IO 多路复用

在 Linux 系统之中有一个核心武器：epoll 池，在高并发的，高吞吐的 IO 系统中常常见到 epoll 的身影。

在 Go 里最核心的是 Goroutine ，也就是所谓的协程，协程最妙的一个实现就是异步的代码长的跟同步代码一样。比如在 Go 中，网络 IO 的 read，write 看似都是同步代码，其实底下都是异步调用，一般流程是：

write ( /* IO 参数 */ )

请求入队

等待完成

后台 loop 程序

发送网络请求

唤醒业务方

Go 合协程在网络 IO 上实现了异步流程的同步代码化。核心就是用 epoll 池来管理网络 fd 。

实现形式上，后台的程序只需要 1 个就可以负责管理多个 fd 句柄，负责应对所有的业务方的 IO 请求。这种一对多的 IO 模式我们就叫做 IO 多路复用。

多路是指？ 多个业务方（句柄）并发下来的 IO 。

复用是指？ 复用这一个后台处理程序。

站在 IO 系统设计人员的角度，业务方咱们没办法提要求，因为业务是上帝，只有你服从的份，他们要创建多个 fd，那么你就需要负责这些 fd 的处理，并且最好还要并发起来。

业务方没法提要求，那么只能要求后台 loop 程序了！

要求什么呢？快！快！快！这就是最核心的要求，处理一定要快，要给每一个 fd 通道最快的感受，要让每一个 fd 觉得，你只在给他一个人跑腿。

那有人又问了，那我一个 IO 请求（比如 write ）对应一个线程来处理，这样所有的 IO 不都并发了吗？是可以，但是有瓶颈，线程数一旦多了，性能是反倒会差的。

最朴实的实现方式？

我不用任何其他系统调用，能否实现 IO 多路复用？

可以的。那么写个 for 循环，每次都尝试 IO 一下，读/写到了就处理，读/写不到就 sleep 下。这样我们不就实现了 1 对多的 IO 多路复用嘛。

while True:

for each 句柄数组 {

read/write(fd, /* 参数 */)

}

sleep(1s)

慢着，有个问题，上面的程序可能会被卡死在第三行，使得整个系统不得运行，为什么？

默认情况下，我们没有加任何参数 create 出的句柄是阻塞类型的。我们读数据的时候，如果数据还没准备好，是会需要等待的，当我们写数据的时候，如果还没准备好，默认也会卡住等待。所以，在上面伪代码第三行是可能被直接卡死，而导致整个线程都得到不到运行。

举个例子，现在有 1，2，3 这 3 个句柄，现在 1 读写都没有准备好，这样 read/write(11, /*参数*/) 就会被卡住，但 2，3 这两个句柄都准备好了，那遍历句柄数组 1，2，13 的时候就会卡死在前面，后面 2，3 则得不到运行。这不符合我们的预期，因为我们 IO 多路复用的 loop 线程是公共服务，不能因为一个 fd 就直接瘫痪。

那这个问题怎么解决？

只需要把 fd 都设置成非阻塞模式。这样 read/write 的时候，如果数据没准备好，返回 EAGIN 的错误即可，不会卡住线程，从而整个系统就运转起来了。比如上面句柄 1 还未就绪，那么 read/write(11, /*参数*/) 不会阻塞，只会报个 EAGIN 的错误，这种错误需要特殊处理，然后 loop 线程可以继续执行 2，3 的读写。

以上就是最朴实的 IO 多路复用的实现了。但是好像在生产环境没见过这种 IO 多路复用的实现？为什么？

因为还不够高级。for 循环每次要定期 sleep 1s，这个会导致吞吐能力极差，因为很可能在刚好要 sleep 的时候，所有的 fd 都准备好 IO 数据，而这个时候却要硬生生的等待 1s，可想而知。。。

那有同学又要质疑了，那 for 循环里面就不 sleep 嘛，这样不就能及时处理了吗？

及时是及时了，但是 CPU 估计要跑飞了。不加 sleep ，那在没有 fd 需要处理的时候，估计 CPU 都要跑到 100% 了。这个也是无法接受的。

纠结了，那 sleep 吞吐不行，不 sleep 浪费 cpu，怎么办？

