Blog.7 IO多路复用
引言
结合文章我读过的最好的epoll讲解，认识select和epoll的基本工做原理。html
假设：启动一个WEB服务，服务端每accept一个链接，在内核中就会生成一个相应的文件描述符。如今服务器成功创建了10个链接，咱们须要知道其中哪些链接发送过来了新的数据，而后对其进行处理和响应。linux
经过一个基本的循环，咱们就能够实现：git
while true:
for x in open_connections:
if has_new_input(x):
process_input(x)
这也是咱们经常使用的“轮询”模式，不停的询问服务器“数据是否已经准备就绪”，而这很是浪费CPU的时间。github
为了不CPU的空转（无限的for循环），系统引入了一个select的代理。这个代理比较厉害，能够同时观察许多流的I/O事件。在空闲的时候，会把当前线程阻塞掉。当有一个或多个流有I/O事件时，就从阻塞态中醒来。因而，代码调整成这样：golang
while true:
select(open_connections)
for x in open_connections:
if has_new_input(x):
process_input(x)
调整以后，若是没有I/O事件产生，咱们的程序就会阻塞在select处。但这样依然有个问题：咱们从select那里仅仅知道，有I/O事件发生了，但却并不知道是那几个流（可能有一个，多个，甚至所有），咱们只能无差异进行轮询，找出能读出或写入数据的流，对他们进行操做。使用select，咱们有O(n)的无差异轮询复杂度，同时处理的流越多，每一次无差异轮询时间就越长。redis
epoll被用来优化select的问题，它会将哪一个流发生了怎样的I/O事件通知咱们。此时咱们对这些流的操做都是有意义的（复杂度下降到了O(k)，k为产生I/O事件流的个数）。最后，代码调整了这样：编程
while true:
active_conns = epoll(open_connections)
for x in active_conns:
process_input(x)
I/O多路复用
多路复用的本质是同步非阻塞I/O，多路复用的优点并非单个链接处理的更快，而是在于能处理更多的链接。相似服务对外提供了一个批量接口。服务器
I/O编程过程当中，须要同时处理多个客户端接入请求时，能够利用多线程或者I/O多路复用技术进行处理。 I/O多路复用技术经过把多个I/O的阻塞复用到同一个select阻塞上，一个进程监视多个描述符，一旦某个描述符就位， 可以通知程序进行读写操做。由于多路复用本质上是同步I/O，都须要应用程序在读写事件就绪后本身负责读写。 最大的优点是系统开销小，不须要建立和维护额外线程或进程。多线程
结合多路复用，来看一下异步非阻塞I/O:并发
对比异步非阻塞I/O，读请求会当即返回，说明请求已经成功发起，应用程序不被阻塞，继续执行其它处理操做。当read响应到达，将数据拷贝到用户空间，产生信号或者执行一个基于线程回调函数完成I/O处理。应用程序不用在多个任务之间切换。
能够看出，阻塞I/O在wait for data和copy data from kernel to user两个阶段都是阻塞的。而只有异步I/O的receivefrom是不阻塞的。
epoll
epoll的系统调用方法包括：epoll_create、epoll_ctl、epoll_wait，
-
epoll_create建立一个epoll对象：
epollfd = epoll_create()
-
epoll_ctl往epoll对象中增长/删除某一个流的某一个事件：
// 有缓冲区内有数据时epoll_wait返回 epoll_ctl(epollfd, EPOLL_CTL_ADD, socket, EPOLLIN); //缓冲区可写入时epoll_wait返回 epoll_ctl(epollfd, EPOLL_CTL_DEL, socket, EPOLLOUT);
-
epoll_wait等待直到注册的事件发生。
Go语言
go语法上提供了select语句，来实现多路复用。select语句中能够监听多个channel，只要其中任意一个channel有事件返回，select就会返回。不然，程序会一直阻塞在select上。经过结合default，还能够实现反复轮询的效果。
select {
case <-tick:
// Do nothing.
case <-abort:
fmt.Println("Launch aborted!")
return
}
netpoll_epoll.go中实现的epoll方法，依次经过调用netpollinit、netpollopen、netpoll来实现。多是调用太清晰了，整个文件除了下面的注释外，再也没有别的有效注释了。
// polls for ready network connections
// returns list of goroutines that become runnable
func netpoll(block bool) *g {}
epoll的LT和ET模式
epoll的两种触发模式：Level triggered和Edge triggered
二者的差别在于level-trigger模式下只要某个socket处于readable/writable状态，不管何时进行epoll_wait都会返回该socket。而edge-trigger模式下只有某个socket从unreadable变为readable或从unwritable变为writable时，epoll_wait才会返回该socket。
因此, 在epoll的ET模式下, 正确的读写方式为:
- 读: 只要可读, 就一直读, 直到返回0, 或者 errno = EAGAIN
- 写: 只要可写, 就一直写, 直到数据发送完, 或者 errno = EAGAIN
关于这两种模式，博客Epoll is fundamentally broken 1/2也作了解释，它经过内核负载均衡accept()的例子来进行说明。这里也尝试简单介绍一下，由于例子读起来确实有趣，也方便咱们加深理解。
在开发一个高吞吐量的HTTP Server(服务大量的短链接)时，由于请求量很是大，咱们但愿充分利用计算机多核资源，将accept操做分配到不一样的核来并发处理。但想要实现链接的负载均衡，直到内核4.5版本才变成可能。
水平触发 - 不须要的唤醒
一个天真的解决办法是：咱们全局建立一个epoll对象，多个工做线程来同时wait它。可是level triggere模式存在“惊群现象”（前提：没有给epoll指定具体的flag），对于每个到来的新链接，全部的工做线程都会被唤醒。
Kernel： 接收到一个新链接 Kernel： 通知正在等待的线程`Thread A`和`Thread B` Thread A： epoll_wait()返回. Thread B： epoll_wait()返回. Thread A： 执行`accept()`, 操做成功. Thread B： 执行`accept()`, 操做失败，返回`EAGAIN`.
在这个过程当中，唤醒Thread B是彻底没有必要的，而且浪费了系统资源。因此，level-triggered模式在水平扩展上很是差。
边缘触发 - 不须要的唤醒和饥饿
咱们已经介绍了level-triggered模式的问题，那么edge-triggered模式会不会作到更好呢？
并非，下面是可能的运行状况：
Kernel： 收到一个新链接，此时线程`A`和`B`都在等待。由于如今是"edge-triggered"模式，因此仅仅会有一个线程被通知，假设是`A`. Thread A： `epoll_wait()`返回. Thread A： 执行`accept()`, 操做成功. Kernel： accpet队列变空, `event-triggered socket`状态由"readable"变为"non readable" Kernel： 接收到第二个链接. Kernel： 如今只剩下线程`B`在执行`epoll_wait()`. 因而唤醒`B`. Thread A： 继续执行`accept()`，本来但愿返回`EAGAIN`，可是返回了第二个链接 Thread B： 执行`accept()`, 返回`EAGAIN`. Thread A： 继续执行`accept()`, 返回`EAGAIN`.
上述过程当中，B的唤醒是彻底不须要的。并且，B会感到很是困惑。此外，edge-triggered模式也很难避免线程饥饿的状况
Kernel： 接收到两个链接，此时`A`和`B`都在等待. 假设`A`收到通知. Thread A： `epoll_wait()`返回. Thread A： 执行`accept()`, 操做成功 Kernel： 接收到第3个链接.`event-triggered socket`是"readable"状态, 如今依然是"readable". Thread A： 必须执行`accept()`, 但愿返回`EGAIN`, 可是返回了第三个链接. Kernel： 接收到第4个链接. Thread A： 继续执行`accept()`, 但愿返回`EGAIN`, 可是返回了第四个链接.
在这个例子中，event-triggered socket状态只是从non-readable变为了readable。由于在edge-trigger模式下，内核只会唤醒其中一个线程。因此，例子中全部的链接都会被线程A处理，负载均衡没法实现。
SELECT
select和poll相似，主要操做包括两步：
- 传递给它们一个文件描述符集合
- 它们返回集合中的哪些能够进行读/写操做
程序调用select将会被阻塞，直到存在可用的文件描述符，或者执行超时。当返回成功时，各个fd_set集合会被修改成仅包含可用的文件描述符。因此，每次调用select还须要重置它的参数列表。
函数解释：
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
nfds被设置为三个集合中最高的文件描述符数值+1，这代表每一个集合中的文件描述符都会被检查，直到达到这个限制。
三个独立的文件描述符集合会被监控：readfds中的文件描述符是否可读，writefds是否有空间可写，exceptfds是否异常的状况。在函数退出时，文件描述符集合会被修改，来标识被改变状态的文件标识符。若是没有文件描述符须要被监控，这三个集合均可以指定为NULL。
当这三个集合都为NULL，而timeval不为空时，等价于系统执行sleep的效果。若是timeval结构体的两个字段都为0，就相似于轮询的效果了。如下是timeval的结构体：
struct timeval {
long tv_sec; /* seconds */
long tv_usec; /* microseconds */
};
在select中有4个宏函数被提供：FD_ZERO()用于清除一个集合，FD_SET()和FD_CLR()用来增长和删除一个给定的描述符，FD_ISSET()用来检查文件描述符是不是集合的一部分。
为何咱们在io操做中不使用select，而选择使用epoll？
节选自Async IO on Linux: select, poll, and epoll的描述：
On each call to select() or poll(), the kernel must check all of the specified file descriptors to see if they are ready. When monitoring a large number of file descriptors that are in a densely packed range, the timed required for this operation greatly outweights [the rest of the stuff they have to do]
参考文章：