反应器模式

结构

反应式应用由多个活动部分组成并依赖于一些支持机制^[2]：

把柄（Handle）: 具有IO和数据的针对特定请求的一个标识符和接口。这通常采用套接字、文件描述符或类似机制的形式，它们应当由大多数现代的操作系统提供。
解多路复用器（Demultiplexer）: 可以有效的监视一个把柄的状态的事件通知器（notifier），它将有关的状态变更通知给其他子系统，典型的是一个IO把柄成为了“准备好读取”。传统上这个角色由select()系统调用充任，而更加现今的例子包括epoll、kqueue和IOCP。
分派器（Dispatcher）: 反应式应用的实际事件循环，这个构件维护着有效的事件处理器（handler）的注册，它在一个事件被引发之时激发（invoke）适合的处理器。
事件处理器（Event Handler）: 也叫做请求处理器，它是用来处理一种类型的服务请求的特定逻辑。反应器模式为了更大的灵活性而提倡将它们动态的向分派器注册为回调。缺省情况下，反应器不使用多线程，转而在跟分派器同一个线程中激发一个请求处理器。
事件处理器接口: 抽象接口类，代表了事件处理器的通用属性和方法。每个特定处理器都必须实现这个接口，分派器将通过这个接口来操作事件处理器。

Remove ads

应用

属性

所有的反应器系统在定义上是单线程的，但可以在多线程环境中存在。

反应器模式可完全分离程序特定代码，这意味着应用可分为模块化的，可复用的组件。另外，由于请求的处理程序是同步调用，反应器模式可允许简单粗粒并发而不必添加多线程并发系统的复杂性。

由于反向的流程控制，反应器模式比过程模式更难以调试 ^[2]。此外，因为请求处理器只会被同步调用，因此会限制反应器模式的最大并发数，特别是在对称多处理硬件。反应器模式的可扩展性，不仅受限于请求处理器的同步调用，同时也受解多路器限制。^[10]

结构