从时间碎片角度理解阻塞IO模型及非阻塞模型

阻塞模型限制了服务器的并发处理能力(伸缩性或同时处理的客户端连接数)

传统的网络服务器只支持阻塞模型,该模型下,针对每个客户端连接,服务器都必须创建一个线程来处理这个连接上的请求,服务器必须维持着这些线程直到线程中的处理工作结束。

服务器上所能创建的线程数量是有限的,WHY?

  • 进程上下文切换是耗时的过程
  • 创建的进程本身占用资源,比如每个进程或线程占用一定容量的内存
  • 等待数据准备和内核缓存复制,导致IO阻塞,占用着线程

所以当连接到服务器上的客户端的数量很大时,把服务器上所能创建的线程都占据了时,服务器就无法接受更多的连接了。这限制了服务器处理请求的伸缩性。

并非所有客户端都是持续活跃的

存在这样一个事实,就是虽然连接到服务器上的客户端很多,但并非所有客户端都是持续活跃着的。它们占据着阻塞式服务器的线程资源——即使它们处于非工作状态。这些线程占据了资源,却不工作。

这会造成什么现象呢?
就是线程时间的碎片化——一个线程大部分时间是在等待IO操作的结果。

为了让服务器能接受更多客户端的连接,非阻塞模型就出现了。

如何提升服务器的并发处理能力?

消灭碎片化时间,可以提升服务器的并发处理能力。

如何消灭碎片化时间? 让线程分工协作各司其职,是一个很好的手段。
原来的阻塞模型下,一个线程要干所有的事情。分工协作机制下,一部分线程专门用于接受客户端的连接、一部分专门用于获取请求的数据、一部分专门执行计算工作、还有一部分线程专门用于响应客户端。
接受客户端连接的线程在接收到客户端连接后,立即把连接交给后续工序的线程处理,而它自己则继续接受下一个连接。如此类推,各个线程无须等待,不存在碎片化时间,全负荷工作。
这样一来,整体上需要的较少的线程,就可以完成以前需要较多线程才能达到的工作时间了。

阻塞模型下的实现方式

在阻塞模型下,利用异步处理的方式对线程进行分工协作。接收请求的线程可以满负荷工作,但处理IO操作的线程仍然是阻塞着的,仍然存在线程工作不饱和的现象。

非阻塞模型彻底消灭线程工作不饱和

非阻塞模型下,IO操作不再是阻塞的了,而是立即返回。这样的话,处理IO操作的线程,可以在空闲时对所有请求进行轮询,以便判断哪些IO操作已完成。比如判断某个请求是否可以进行“写”操作,如果还不可以,无须等待,继续判断下一个请求是否可以进行“读”操作,如果可以则立即读取数据,然后把数据转交给专职计算的线程。这样就让线程工作不饱和现象消失了。

这是所谓的“同步非阻塞”。

轮询的耗时如何消灭?

这就要请出“IO复用”这尊大神了。

IO复用模型下,线程一次性从操作系统那儿获得一批可以进行IO操作的请求,处理完毕后,再此获得新的一批。线程无须与操作系统交互多次以便轮询每个请求的状态,而是与操作系统交互一次即可获得批量信息。效率进一步提高啦。

阅读 1k更新于 2018-11-13
推荐阅读
数据价值
用户专栏

挖掘数据价值的技术、流程相关的文章

8 人关注
13 篇文章
专栏主页
目录