《游戏服务端编程实践》2.1.2 Reactor 模式与事件循环

一、引言：从 I/O 到事件的必然演化

在上一节我们学习了阻塞与非阻塞 I/O 模型：

• 阻塞模型简单，但每个连接需要独立线程；
• 非阻塞模型高效，但需要手动轮询，代码复杂。

于是问题来了：

有没有一种方式，既不阻塞线程，又不需要应用自己去轮询所有连接？

答案就是 —— Reactor 模式（反应器模式）。

它的出现，是对“事件驱动架构（Event-driven Architecture）”的第一次大规模系统化实践， 也是 Nginx、Netty、Node.js、Skynet、Go runtime 的共同理论基础。

二、Reactor 模式的核心思想

Reactor 是一种基于“事件多路复用 + 回调分发”的高并发 I/O 模型。

简单来说：

1. 所有的 socket 事件（连接、可读、可写）都由一个统一的**事件分发器（Event Demultiplexer）**监控；
2. 当某个事件发生时，系统唤醒 Reactor；
3. Reactor 调用事先注册好的事件处理器（Handler）；
4. 每个 Handler 只处理自己负责的事件。

示意图：

flowchart LR
A["多个客户端"] -->|连接/读写事件| B["事件分发器 (epoll/select)"]
B --> C["Reactor 主线程"]
C --> D["Handler: accept/read/write"]

“Reactor 就像一个剧院经理（Event Loop），当观众（事件）举手时，它把麦克风交给对应的演员（Handler）。”

三、Reactor 模式的角色划分

四、Reactor 模式的工作流程

sequenceDiagram
    participant Client
    participant Reactor
    participant Handler
    Client->>Reactor: 网络事件发生（read/write）
    Reactor->>Reactor: 事件检测 (epoll_wait)
    Reactor->>Handler: 回调对应事件处理器
    Handler->>Client: 处理并响应结果

流程分为四步：

1. 事件注册：每个连接向 Reactor 注册感兴趣的事件（READ、WRITE、ACCEPT）。
2. 事件检测：Reactor 阻塞等待事件（epoll_wait）。
3. 事件分发：事件触发后，Reactor 调用对应 Handler。
4. 事件处理：Handler 读取数据、执行业务逻辑、发送响应。

五、单 Reactor 单线程模型

这是最基本的 Reactor 实现形式。

架构图

graph LR
A["Main Thread"] --> B["Reactor: select/epoll"]
B --> C["Handler: Accept/Read/Write"]

特点

• 所有事件在同一线程中处理；
• 没有锁，逻辑简单；
• 无法充分利用多核 CPU；
• 大并发下性能受限。

示例：单线程 Reactor（Java 伪代码）

Selector selector = Selector.open();
ServerSocketChannel server = ServerSocketChannel.open();
server.configureBlocking(false);
server.register(selector, SelectionKey.OP_ACCEPT);

while (true) {
    selector.select();
    for (SelectionKey key : selector.selectedKeys()) {
        if (key.isAcceptable()) accept(key);
        else if (key.isReadable()) read(key);
    }
}

这是 Netty、Node.js、Skynet 等的最原始雏形。

六、单 Reactor 多线程模型

为利用多核资源，我们可以把事件分发和业务处理拆开：

graph LR
A[Main Thread Reactor] --> B[Worker Thread Pool]
A --> C[Handlers]

工作流程

1. Reactor 负责 I/O 事件分发；
2. 每个事件被分配给线程池；
3. 工作线程异步执行业务逻辑；
4. 防止 I/O 线程阻塞。

伪代码示例

ExecutorService workers = Executors.newFixedThreadPool(8);

while (true) {
    selector.select();
    for (SelectionKey key : selector.selectedKeys()) {
        if (key.isAcceptable()) accept(key);
        else if (key.isReadable()) workers.submit(() -> read(key));
    }
}

这种结构成为 “Reactor + Worker Thread Pool” 模型，是现代服务端通用形态。

七、主从 Reactor 模型（Multi-Reactor）

背景

单个 Reactor 在高并发下仍可能成为瓶颈。 解决方案是 多个 Reactor 线程分工：一个负责接收连接，多个负责读写事件。

结构图

graph LR
A[Main Reactor] --> B[Sub Reactor 1]
A --> C[Sub Reactor 2]
A --> D[Sub Reactor 3]
B --> B1[Handler 1...n]
C --> C1[Handler n...m]

工作机制

• Main Reactor 监听连接事件；
• 新连接分配给某个 Sub Reactor；
• Sub Reactor 独立事件循环处理 I/O。

Netty 实现对应关系

这种结构称为 Reactor 多线程模型（Reactor Multithreaded Pattern）。

八、Reactor 的线程模型演化对比

现代框架如：

