IO

最初级的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对事件的整个轮寻操作。

    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才会接着往下走。这就是异步回调。