66、Reactor模式：事件驱动模型、Reactor核心组件、libevent简介

说到网络编程，绕不开的一个话题就是「Reactor模式」。我刚开始接触它的时候，觉得这东西挺玄乎的。后来在项目中真正用起来，才发现它其实就是一套「等事件来了再干活」的思路。说白了，就是不让你的程序傻等着。

事件驱动模型：别让CPU空转

传统的阻塞式编程，你想想看，一个accept()下去，如果没有新连接，整个线程就卡在那了。这多浪费啊。事件驱动模型的核心思想就是：把控制权交给一个中央调度器，由它来通知你「有事情发生了，快去处理」。

我在早期做的一个聊天服务器项目里，就吃过这个亏。每个客户端一个线程，结果几百人同时在线，线程切换开销直接把CPU干到100%。后来改成事件驱动，同样的机器，扛住了几千人。嗯，这就是差距。

这个模型的好处很明显：一个线程就能管理成千上万个连接。CPU不会空转，只在有事件时才干活。你想想看，这效率能不高吗？

Reactor核心组件：拆开来看其实不复杂

Reactor模式里有几个关键角色。我习惯把它们比作一个团队：

组件	角色	职责
Reactor	项目经理	负责事件循环，分发事件给对应的Handler
Event Handler	一线员工	处理具体的事件逻辑，比如读数据、写数据
Demultiplexer	前台接待	等待事件发生，通知Reactor「有人来了」
Initiation Dispatcher	调度员	管理Event Handler的注册和移除

说白了，Reactor就是那个「总控」。它调用select/poll/epoll（也就是Demultiplexer）去等事件，等到了就喊对应的Handler来干活。我曾经在重构一个老旧网关程序时，就是按照这个结构重新设计的，代码清晰了很多，维护起来也舒服。

一个简单的Reactor框架示例

光说不练假把式。我写个极简的Reactor核心循环，你感受一下：

// 伪代码：Reactor事件循环的核心
void reactor_loop(Reactor *reactor) {
    while (reactor->running) {
        // 1. 等待事件发生（Demultiplexer的工作）
        int nfds = epoll_wait(reactor->epfd, events, MAX_EVENTS, -1);
        
        // 2. 遍历所有就绪的事件
        for (int i = 0; i < nfds; i++) {
            EventHandler *handler = (EventHandler*)events[i].data.ptr;
            
            // 3. 根据事件类型调用对应的回调
            if (events[i].events & EPOLLIN) {
                handler->on_readable(handler);
            }
            if (events[i].events & EPOLLOUT) {
                handler->on_writable(handler);
            }
            if (events[i].events & EPOLLERR) {
                handler->on_error(handler);
            }
        }
    }
}

你看，核心逻辑就这么几行。但实际工程中，要考虑的事情就多了：内存管理、超时处理、线程安全……嗯，这里要注意，回调函数里千万别做耗时操作，否则会阻塞整个事件循环。我曾经有个同事，在回调里直接调了个sleep()，结果整个服务器卡了5秒，线上事故啊。

libevent简介：别自己造轮子了

既然Reactor模式这么好用，那是不是每个项目都要自己写一个？我个人建议：除非你是为了学习，否则直接用现成的库。libevent就是这样一个成熟的事件通知库。

libevent封装了底层的事件多路复用机制（select/poll/epoll/kqueue等），给你提供统一的API。你只需要注册事件和回调，剩下的它帮你搞定。

用libevent写一个简单的TCP服务器，代码量能减少一半以上。我记得第一次用libevent重写一个老项目时，原来2000多行的网络层代码，最后只用了不到500行就搞定了。而且bug还少了，因为底层的东西库作者已经帮你踩过坑了。

// libevent 简单示例：创建一个TCP服务器
#include <event2/event.h>
#include <event2/listener.h>

void accept_cb(struct evconnlistener *listener, 
               evutil_socket_t fd, 
               struct sockaddr *addr, 
               int socklen, 
               void *ctx) {
    // 新连接来了，在这里处理
    printf("新连接接入，fd=%d\n", fd);
}

int main() {
    struct event_base *base = event_base_new();
    
    struct sockaddr_in sin;
    memset(&sin, 0, sizeof(sin));
    sin.sin_family = AF_INET;
    sin.sin_port = htons(8888);
    
    struct evconnlistener *listener = 
        evconnlistener_new_bind(base, accept_cb, NULL,
                                LEV_OPT_REUSEABLE|LEV_OPT_CLOSE_ON_FREE,
                                -1, (struct sockaddr*)&sin, sizeof(sin));
    
    // 进入事件循环
    event_base_dispatch(base);
    
    evconnlistener_free(listener);
    event_base_free(base);
    return 0;
}

这段代码虽然短，但已经是一个能跑的TCP服务器了。你编译运行后，用telnet连上去，accept_cb就会被触发。是不是很简洁？

Reactor模式的适用场景

不是所有场景都适合用Reactor。我个人总结了几条经验：

• 高并发连接：比如聊天服务器、游戏服务器、消息推送系统
• I/O密集型：大部分时间在等网络或磁盘，CPU占用不高
• 回调友好：业务逻辑可以拆分成短小的回调函数

反过来，如果你的业务是CPU密集型的，或者每个请求处理时间很长，那Reactor模式反而会拖累性能。这时候可以考虑用多线程或者多进程模型。

知识体系总览

下面这张图是我自己整理的Reactor模式知识结构，你可以对照着梳理思路：

从这张图可以看出来，Reactor模式从上到下分了三层：事件循环层、多路复用层、实践应用层。每一层都有对应的组件和实现方式。我个人建议你从libevent入手，先会用，再慢慢理解底层原理。

好了，关于Reactor模式的核心内容就这些。记住一句话：事件驱动不是银弹，但在网络编程领域，它绝对是最趁手的兵器之一。多写几个demo，你就能体会到它的妙处了。

---