Proactor设计模式：单线程高并发

Boost::Asio为同步和异步操作提供了并行支持，异步支持基于前摄器模式，这种模式的优点和缺点可能比只同步或反应器方法要低。

让我们检查一下Boost::Asio是如何实现前摄器模式的，没有引用基于平台的细节。

前摄器设计模式，改编自POSA2

--异步操作

定义一个异步执行的操作，比如socket的异步读和异步写。

--异步操作处理器

执行异步操作并在操作完成的时候把事件入队到一个完成事件队列，stream_socket_service等服务可以抽象成异步操作处理器。

--完成事件队列

缓存完成事件直到他们被异步事件分解器取出队列。

--完成句柄

处理异步操作的结果，是函数对象，经常使用boost::bind创建。

--异步事件多路分解器

阻塞等待完成事件队列，直到有事件发生，并返回一个完成事件给调用者。

--前摄器

调用异步事件分解器来把事件出队列，并且分发给同事件关联的完成句柄(调用函数对象)，这个抽象层的代表是io_service层。

--发起者

应用程序的代码启动了异步操作，发起者通过一个抽象的接口来和异步操作处理器交互，比如basic_stream_socket,轮流提供类似于stream_socket_service的服务。

使用Reactor的实现

在许多平台，Boost::Asio依照Reactor的方式实现Proactor，比如select、epoll、kqueue，下列方法符合Proactor的设计模式：

--异步操作处理器

一个使用select、epoll、kqueue实现的Reactor，当Reactor指示资源已经准备好执行操作，处理器执行操作并把完成时间队列关联的完成句柄入队列。

--完成事件队列

完成句柄的列表(函数对象)。

--异步事件多路分解器

等待事件或者条件变量直到完成事件队列的完成句柄可用。

使用windows平台overlapped I/O实现

在windowsNT、2000或者xp，Boost::Asio利用overlapped的优势来实现有效的Protacor模式，下列是符合Proactor模式的方法：

--异步操作处理器

操作系统提供支持，通过调用AcceptEx之类的操作来发起操作。

--完成事件队列

操作系统提供支持，并和I/O完成端口关联起来，

--异步事件多路分解器

被Boost::Asio调用来出队列事件和他们的关联完成句柄。

优势

--可移植的

许多操作系统支持一个原生的异步I/O API作为高性能网络开发的推荐操作，这些库可能依据原生异步I/O的实现，然而，如果原生API不可用，这些库也可能使用典型Reactor模式的异步事件多路分解器来实现，比如POSIX select()。

--从并发中解耦线程

耗时长的操作被应用程序异步执行，因此应用程序不需要启动大量线程来提高并发

--性能和扩展性

某些实现策略会降低系统性能，比如每个线程一个连接，因为增加了CPU间的上下文切换、同步、数据移动，通过异步操作可以避免或者减少上下文切换开销-最小化操作系统的线程-限制资源-只激活有事件要处理的控制线程。

--简单的应用同步

异步完成句柄就像是在一个单线程环境写入，因此应用程序开发过程中可以少考虑或者不考虑同步问题。

--函数构成

函数构成依据函数的实现来提高更高抽象的操作，比如发送一个特定格式的消息，每个函数多次调用来完成较低抽象的读、写操作。

例如，一个协议的每个消息包含一个定长的消息头和变长的消息体，消息体的长度被消息头指定，一种假设是用两个低抽象的读、写操作完成消息的读取，第一个接收消息头，一旦消息长度确定，第二个接收整个消息。

为了写作异步模式的函数，异步操作可以被连接起来，也就是说，一个操作上的完成端口可以启动另外一个，启动链条的第一个可以被包装起来，调用者不需要知道高级抽象操作作为一个异步操作的链条来实现。

这种编写方式简化了开发者在网络库上的高层抽象，比如为了支持某种协议而开发函数。

劣势

--编程复杂性

使用异步模式开发应用程序更加困难，因为从时间和空间来看启动和完成被分割开来，因为控制流反转应用程序更难被调试。

--内存使用

在读、写期间内存是一直占用的，这会带来不确定性，在每个并发的时候需要一个单独的buffer，而Reactor模式，在读、写就绪前并不需要缓存空间。

参考文献

[POSA2] D. Schmidt et al, Pattern Oriented Software Architecture, Volume 2. Wiley, 2000.