这种情况用户态很难有所作为，只能求助内核来提供机制协助来。因为内核才能及时的管理这些通知和调度。

我们再梳理下 IO 多路复用的需求和原理。IO 多路复用就是 1 个线程处理 多个 fd 的模式。我们的要求是：这个 “1” 就要尽可能的快，避免一切无效工作，要把所有的时间都用在处理句柄的 IO 上，不能有任何空转，sleep 的时间浪费。

有没有一种工具，我们把一箩筐的 fd 放到里面，只要有一个 fd 能够读写数据，后台 loop 线程就要立马唤醒，全部马力跑起来。其他时间要把 cpu 让出去。

能做到吗？能，这种需求只能内核提供机制满足你。

Linux 内核提出了解决方案

是的，想要不用 sleep 这种辣眼睛的实现，Linux 内核必须出手了，毕竟 IO 的处理都是内核之中，数据好没好内核最清楚。

内核一口气提供了 3 种工具 select，poll，epoll 。

为什么有 3 种？他们三种的区别是什么？

1. select 时间复杂度O(n)

select仅仅知道，有I/O事件发生，却并不知道是哪那几个流（可能有一个，多个，甚至全部），我们只能无差别轮询所有流，找出能读出数据，或者写入数据的流，对他们进行操作。所以select具有O(n)的无差别轮询复杂度，同时处理的流越多，无差别轮询时间就越长。

2. poll 时间复杂度O(n)

poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，但是它没有最大连接数的限制，原因是它是基于链表来存储的.

3. epoll 时间复杂度O(1)

epoll可以理解为event poll，不同于忙轮询和无差别轮询，epoll会把哪个流发生了怎样的I/O事件通知我们。所以我们说epoll实际上是事件驱动（每个事件关联上fd） ，此时我们对这些流的操作都是有意义的。（复杂度降低到了O(1)）

select，poll，epoll都是IO多路复用的机制。I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持，其中epoll是Linux所特有，而select则应该是POSIX所规定，一般操作系统均有实现

epoll 池原理

下面我们看一下 epoll 池的使用和原理。 epoll本质上 事件驱动

epoll 涉及的系统调用

epoll 的使用非常简单，只有下面 3 个系统调用。

epoll_create

epollctl

epollwait

就这？是的，就这么简单。

• epollcreate 负责创建一个池子，一个监控和管理句柄 fd 的池子；
• epollctl 负责管理这个池子里的 fd 增、删、改；
• epollwait 就是负责打盹的，让出 CPU 调度，但是只要有“事”，立马会从这里唤醒；

epoll 高效的原理

Linux 下，epoll 一直被吹爆，作为高并发 IO 实现的秘密武器。其中原理其实非常朴实：epoll 的实现几乎没有做任何无效功。 我们从使用的角度切入来一步步分析下。

首先，epoll 的第一步是创建一个池子。这个使用 epoll_create 实现

epollfd = epoll_create(1024);

if (epollfd == -1) {

perror("epoll_create");

exit(EXIT_FAILURE);

}

这个池子对我们来说是黑盒，这个黑盒是用来装 fd 的，我们暂不纠结其中细节。我们拿到了一个 epollfd ，这个 epollfd 就能唯一代表这个 epoll 池。

然后，我们就要往这个 epoll 池里放 fd 了，这就要用到 epoll_ctl 了

if (epoll_ctl(epollfd, EPOLL_CTL_ADD, 11, &ev) == -1) {

perror("epoll_ctl: listen_sock");

exit(EXIT_FAILURE);

}

我们就就把句柄 1 放到这个池子里了，op（EPOLL_CTL_ADD）表明操作是增加、修改、删除，event 结构体可以指定监听事件类型，可读、可写。

1. 第一个跟高效相关的问题来了，添加 fd 进池子也就算了，如果是修改、删除呢？怎么做到时间快？

这里就涉及到你怎么管理 fd 的数据结构了。

最常见的思路：用 list ，可以吗？功能上可以，但是性能上拉垮。list 的结构来管理元素，时间复杂度都太高 O(n)，每次要一次次遍历链表才能找到位置。池子越大，性能会越慢。

2. 那有简单高效的数据结构吗？

