4. 异步IO模型：从select到Reactor
我记得刚做网络编程那会儿，总以为IO模型就是个调用接口的事儿。后来在SDK里踩了无数坑，才真正明白——选错IO模型，就好比让法拉利去跑泥巴路。底层的并发优化，往往就卡在这个点上。
4.1 先搞清楚一件事：什么是异步IO？
先说个简单的。同步IO就像你去餐馆排队点餐，你一直站在柜台前等着。异步IO呢，就是你拿个号，然后去旁边玩手机，轮到你服务员叫你。说白了，异步就是“我不等你，你去忙你的，完事通知我”。
但在SDK里，事情没那么理想。操作系统提供的异步能力是有限的，真正落地时还得靠我们自己去“封装”。
4.2 三兄弟的演进：select、poll、epoll
4.2.1 select —— 老大哥，但不够用
select是历史最悠久的IO多路复用接口。它能同时监控多个文件描述符，看哪些可读可写。但它的槽点也很明显：
- 最大连接数有限：通常1024个（由FD_SETSIZE决定），在高并发SDK里根本不不够用。
- 每次都要遍历：内核会把整个fd_set从用户态拷进去再拷出来，O(n)复杂度。
- 数据拷贝开销大：每次调用都要重新构建监控集合。
我做SDK刚起步时想过用select来顶一顶。结果连接数一上500，CPU就开始飚。嗯，这条路走不通。
4.2.2 poll —— 去掉了上限，但遍历还在
poll用链表代替了bitmap，理论上能监控任意数量fd。但它没有解决核心问题——依然需要遍历所有fd。连接越多，效率越差。
你可以认为poll是select的“修复版”，不是“升级版”。它修了小bug，但架构没变。
4.2.3 epoll —— 这才是真正的王者
epoll的出现，本质上解决了两个问题：
- 事件驱动，而非轮询：内核只通知你“哪些fd就绪了”，不再需要全量遍历。
- 零拷贝优化：使用mmap让内核和用户态共享事件表，减少拷贝。
你想想看，如果你的SDK有10000个连接，select要扫描10000次才能确定哪些数据可读。而epoll呢？它会直接告诉你“第3号、第512号、第9998号有数据了”，你去处理就行。这个差距一放大，一个CPU核都扛不住前者。
| 特性 | select | poll | epoll |
|---|---|---|---|
| 最大fd数 | 1024 (受限) | 无上限 | 无上限 |
| 遍历方式 | 全量遍历 | 全量遍历 | 事件驱动（回调） |
| 数据拷贝 | 用户态↔内核态全拷贝 | 用户态↔内核态全拷贝 | mmap共享内存 |
| 适用场景 | 少量连接，原型阶段 | 中小量连接 | 高并发、大量连接 |
核心结论：在IO密集型的SDK里，epoll是Linux平台下唯一正确的选择。其他平台用kqueue（BSD/macOS）或IOCP（Windows），但底层逻辑一样：事件驱动优于轮询。
4.3 IO多路复用的本质
说白了，IO多路复用就是用一个线程管一大堆IO操作。传统的做法是“一个连接一个线程”，连接一多线程数爆炸，上下文切换成本能把你的CPU拖垮。而多路复用，用一个线程+事件循环，扛住成千上万个连接。
形式上，它这样的：
while (1) {
int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
for (int i = 0; i < n; i++) {
handle_event(events[i]);
}
}每次epoll_wait返回一组就绪事件，你逐个处理。这比for (i=0; i<MAX_FD; i++)去轮询，效率天差地别。我在项目中遇到过最极端的情况：旧SDK用poll，连接数2000时CPU占用95%；改用epoll后降到30%出头。方案没变，IO模型换了而已。
4.4 Reactor模式 —— 从轮询到事件分发的架构
epoll解决了“怎么监视”，但没解决“怎么分发”。Reactor模式就是用来干分发这活的。
它的核心思想：
- 一个事件循环（Reactor）：负责监听IO就绪事件。
- 多个Handler（处理者）：每个IO操作对应一个handler。
- 由Reactor决定谁处理：事件来了，Reactor调度对应的handler去干活。
你想想看，这和“老板只看关键节点，具体活分给不同员工”是一样的道理。不做Reactor模式的话，所有事件处理逻辑混在一起，代码很快变成一团乱麻。我之前写过一个SDK，最初就是一股脑儿在epoll_wait的循环里处理所有逻辑，后来加了什么心跳、重连、超时，那个if-else堆得我头皮发麻。改成Reactor后，每种事件单独一个handler，清晰多了。
小提示：Reactor不一定非要用epoll，但epoll+Reactor是Linux平台上的黄金组合。如果要跨平台，可以考虑libevent或libuv这种现成的库，它们把select/poll/epoll/kqueue/IOCP都封装好了。
4.5 一张图看懂异步IO模型演化
下面的SVG图展示了我对本章核心逻辑的理解：从同步阻塞到Reactor模式的完整思路。我建议你收藏这张图，将来做SDK架构设计时拿出来看一看，能省不少绕弯的时间。
4.6 避坑指南：Reactor里的坑我替你踩过了
⚠️ 小心事件处理阻塞事件循环
我曾经在一个SDK里这样写代码：epoll_wait返回后，直接在循环里做网络数据解析、业务逻辑、持久化。结果某次第三方API超时，整个Reactor卡死了5秒钟。其实只要把耗时操作扔到线程池就行。记住：Reactor里只能做非阻塞的、轻量的操作。不够快的，别放在里面。
💡 建议：小而快的事件处理
对于大部分SDK来说，Reactor只负责读取网络数据、拆包、分发给业务层。业务层自己决定是同步还是异步处理。这其实是个“边界意识”——Reactor只做网络侧的事，业务侧的事归业务线程管。
我自己的项目里，一般用epoll+线程池+事件队列。原理就是：Reactor负责把网络事件投递到队列里，线程池的worker从队列里取任务执行。这样既能享受epoll的高效，又不会阻塞事件循环。
好了，第4章就这么多。核心记住三个东西：epoll比select/poll强多少、Reactor怎么分派事件、以及事件循环里别放慢活。下个话题是连接池的配置策略，这里先把基础打牢了，后面的内容才能接得住。