反应堆模式(二)：非阻塞式IO应用

 在第一部分中，我们讲述了在单个服务下扩展一个单线程应用的请求处理数量所面临的问题。

在这篇文章中，我们将关注CPU使用率最大化的一个可选择的解决方案。

以下来自文章一的图，表明了应用需要通过请求来使用CPU，而且还必须在两次请求之间等待。

加入我们把处理请求看成一个事件，并且把这些时间进行排队然后在一个线程中执行，那么我们可以肯定CPU降一直被占用，从而也使CPU使用率达到最大，还避免了不必要的上下文切换。

考虑到由于没有任何IO操作的事件可以在处理块中被非顺序性或者异步执行，所以可以把代码分割成独立的可执行快(事件)，这样其他的请求事件可以再它们之间穿插执行。

 

Event Loop
Event Loop是在一个程序中的一个可以通过单个线程来等待事件、执行事件的循环程序。想要了解更多的话可以通过搜索“Event Loop”来了解。

 

Unix文件描述符

由于unix认为所有东西都是文件的原则，文件描述符在文件读写、网络通信、设备通讯和进程间通信时用来检测事件的发生。而系统调用通过“epoll”、“pselect”可以在不阻塞应用的前提下来检测文件描述符的状态变化。

下图展示了一个简单的event loop,其中每个循环包括四个阶段:

1.检查是否有新的事件创建(如一个请求的到来或者一个回调事件的发生)以及为队列中已经存在的任务添加新的事件

2.从队列中选择事件

3.执行事件

4.创建回调事件(如响应结果时的数据库查询和网络请求的回调)。回调事件是通过epoll或者pselect模式来处理。

以上描述的就是堆反应模式的一个简单例子。

 

C10K问题

曾经，反应堆模式(reactor pattern)在C10问题和C10K问题解决办法中对非阻塞模式的使用有着非常突出的作用。

 

反应堆模式(reactor pattern)的缺点

1.基于异步事件机制使得对整个代码及其结构的理解边的非常困难。这个希望一些库可以起到帮助作用。

2.由于堆栈将从回调开始而不是从请求一开始就建立，因此，调试也变的更加困难。

这些缺点可以通过使用fiber来缓和(例如使用ruby fiber,node fiber)，这些将在以后的文章中讲到。

 

1.本文由程序员学架构翻译，由mathew同学校审；仅用于交流学习使用。

2.本文译自Venkatesh CM在Reactor Pattern Part 2 - Applications with Non-Blocking I/O的博客。

3. 转载请务必注明本文出自:程序员学架构(微信号：archleaner )

4.更多文章请扫码：