有，红黑树。Linux 内核对于 epoll 池的内部实现就是用红黑树的结构体来管理这些注册进程来的句柄 fd。红黑树是一种平衡二叉树，时间复杂度为 O(log n)，就算这个池子就算不断的增删改，也能保持非常稳定的查找性能。

3. 现在思考第二个高效的秘密：怎么才能保证数据准备好之后，立马感知呢？

epoll_ctl 这里会涉及到一点。秘密就是：回调的设置。在 epoll_ctl 的内部实现中，除了把句柄结构用红黑树管理，另一个核心步骤就是设置 poll 回调。

4. 思考来了：poll 回调是什么？怎么设置？

先说说 file_operations->poll 是什么？

Linux 设计成一切皆是文件的架构，这个不是说说而已，而是随处可见。实现一个文件系统的时候，就要实现这个文件调用，这个结构体用 struct file_operations 来表示。这个结构体有非常多的函数，我精简了一些，如下：

struct file_operations {

ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);

ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);

__poll_t (*poll) (struct file *, struct poll_table_struct *);

int (*open) (struct inode *, struct file *);

int (*fsync) (struct file *, loff_t, loff_t, int datasync);

// ....

};

你看到了 read，write，open，fsync，poll 等等，这些都是对文件的定制处理操作，对于文件的操作其实都是在这个框架内实现逻辑而已，比如 ext2 如果有对 read/write 做定制化，那么就会是 ext2_read，ext2_write，ext4 就会是 ext4_read，ext4_write。在 open 具体“文件”的时候会赋值对应文件系统的 file_operations 给到 file 结构体。

那我们很容易知道 read 是文件系统定制 fd 读的行为调用，write 是文件系统定制 fd 写的行为调用，file_operations->poll 呢？

这个是定制监听事件的机制实现。通过 poll 机制让上层能直接告诉底层，我这个 fd 一旦读写就绪了，请底层硬件（比如网卡）回调的时候自动把这个 fd 相关的结构体放到指定队列中，并且唤醒操作系统。

举个例子：网卡收发包其实走的异步流程，操作系统把数据丢到一个指定地点，网卡不断的从这个指定地点掏数据处理。请求响应通过中断回调来处理，中断一般拆分成两部分：硬中断和软中断。poll 函数就是把这个软中断回来的路上再加点料，只要读写事件触发的时候，就会立马通知到上层，采用这种事件通知的形式就能把浪费的时间窗就完全消失了。

划重点：这个 poll 事件回调机制则是 epoll 池高效最核心原理。

划重点：epoll 池管理的句柄只能是支持了 file_operations->poll 的文件 fd。换句话说，如果一个“文件”所在的文件系统没有实现 poll 接口，那么就用不了 epoll 机制。

poll 怎么设置？

在 epoll_ctl 下来的实现中，有一步是调用 vfs_poll 这个里面就会有个判断，如果 fd 所在的文件系统的 file_operations 实现了 poll ，那么就会直接调用，如果没有，那么就会报告响应的错误码。

static inline __poll_t vfs_poll(struct file *file, struct poll_table_struct *pt)

{

if (unlikely(!file->f_op->poll))

return DEFAULT_POLLMASK;

return file->f_op->poll(file, pt);

}

你肯定好奇 poll 调用里面究竟是实现了什么？

总结概括来说：挂了个钩子，设置了唤醒的回调路径。epoll 跟底层对接的回调函数是：ep_poll_callback，这个函数其实很简单，做两件事情：

1. 把事件就绪的 fd 对应的结构体放到一个特定的队列（就绪队列，ready list）；

2. 唤醒 epoll ，活来啦！

当 fd 满足可读可写的时候就会经过层层回调，最终调用到这个回调函数，把对应 fd 的结构体放入就绪队列中，从而把 epoll 从 epoll_wait 出唤醒。

这个对应结构体是什么？

结构体叫做 epitem ，每个注册到 epoll 池的 fd 都会对应一个。

就绪队列很高级吗？

就绪队列就简单了，因为没有查找的需求了呀，只要是在就绪队列中的 epitem ，都是事件就绪的，必须处理的。所以就绪队列就是一个最简单的双指针链表。

小结下：epoll 之所以做到了高效，最关键的三点：

1. 内部管理 fd 使用了高效的红黑树结构管理，做到了增删改之后性能的优化和平衡；

