IO多路复用

1、“I/O多路复用”这个坑爹翻译可能是这个概念在中文里面如此难理解的原因; 2、I/O多路复用，即：I/O multiplexing，这里面的 multiplexing 指的其实是在单个线程通过记录跟踪每一个Sock(I/O流)的状态来同时管理多个I/O流。发明它的原因，是尽量多的提高服务器的吞吐能力； 3、可以理解成是一种“时分复用”；

IO 复用例子说明

假设你是一个机场的空管，你需要管理到你机场的所有的航线， 包括进港，出港，有些航班需要放到停机坪等待，有些航班需要去登机口接乘客。

你会怎么做?

最简单的做法，就是你去招一大批空管员，然后每人盯一架飞机， 从进港，接客，排位，出港，航线监控，直至交接给下一个空港，全程监控。

那么问题就来了：

很快你就发现空管塔里面聚集起来一大票的空管员，交通稍微繁忙一点，新的空管员就已经挤不进来了。空管员之间需要协调，屋子里面就1,2个人的时候还好，几十号人以后 ，基本上就成菜市场了。

空管员经常需要更新一些公用的东西，比如起飞显示屏，比如下一个小时后的出港排期，最后你会很惊奇的发现，每个人的时间最后都花在了抢这些资源上。

现实上我们的空管同时管几十架飞机稀松平常的事情:

他们怎么做的呢？这个东西叫flight progress strip。

每一个块代表一个航班，不同的槽代表不同的状态，然后一个空管员可以管理一组这样的块（一组航班），而他的工作，就是在航班信息有新的更新的时候，把对应的块放到不同的槽子里面。

这个东西现在还没有淘汰哦，只是变成电子的了而已。

是不是觉得一下子效率高了很多，一个空管塔里可以调度的航线可以是前一种方法的几倍到几十倍。

如果你把每一个航线当成一个Sock(I/O 流),空管当成你的服务端Sock管理代码的话.

第一种方法就是最传统的多进程并发模型 (每进来一个新的I/O流会分配一个新的进程管理。) 第二种方法就是I/O多路复用 (单个线程，通过记录跟踪每个I/O流(sock)的状态，来同时管理多个I/O流 。)

其实I/O多路复用这个坑爹翻译可能是这个概念在中文里面如此难理解的原因。所谓的I/O多路复用在英文中其实叫 I/O multiplexing.

重要的事情再说一遍： I/O multiplexing 这里面的 multiplexing 指的其实是在单个线程通过记录跟踪每一个Sock(I/O流)的状态(对应空管塔里面的Fight progress strip槽)来同时管理多个I/O流. 发明它的原因，是尽量多的提高服务器的吞吐能力。

是不是听起来好拗口，看个图就懂了:

最初级的I/O复用

所谓的I/O复用，就是多个I/O可以复用一个进程。

采用非阻塞的模式，当一个连接过来时，我们不阻塞住，这样一个进程可以同时处理多个连接了。

比如一个进程接受了10000个连接，这个进程每次从头到尾的问一遍这10000个连接：“有I/O事件没？有的话就交给我处理，没有的话我一会再来问一遍。” 然后进程就一直从头到尾问这10000个连接，如果这1000个连接都没有I/O事件，就会造成CPU的空转，并且效率也很低，不好不好。

升级版的I/O复用

上面虽然实现了基础版的I/O复用，但是效率太低了。于是伟大的程序猿们日思夜想的去解决这个问题...终于！

我们能不能引入一个代理，这个代理可以同时观察许多I/O流事件呢？

当没有I/O事件的时候，这个进程处于阻塞状态；当有I/O事件的时候，这个代理就去通知进程醒来？

于是，早期的程序猿们发明了两个代理---select、poll。

select、poll代理的原理是这样的：

当连接有I/O流事件产生的时候，就会去唤醒进程去处理。 但是进程并不知道是哪个连接产生的I/O流事件，于是进程就挨个去问：“请问是你有事要处理吗？”......问了99999遍，哦，原来是第100000个进程有事要处理。那么，前面这99999次就白问了，白白浪费宝贵的CPU时间片了！痛哉，惜哉...

1. select是第一个实现 (1983 左右在BSD里面实现)
2. 1997年实现了poll.
3. select与poll原理是一样的，只不过select只能观察1024个连接，poll可以观察无限个连接。

上面看了，select、poll因为不知道哪个连接有I/O流事件要处理，性能也挺不好的。

那么，如果发明一个代理，每次能够知道哪个连接有了I/O流事件，不就可以避免无意义的空转了吗？

于是，超级无敌、闪闪发光的epoll，于5年以后, 在2002年被大神 Davide Libenzi 发明出来了。

epoll IO多路复用

epoll代理的原理是这样的：

当连接有I/O流事件产生的时候，epoll就会去告诉进程哪个连接有I/O流事件产生，然后进程就去处理这个进程。如此，多高效！

epoll 可以说是I/O 多路复用最新的一个实现，epoll 修复了poll 和select绝大部分问题, 比如：

epoll 现在是线程安全的。 epoll 现在不仅告诉你sock组里面数据，还会告诉你具体哪个sock有数据，你不用自己去找了。

可是epoll 有个致命的缺点，只有linux支持。于是其他的平台实现类型的多路复用，比如BSD上面对应的是kqueue， win下对应的iocp。

epoll和select/poll区别

简单说epoll和select/poll最大区别是

1. epoll内部使用了mmap共享了用户和内核的部分空间，避免了数据的来回拷贝
2. epoll基于事件驱动，epoll_ctl注册事件并注册callback回调函数，epoll_wait只返回发生的事件避免了像select和poll对事件的整个轮寻操作。

3. Nginx 异步，非阻塞，IO多路复用

Nginx 这样出众，正是他采用了异步，非阻塞，IO多路复用。

Nginx之前是单进程的。看下他的进程。1个master进程，2个work进程。

`$ pstree |grep nginx`
`|-+=  81666 root nginx: master process nginx`
`|  |---  82500 nobody nginx: worker process`
`| \---  82501 nobody nginx: worker process`

每进来一个request，会有一个worker进程去处理。但不是全程的处理，处理到什么程度呢？处理到可能发生阻塞的地方，比如向上游（后端）服务器转发request，并等待请求返回。那么，这个处理的worker不会这么傻等着，他会在发送完请求后，注册一个事件：“如果upstream返回了，告诉我一声，我再接着干”。于是他就休息去了。这就是异步。此时，如果再有request 进来，他就可以很快再按这种方式处理。这就是非阻塞和IO多路复用。而一旦上游服务器返回了，就会触发这个事件，worker才会来接手，这个request才会接着往下走。这就是异步回调。