Linux高效事件处理模式：Reactor模式和Proactor模式

 

一：认识Reactor模式

  针对于Reactor这个词翻译成汉语是：反应器，也就是反应器模式，很多地方也把它称之为reactor模式。但是呢这两种叫法都不能很好的让我们来理解，这种模式的真正含义！所以我觉得叫他应答者模式会更好理解一些。也就是说，这个模式就像一个侍卫一样，一直在等待你的召唤（也就是你的守卫精灵）。

  并发系统常使用reactor模式，代替常用的多线程处理方式：可以节省系统资源，提高系统的吞吐量。

 

  接下来用比较直观的方式来介绍一下这种方式的优点，以及和通用多线程方式比较一下，可能会更好理解一些！！！。

  以餐饮店为例：每有一个客人来就餐 这就是一个事件，然后它会看一下餐单然后点餐（这就好比喻一个网站会有很多的请求，要求服务器做一些事情），处理这些就餐时间 就需要我们的服务人员了。

  在多线程处理的方式会是这样的：

一个人来就餐，一个服务员去服务，然后客人看餐单，点餐。服务员将餐单传递给后厨；

两个人来就餐，两个服务员去服务......

五个人来就餐，五个服务员去服务......

 

这就是多线程的处理方式，一个事件到来就会有一个线程服务。很显然这种方式在人少的情况下会产生很好的用户体验，每个客人都会觉得自己就是VIP，专人服务的。如果餐厅一直维持这种模式最多来5个客人，这家餐厅是可以很好的服务下去的。

来了一个好消息，因为这家店的服务和餐饮都比较好，吃饭的人多了起来。同一时间会来10个客人，老板很开心，但是只有5个服务员，这样就不能一对一服务了，有些客人就要没有人管了。老板就又请了5个服务员，现在好了，又能每个人都收到VIP的待遇了。

 

可想而知！由于服务态度和食品的质量，这家店的客源越来越多，同事来吃饭的人到了20多个人，可是老板高兴不起来了，再请服务员吧，占地方不说，还要开工资，这可怎么办呢？老板想了想，10个服务员对付20个客人也是能对付过来的，服务员勤快点就好了：也就是服务员伺候完一个客人马上去伺候另一个，还是来得及的。综合考虑老板就用了10个服务人员的线程池了~~~

  但是这样有一个严重的缺点就是：如果正在接受服务员服务的客人点菜很慢（占据时间太长了）其他客人还是要等好长时间。有些脾气火爆的客人可能就不等了直接走了！！！

 

  Reactor是如何解决这个问题的呢：

  老板发现，客人点餐比较慢，大部分服务人员的事件都浪费在了等客人点餐的时间上了！其实干的活不多。老板能当老板当然有不一样的地方，那就是：当客人点餐的时间服务人员可以去招呼其他的客人，等客人点好了菜，直接招呼一声服务员就可以了，马上就会有个服务员过去服务。嘿嘿，然后再老板有了这个新的方法之后，就进行了一次裁员，只留了一个服务员！这就是用单线程来做多线程的事。

 

实际的餐厅都是用的Reactor模式在服务。一些设计都是从生活中来的。

Reactor模式主要是用来提高系统的吞吐量，在有限的资源下处理更多的事。

二：比较

  在高性能的I/O设计中，有两个比较著名的模式Reactor模式和Proactor模式，其中Reator模式用于同步I/O，而Proactor运用于异步I/O操作。

比较这两种模式之前我们先来搞清几个概念：什么是阻塞和非阻塞，什么是同步和异步。

  同步和异步是针对应用程序和内核交互而言的，同步指的是用户进程触发I/O操作并等待挥着轮询的去查看I/O操作是否就绪；而异步是指用户进程触发I/O操作以后便开始做自己的事情，而当I/O操作完成后会得到内核I/O完成的通知。

  而阻塞和非阻塞是针对于进程在访问数据的时候，根据I/O操作的就绪状态来采取的不同方式。（阻塞方式下读取或者写入函数将一直等待，而非阻塞方式下，读取或写入函数会立即返回一个状态值）。

  一般来说I/O模型可以分为：同步阻塞，同步非阻塞，异步阻塞，异步非阻塞I/O。

同步阻塞I/O	用户进程发起一个I/O操作以后，必须等待I/O操作完成，只有当完成了I/O操作后，用户进程才能运行。
同步非阻塞I/O	用户进程发起一个I/O操作后便可返回做其他的事情，但是用户进程需要时不时的询问I/O操作是否就绪，这就要求用户进程不停的其询问，从而引起了不必要的CPU资源浪费。
异步阻塞I/O	应用程序发起一个I/O操作后，不等待内核I/O操作的完成，等内核完成I/O操作后悔通知应用程序，（这也就是同步和异步最关键的区别：I/O的完成时主动得知还是被动得知）；那么为什么说是阻塞的呢？因为此时通过select系统调用来完成的，而select函数本身的实现方式就死阻塞，而采用select函数有个好处就是它可以同时监听多个文件句柄，从而提高系统的并发性！
异步非阻塞I/O	用户进程只需要发起一个I/O操作，然后立即返回，等I/O操作真正的完成后，应用程序会得到I/O操作完成的通知，此时用户进程只需要对数据进行处理就好了，不需要实际的I/O读写操作，因为真正的I/O读取或者写入操作已经由内核完成了。

当我们理解了上面的概念时，我们分别以读写操作为例来看看Reactor和Proactor是怎么处理的！

  Reactor模式处理读取操作：

1.应用程序注册读就绪事件和相关的事件处理器

2.事件分离器等待事件的发生

3.当发生读就绪事件的时候，事件分离器调用第一步注册的事件处理器

4.事件处理器首先执行实际的读取操作，然后根据独到的内容进行进一步的处理

    写入操作类似读取操作，只不过第一步注册的是写就绪事件。

  Proactor模式处理读取操作：

1.应用程序初始化一个异步读取操作，然后注册相应的事件处理器，此时事件处理器不关注读取就绪事件，而是关注读取完成事件，这就是区别于Reactor的关键。

2.时间分离器等待读取操作完成事件。

3.在事件分离器等待读取操作完成的时候，操作系统调用内核线程完成读取操作，并将读取的内容放入用户传递过来的缓存区中。这也是区别于：Reactor的一点。I/O读取处理。

4.事件分离器捕获到读取完成事件后，激活应用程序注册的事件处理器，事件处理器直接从缓存区中读取数据，而不需要进行实际的读取操作。

  总结：

    从上面论述可以看出，Reactor和Proactor模式的主要区别就是真正的读取和写入操作是由谁来完成的。Reactor中需要应用程序自己读取或者写入数据，而Proactor模式中，应用程序不需要进行实际的读写过程，它只需要从缓存区读取或者写入便可，操作系统会读取缓存区或者写入缓存区到真正的I/O设备上。同步和异步是相对于应用和内核的交互方式而言的，同步需要主动去询问，而异步的时候内核在I/O事件发生的时候通知应用程序，而非阻塞和阻塞仅仅是系统再调用系统调用的时候函数的实现方式而已。