一、Reactor模式设计：从单线程到主从架构

Reactor模式，说白了就是网络编程里的“事件分发器”。我刚开始接触它的时候，觉得这东西不就是个while循环吗？后来踩过坑才明白——Reactor是高性能服务器的灵魂。

今天咱们就把它彻底聊透。从最朴素的单线程版本，到工业级的主从架构，我会把每个设计决策背后的思考都讲清楚。

1.1 Reactor模式的核心思想

先问个问题：一个服务器要同时处理成千上万个连接，怎么做到不卡死？

传统做法是来一个连接开一个线程。但线程多了，上下文切换的开销能把CPU拖垮。你想想看，10000个线程光切换就能吃掉大半性能。

Reactor的思路完全不同——它把“等待”和“处理”拆开了。

我习惯把Reactor比作一个前台接待员。客户来了（事件发生），接待员喊一声“张三，你的快递到了”，然后继续等下一个客户。接待员自己不拆快递——拆快递是处理器的事。

嗯，这里要注意：Reactor只负责通知，不负责干活。这个设计哲学贯穿了所有变体。

1.2 单线程Reactor：最朴素的版本

先看最简单的实现。所有事情都在一个线程里完成：监听事件、读取数据、处理业务、发送响应。

// 伪代码：单线程Reactor
while (true) {
    events = epoll_wait(epfd, events_arr, MAX_EVENTS, -1);
    for (int i = 0; i < events; i++) {
        if (events_arr[i].data.fd == listen_fd) {
            // 接受新连接
            conn_fd = accept(listen_fd, ...);
            epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, ...);
        } else {
            // 处理已连接socket上的数据
            handle_event(events_arr[i].data.fd);
        }
    }
}

这段代码我当年在写第一个聊天服务器时用过。优点很明显——没有锁，没有并发问题。但缺点也致命：任何一个请求处理慢了，后面的全得排队等。

单线程Reactor适合什么场景？CPU密集型任务少、连接数不多（几百以内）。比如一些内部管理工具、监控代理。

1.3 多线程Reactor：让干活的人多起来

单线程的问题在于“一个人干所有活”。那我们把“干活”这件事拆出去不就行了？

多线程Reactor的思路是：Reactor线程只负责事件分发，业务处理交给线程池。

// 伪代码：多线程Reactor
// Reactor线程
while (true) {
    events = epoll_wait(epfd, events_arr, MAX_EVENTS, -1);
    for (int i = 0; i < events; i++) {
        if (events_arr[i].data.fd == listen_fd) {
            conn_fd = accept(listen_fd, ...);
            epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, ...);
        } else {
            // 把任务丢给线程池
            thread_pool.submit(handle_event, events_arr[i].data.fd);
        }
    }
}

// 工作线程
void handle_event(int fd) {
    read(fd, buf, sizeof(buf));
    process(buf);  // 业务逻辑
    write(fd, response, len);
}

这里有个关键点：读写操作也在工作线程里完成。Reactor线程只做两件事——accept新连接、把就绪fd扔给线程池。

我个人习惯把线程池大小设为CPU核心数的2倍。为什么？因为网络IO经常有等待，多几个线程能填满空闲时间片。但别设太多，否则锁竞争会让你怀疑人生。

1.4 主从Reactor架构：工业级的选择

多线程Reactor还有个问题：一个Reactor线程要处理accept和所有连接的读写事件。当连接数上万时，这个单点会成为瓶颈。

主从Reactor的解法很优雅——把“接客”和“服务”分开。

• 主Reactor：只负责accept新连接
• 从Reactor：多个，每个负责一部分连接的读写事件

你想想看，这就像餐厅里有个领班专门带位，然后多个服务员分别服务不同桌的客人。领班不端菜，服务员不带位——各司其职。

// 伪代码：主从Reactor
// 主Reactor线程
void main_reactor() {
    while (true) {
        events = epoll_wait(main_epfd, ...);
        for (event : events) {
            if (event is accept) {
                conn_fd = accept(listen_fd, ...);
                // 选择一个从Reactor，把连接注册给它
                sub_reactors[next].add_conn(conn_fd);
                next = (next + 1) % SUB_REACTOR_COUNT;
            }
        }
    }
}

// 从Reactor线程（每个从Reactor一个线程）
void sub_reactor(int id) {
    while (true) {
        events = epoll_wait(sub_epfd, ...);
        for (event : events) {
            handle_event(event.data.fd);  // 读写+业务处理
        }
    }
}

这里有个设计细节：从Reactor里要不要再用线程池？ 我的经验是：如果业务逻辑轻（比如转发、代理），直接在从Reactor线程里处理就行。如果业务重（比如编解码、压缩），那就在从Reactor里再加一层线程池。

我参与过的一个网关项目，就是用主从Reactor扛住了10万并发连接。主Reactor 1个线程，从Reactor 8个线程（8核机器），每个从Reactor管理约1.2万个连接。CPU利用率稳定在75%左右，非常稳。

1.5 三种架构的对比与选型

聊了这么多，到底该用哪种？我整理了个对比表：

架构	并发能力	开发复杂度	适用场景
单线程Reactor	低（<1000连接）	低	原型验证、内部工具、低负载服务
多线程Reactor	中（<10000连接）	中	业务逻辑较重的服务、中小型网关
主从Reactor	高（10万+连接）	高	高性能服务器、大型网关、IM系统

选型建议：

• 如果你在写一个Demo或内部工具，单线程就够了。别过度设计。
• 如果业务逻辑重，但连接数不大，多线程Reactor性价比最高。
• 如果目标是高并发，直接上主从Reactor。别犹豫。

1.6 核心逻辑图

下面这张图展示了三种Reactor架构的核心流程对比。我特意把事件流画清楚了，方便你理解数据是怎么流动的。

从这张图可以清楚看到：单线程是一条线走到底，多线程是分叉到线程池，主从则是先分叉到从Reactor、再从从Reactor分叉。每多一层分叉，并发能力就上一个台阶，但复杂度也相应增加。

1.7 总结

Reactor模式的核心就一句话：把事件通知和业务处理解耦。单线程版本让你理解原理，多线程版本解决阻塞问题，主从版本突破单点瓶颈。

我建议你从单线程Reactor开始写代码，跑通后再一步步加线程、加主从。这个过程走一遍，你对网络编程的理解会上一个台阶。

嗯，今天就聊到这。记住：架构没有银弹，只有最适合当前场景的选择。