你有没有想过为什么一台普通的服务器Neng同时处理几万甚至几十万条请求？这背后其实藏着一个叫ZuoI/O多路复用的技术魔法，配合Reactor模式，就Neng让单线程也跑得飞快。今天咱们聊聊这套系统，别kan说的是技术，其实它就像一台高效的排队机，把所有连接dou集中在一个“主厨”面前，等着来点菜。

I/O多路复用：一次性盯着千条线

传统的阻塞IO，想想你拿个

Linux里Zui常见的是epoll，它比老式select/poll快得多。核心是两个数据结构：红黑树和就绪链表。当网络卡片收到包时中断唤醒内核，把fd压进链表；应用层只要一次epoll_wait，就Neng拿到全部就绪事件。

int epfd = epoll_create1;
struct epoll_event ev;
ev.events = EPOLLIN | EPOLLET;
ev.data.fd = sock;
epoll_ctl;
struct epoll_event events;
int n = epoll_wait;
for  {
    handle_event;
}

注意！Ru果你把文件描述符关掉，却忘记epoll_ctl，红黑树会堆积成大山，程序死掉。Linux自动帮忙，但跨进程共享描述符还是要手动删除。

边缘触发 vs 水平触发

这两个词听起来hen酷，其实是两种唤醒策略。

水平触发: 每次有数据dou通知你，你Ke以随便读。简单易用，但每次读完dou可Neng 被唤醒——浪费CPU。

边缘触发: 只在状态从无到有时通知一次。读完还没通知，这时你得循环读取直到EAGAIN。这种方式geng节省CPU，但代码稍微麻烦点。

说实话，Ru果你不是写极致性Neng的中间件，用LT够用了。ET适合对延迟极度敏感、资源极限化的场景。

Reactor模式：事件驱动的大厨

I/O多路复用只是工具箱里的工具，而Reactor是把这些工具拼装起来、调配好菜品的方法论。核心思路：事件 → 处理函数。当epoll告诉我们“socket X可读”，我们把这个事件投给相应的handler去处理，而不是让每个socket自己去争抢CPU。

# 简化版 Reactor 循环
while True:
    events = epoll.wait
    for ev in events:
        dispatch   # 根据事件类型调用对应处理器

dispatch内部会根据事件类型分派给Acceptor、Reader/Writer等模块。这种分工让代码既清晰又易于 ；再加上回调或协程，整个系统像流水线一样运转。

为什么叫Reactor？

名字来源于物理学中的“反应器”。当外部刺激到达时它立即产生反应并输出结果。在网络层面就是外部网络事件激活我们的处理器，然后返回响应给客户端。

A Simple Echo Server Demo

import socket
import selectors
sel = selectors.DefaultSelector
def accept:
    conn, addr = sock.accept
    conn.setblocking
    sel.register
def read:
    data = conn.recv
    if data:
        conn.send   # 回声
    else:
        sel.unregister
        conn.close
sock = socket.socket
sock.bind)
sock.listen
sock.setblocking
sel.register
while True:
    for key, mask in sel.select:
        callback = key.data
        callback

kan吧，一个线程，一个epoll，一份代码搞定千万级并发！当然要实现真正高吞吐，还得优化内存、IO缓存、协议解析等细节，但核心架构Yi确定。

Proactor模式：完成通知而非就绪通知

Proactor跟Reactor的区别就在于谁来完成IO操作：

Reactor: 由用户自己读取/写入。当事件来了你去read或者write

Proactor: 操作系统或底层库帮你完成IO，然后把完成结果回传给你。例如Windows IOCP、Linux io_uring.

The great advantage of Proactor is that it frees user space from blocking I/O calls – you just get notified when data is ready to be processed.

Aio + asyncio: Python里的用户态Reactor

import asyncio
async def handle(reader: asyncio.StreamReader,
                 writer: asyncio.StreamWriter):
    data = await reader.read      # 协程挂起，等待EPOLLIN
    if not data:
        writer.close
        await writer.wait_closed
        return
    writer.write                    # 写回去
    await writer.drain
async def main:
    server = await asyncio.start_server(handle,
                                       '127.0.0.1', 8888)
    async with server:
        await server.serve_forever
asyncio.run)

`asyncio`内部就是一个Reactor，只不过它包装成了协程语法，让开发者不用关心底层selector细节，却Neng享受到同样高效的并发模型。它会把每个Socket注册到selector上，当可读/可写时自动唤醒对应协程；而协程在等待时会自动yield，让出CPU给别的任务。

Epoll vs Kqueue vs Select 的性Neng差异 Epoll 在 Linux 上占据主导地位，因为它只维护红黑树和链表，无需遍历全部FD，提高了O检索效率，并且支持ET/ LT两种触发方式，可根据业务需求灵活切换。

方法	核心机制	性Neng特点	适用场景
Select	N+1 系统调用 + 标量遍历	LIFO、低吞吐、高延迟	BBS、邮件服务器
POLL	N 个文件描述符集合扫描	LIFO、稍好一点但仍慢	N/A

C++实现简例

// libuv-style event loop 
uv_loop_t *loop;
uv_tcp_t *server;
void on_new_connection(uv_stream_t *stream,
                       int status) {
   uv_tcp_t *client = new uv_tcp_t;
   uv_tcp_init;
   uv_acceptclient);
   // register read callback...
}
int main {
   loop = uv_default_loop;
   server= new uv_tcp_t;
   uv_tcp_initserver);
   struct sockaddr_in addr;
   uv_ip4_addr;
   uv_tcp_bind);
   uv_listenserver,
            SOMAXCONN,on_new_connection);
   return uv_run;
}

Main‑Sub Reactor 架构：Nginx 与 Netty 的典型Zuo法

Main-Reactor负责接收新连接，把每条新连子交给子Reactors进行后续I/O；子Reactors各自拥有自己的epoll实例，并可Neng绑定一组Worker线程池来Zuo业务计算，从而充分利用多核CPU。Nginx就是这么Zuo：主进程+若干worker，每个workerdou是单线程但拥有自己的epoll；Netty则使用EventLoopGroup+ChannelPipeline组合实现同样效果，只不过在JVM里封装得geng漂亮一点儿。

"咱就是说当并发量暴涨的时候，多进程+子reactorKe以让每颗CPUdou吃饱饭，而不是一直等单线程打卡。"—我朋友老王说的吧。

AIO 与 io_uring 的崛起与局限性

AIO 在Linux上早期通过libaio提供，但API繁琐且不稳定，而且只Neng对文件/套接字Zuo异步操作，不支持完全无阻塞式编程模型。

io_uring 是Zui近Linux v5.x加入的新API，用队列头尾指针和内存映射实现零拷贝异步I/O，再加上完成事件通知机制，让Proactor模式在Linux上变得可行。但由于需要较新的内核版本，在老旧环境下仍然不可用。

Windows IOCP 是Windows平台上的经典实现，在.NET Core里Yi经默认使用，它把I/O操作本身放进后台，由系统完成后再回调用户空间，非常适合高并发服务。

不管是哪种异步API，dou需要细致管理缓冲区生命周期，否则容易出现空指针或内存泄漏——这也是为什么hen多生产项目还是坚持使用传统reacotr+threadpool组合。

---