Reactor模式演进分为单线程、多线程和主从三种模型：单线程模型由一个NIO线程串行处理全部事件，轻量无锁但无法利用多核；多线程模型将业务逻辑卸载至Worker线程池，提升吞吐但引入上下文切换开销；主从模型通过Main Reactor专责accept、Sub Reactor分担I/O，实现连接管理与数据处理彻底分层，成为高并发生产环境事实标准。
Reactor 模式本质是把“等事件”和“处理事件”分开，用 I/O 多路复用（如 epoll）监听多个连接，再按需分发。它的演进不是为了炫技，而是为了解决真实场景中不断暴露的瓶颈：单线程扛不住高并发、多线程引入锁竞争、业务逻辑卡住 I/O 路径。三种主流模型对应三个关键阶段的解耦。
单线程 Reactor：一个线程干所有事
整个流程——accept 新连接、read 请求、decode、execute 业务、encode、write 响应、close 连接——全在一个 NIO 线程里串行完成。它依赖 Selector 轮询就绪事件，靠非阻塞 I/O 避免线程挂起。
优点很实在：没有线程切换开销，没有锁，代码路径清晰，调试简单。适合低负载、纯 I/O 密集、业务逻辑毫秒级完成的场景，比如轻量级代理或监控探针。
但硬伤明显：
- 无法利用多核 CPU，4 核机器只跑满 1 个核
- 任意环节耗时稍长（比如一次同步 DB 查询），整个事件循环就卡住，后续所有连接的读写都会延迟
- 连接数上万后，Selector.select() 和事件遍历本身也会成为瓶颈
多线程 Reactor：I/O 和业务逻辑分离
它把原来单线程里最耗时的业务处理（decode/encode/计算/DB 调用）抽出来，交给独立的 Worker 线程池执行。Reactor 线程只管 accept、read、write 和事件分发，不碰业务逻辑。
这种分工带来两个直接收益：
- Reactor 线程保持轻量，响应更快，能支撑更高连接吞吐
- Worker 线程池可横向扩展，匹配 CPU 核心数，真正压满硬件资源
代价也很清楚：每次事件从 Reactor 线程移交到 Worker 线程，要走一次队列入队 + 线程唤醒 + 上下文切换；Worker 处理完再把响应交回 Reactor 写出，又是一次切换。在 QPS 极高、单请求极轻的场景下，这部分开销可能反成拖累。
主从 Reactor：连接管理与数据处理彻底分层
这是生产环境事实标准，Netty、Nginx、Redis 6+ 的 IO 模块都基于此。它把 Reactor 拆成两级：
- Main Reactor（主线程）：只做一件事——accept 新连接。它不读写任何客户端数据，也不注册读写事件
- Sub Reactor（多个子线程，通常等于 CPU 核数）：每个 Sub Reactor 绑定一个独立的 Selector 和线程，负责自己分到的那批连接的全部 I/O：read、write、心跳检测、超时关闭
新连接被 Main Reactor 接收后，通过轮询或负载策略分配给某个 Sub Reactor；该 Sub Reactor 立即将这个 SocketChannel 注册到自己的 Selector 上，后续所有 I/O 全由它闭环处理。
这种结构消除了前两种模型的痛点：
- 不再有单点 Reactor 瓶颈：accept 和 I/O 并行，Main 和 Sub 各自专注
- 无跨线程 I/O 数据搬运：每个连接的生命周期完全绑定在一个 Sub Reactor 线程内，避免了锁和上下文切换
- 天然支持 One Thread One Loop，线程与 EventLoop 一一绑定，零竞争
实际部署时，Sub Reactor 数量通常设为 CPU 核心数，Main Reactor 可配 1 个或少量（防 accept 风暴）。业务逻辑仍可进一步卸载到额外线程池，形成「主从 Reactor + 业务线程池」的完整分层。