• Netty、Nginx、Go runtime → 多 Reactor 多线程；
• Node.js → 单 Reactor 单线程 + 协程 offload；
• Skynet → 多 Service 多 Reactor 独立通信。

九、事件循环（Event Loop）的本质

Reactor 的核心其实就是一个“事件循环”：

while (running) {
    events = poller.poll(timeout)
    for event in events:
        handler = registry[event.fd]
        handler.handle(event)
}

这个循环满足：

• 永不退出；
• 事件驱动；
• 非阻塞；
• 单线程或有限线程数。

它是整个系统的心跳。

十、事件循环的生命周期

十一、Java 中的事件循环（Netty）

Netty 的 NioEventLoop 是对 Reactor 模型的高度封装：

public void run() {
    for (;;) {
        int ready = selector.select();
        processSelectedKeys();
        runAllTasks(); // 用户任务
    }
}

特征：

• 每个线程独立 Selector；
• 事件轮询 + 用户任务交替执行；
• 不允许阻塞操作；
• 通过 ChannelPipeline 实现责任链模式。

十二、Go 的事件循环（runtime netpoll）

Go runtime 的 netpoll 实现类似 epoll + M:N 调度：

• 每个 P（Processor）管理一个 PollDesc；
• 通过 epoll/kqueue 等等待事件；
• 将事件加入就绪队列；
• 调度器唤醒相应 goroutine。

func netpoll(block bool) gList {
    var events = epoll_wait(...)
    for _, ev := range events {
        ready.push(ev.g)
    }
    return ready
}

特点：

• 每个 goroutine 看似阻塞，实际是挂起；
• 内核事件唤醒对应协程；
• “同步写法，异步执行”。

十三、事件循环与任务队列

现代 Reactor 都支持“任务队列”（task queue），允许在事件循环内提交延迟任务：

eventLoop.execute(() -> doSomethingLater());

任务类型：

• 定时任务；
• 用户回调；
• I/O 读写；
• 状态变更。

在游戏服务器中：

• 任务队列可以实现帧同步；
• 也可以用作逻辑队列（Logic Queue），保证单线程逻辑安全。

十四、Reactor 与 Actor 模型的区别

Reactor 解决“并发连接”； Actor 解决“并发逻辑”。 它们往往在大型服务器中结合使用。

十五、Reactor 的典型陷阱

十六、背压机制（Backpressure）

在高并发系统中，如果生产者速度 > 消费者处理速度，会导致内存暴涨。

Reactor 框架通过 背压机制 控制流量：

• 暂停读事件；
• 等待队列释放；
• 再次注册读事件。

Netty 示例：

channel.config().setAutoRead(false);
...
channel.config().setAutoRead(true);

十七、Reactor 的延伸：Proactor 模型

Reactor 是“事件就绪通知”，而 Proactor 是“操作完成通知”。

代表实现：

• Reactor：Linux epoll、BSD kqueue；
• Proactor：Windows IOCP、Linux AIO。

现代异步框架（如 Rust Tokio）已接近 Proactor 混合模式。

十八、游戏服务器中的 Reactor 应用

十九、性能优化与调优

1. 减少 Selector 唤醒次数：合并事件；
2. I/O 与逻辑线程分离：事件循环仅处理 I/O；
3. 批量读写：减少系统调用；
4. 内存池化：复用 ByteBuffer；
5. 零拷贝：使用 FileChannel.transferTo()；
6. 避免过度注册事件：仅注册需要监听的事件；
7. 跨核亲和性调度：线程与 CPU 核绑定。

二十、Reactor 实战：简易 Echo Server（单 Reactor）

public class SimpleReactor {
    public static void main(String[] args) throws IOException {
        Selector selector = Selector.open();
        ServerSocketChannel server = ServerSocketChannel.open();
        server.bind(new InetSocketAddress(8080));
        server.configureBlocking(false);
        server.register(selector, SelectionKey.OP_ACCEPT);

        while (true) {
            selector.select();
            Iterator<SelectionKey> keys = selector.selectedKeys().iterator();
            while (keys.hasNext()) {
                SelectionKey key = keys.next(); keys.remove();
                if (key.isAcceptable()) {
                    SocketChannel client = server.accept();
                    client.configureBlocking(false);
                    client.register(selector, SelectionKey.OP_READ);
                } else if (key.isReadable()) {
                    SocketChannel client = (SocketChannel) key.channel();
                    ByteBuffer buf = ByteBuffer.allocate(1024);
                    int n = client.read(buf);
                    if (n == -1) { client.close(); continue; }
                    buf.flip();
                    client.write(buf);
                }
            }
        }
    }
}

二十一、总结

一句话总结： Reactor 模式让服务器从“请求驱动”转变为“事件驱动”； 事件循环是 Reactor 的心跳； 非阻塞 I/O 是 Reactor 的血液； Handler 与回调是 Reactor 的神经系统。

• Game Server
• Game
• Game in Action
• Programming