2. epoll 池添加 fd 的时候，调用 file_operations->poll ，把这个 fd 就绪之后的回调路径安排好。通过事件通知的形式，做到最高效的运行；

3. epoll 池核心的两个数据结构：红黑树和就绪列表。红黑树是为了应对用户的增删改需求，就绪列表是 fd 事件就绪之后放置的特殊地点，epoll 池只需要遍历这个就绪链表，就能给用户返回所有已经就绪的 fd 数组；

哪些 fd 可以用 epoll 来管理？

再来思考另外一个问题：由于并不是所有的 fd 对应的文件系统都实现了 poll 接口，所以自然并不是所有的 fd 都可以放进 epoll 池，那么有哪些文件系统的 file_operations 实现了 poll 接口？

首先说，类似 ext2，ext4，xfs 这种常规的文件系统是没有实现的，换句话说，这些你最常见的、真的是文件的文件系统反倒是用不了 epoll 机制的。

那谁支持呢？

最常见的就是网络套接字：socket 。网络也是 epoll 池最常见的应用地点。Linux 下万物皆文件，socket 实现了一套 socket_file_operations 的逻辑（ net/socket.c ）：

static const struct file_operations socket_file_ops = {

.read_iter = sock_read_iter,

.write_iter = sock_write_iter,

.poll = sock_poll,


};

我们看到 socket 实现了 poll 调用，所以 socket fd 是天然可以放到 epoll 池管理的。

还有吗？
有的，其实 Linux 下还有两个很典型的 fd ，常常也会放到 epoll 池里。

eventfd：eventfd 实现非常简单，故名思义就是专门用来做事件通知用的。使用系统调用 eventfd 创建，这种文件 fd 无法传输数据，只用来传输事件，常常用于生产消费者模式的事件实现；

timerfd：这是一种定时器 fd，使用 timerfd_create 创建，到时间点触发可读事件；

小结一下：

1. ext2，ext4，xfs 等这种真正的文件系统的 fd ，无法使用 epoll 管理；

2. socket fd，eventfd，timerfd 这些实现了 poll 调用的可以放到 epoll 池进行管理；

其实，在 Linux 的模块划分中，eventfd，timerfd，epoll 池都是文件系统的一种模块实现。

思考

前面我们已经思考了很多知识点，有一些简单有趣的知识点，提示给读者朋友，这里只抛砖引玉。

1. 单核 CPU 能实现并行吗？ 不行。
2. 单线程能实现高并发吗？ 可以。
3. 那并发和并行的区别是？ 一个看的是时间段内的执行情况，一个看的是时间时刻的执行情况。
4. 单线程如何做到高并发？ IO 多路复用呗，今天讲的 epoll 池就是了。
5. 单线程实现并发的有开源的例子吗？
   redis，nginx 都是非常好的学习例子。当然还有我们 Golang 的 runtime 实现也尽显高并发的设计思想。

总结

1. IO 多路复用的原始实现很简单，就是一个 1 对多的服务模式，一个 loop 对应处理多个 fd ；
2. IO 多路复用想要做到真正的高效，必须要内核机制提供。因为 IO 的处理和完成是在内核，如果内核不帮忙，用户态的程序根本无法精确的抓到处理时机；
3. fd 记得要设置成非阻塞的哦，切记；
4. epoll 池通过高效的内部管理结构，并且结合操作系统提供的 poll 事件注册机制，实现了高效的 fd 事件管理，为高并发的 IO 处理提供了前提条件；
5. epoll 全名 eventpoll，在 Linux 内核下以一个文件系统模块的形式实现，所以有人常说 epoll 其实本身就是文件系统也是对的；
6. socketfd，eventfd，timerfd 这三种”文件“fd 实现了 poll 接口，所以网络 fd，事件fd，定时器fd 都可以使用 epoll_ctl 注册到池子里。我们最常见的就是网络fd的多路复用；
7. ext2，ext4，xfs 这种真正意义的文件系统反倒没有提供 poll 接口实现，所以不能用 epoll 池来管理其句柄。那文件就无法使用 epoll 机制了吗？不是的，有一个库叫做 libaio ，通过这个库我们可以间接的让文件使用 epoll 通知事件，以后详说，此处不表；