异步 I/O 模型大体上可以分为两种，反应式（ Reactive ）模型和前摄式（ Proactive ）模型

首先让我们对异步 I/O 做一些基本的了解。异步 I/O 模型大体上可以分为两种，反应式（ Reactive ）模型和前摄式（ Proactive ）模型：

传统的 select / epoll / kqueue 模型，以及 Java NIO 模型，都是典型的反应式模型，即应用代码对 I/O 描述符进行注册，然后等待 I/O 事件。当某个或某些 I/O 描述符所对应的 I/O 设备上产生 I/O 事件（可读、可写、异常等）时，系统将发出通知，于是应用便有机会进行 I/O 操作并避免阻塞。由于在反应式模型中应用代码需要根据相应的事件类型采取不同的动作，最常见的结构便是嵌套的 if {...} else {...}  或 switch ，并常常需要结合状态机来完成复杂的逻辑。

前摄式模型则恰恰相反。在前摄式模型中，应用代码主动地投递异步操作而不管 I/O 设备当前是否可读或可写。投递的异步 I/O 操作被系统接管，应用代码也并不阻塞在该操作上，而是指定一个回调函数并继续自己的应用逻辑。当该异步操作完成时，系统将发起通知并调用应用代码指定的回调函数。在前摄式模型中，程序逻辑由各个回调函数串联起来：异步操作 A 的回调发起异步操作 B ，B 的回调再发起异步操作 C ，以此往复。

Reactor 和 Proactor 同为事件驱动 I/O 模型，其本质区别在于事件触发时机： Reactor 在 I/O 设备就绪，即可以立即执行 I/O 调用而无需阻塞时触发，只有这时才可以放心大胆的执行 I/O 调用；而 Proactor 则允许在任意时刻发起 I/O 调用请求，并在 I/O 调用完成时触发事件。

Proactor 可以直接利用系统提供的 aio 、 IOCP 等异步 I/O 机制实现。不过鉴于一时之间各种平台上 aio 接口实现的兼容性、功能、性能等方面的表现都还比较不靠谱，常见平台里还是 Win32 IOCP 对 Proactor 的原生支持最好。当系统不提供原生的异步 I/O 机制时，也可以使用 Reactor 模拟实现。相关内容可参见这篇文章。 MINA 正是借由 Java NIO 的 Reactor 实现的模拟 Proactor 模型。 Boost.Asio 的 Proactor 内核在非 NT Win32 平台上也是利用select() / kqueue() / epoll 等 Reactor 模拟实现的。

Reactor 按照事件触发方式又可分为 level-triggered (LT) 和 edge-triggered (ET) 两种，其区别详见 epoll 的 man page 。传统的 select() / poll() 都属于 LT Reactor ； kqueue() 则是 ET Reactor ； epoll 是个两面派， LT/ET 语义通吃。

前摄式模型相较于反射式模型往往更加难以编程。然而在具有原生异步 I/O 支持的操作系统中（例如支持 IO Completion Port 的 Win32 系统），采用前摄式模型往往可以取得比反应式模型更佳的效率。在没有原生异步 I/O 支持的系统中，也可以使用传统的反应式 API 对前摄式模型予以模拟。在现代的软硬件系统中，使用 epoll 和 kqueue 的前摄式模型实现同样可以轻松解决 C10K 问题。前摄式模型的一个显著优势是在实现复杂逻辑的时候不需要借助于状态机。因为状态机已经隐含在由回调串联起来的异步操作链当中了。如果上述内容难以理解，可以参考 Boost.Asio，这是一个相当优秀的跨平台 C++ 前摄式 I/O 模型实现。