IO多路复用

事件驱动模型还有另外一个名字，而且更加出名的名字：io多路复用。

关于I/O多路复用(又被称为“事件驱动”)，首先要理解的是，操作系统为你提供了一个功能，当你的某个socket可读或者可写的时候，它可以给你一个通知。这样当配合非阻塞的socket使用时，只有当系统通知我哪个描述符可读了，我才去执行read操作，可以保证每次read都能读到有效数据而不做纯返回-1和EAGAIN的无用功。写操作类似。操作系统的这个功能通过select/poll/epoll/kqueue之类的系统调用函数来使用，这些函数都可以同时监视多个描述符的读写就绪状况，这样，多个描述符的I/O操作都能在一个线程内并发交替地顺序完成，这就叫I/O多路复用，这里的“复用”指的是复用同一个线程。

作者：晨随 链接：https://www.zhihu.com/question/28594409/answer/52763082 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

事件驱动不是无敌的，在事件驱动模型中，处理事件的进程一定是单线程的。

在现代工业中我们会面临两个问题：

1. 单线程模型不能有阻塞，一旦发生任何阻塞（包括计算机计算延迟）都会使得这个模型不如多线程。另外，单线程模型不能很好的利用多核cpu。
2. 既然不能有阻塞，那我们只有用多线程去做异步io，那马上就会面临回掉地狱。

为了解决我上述说的两个问题人们做出了一些改进：

1. 利用多进程，每个进程单条线程去利用多核CPU。但是这又引入了新的问题：进程间状态共享和通信。但是对于提升的性能来说，可以忽略不计。
2. 发明了协程。

作者：方正 链接：https://www.zhihu.com/question/28594409/answer/345897182 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

阻塞式I/O和I/O复用，两个阶段都阻塞，那区别在哪里呢？就在于第三节讲述的Selector，虽然第一阶段都是阻塞，但是阻塞式I/O如果要接收更多的连接，就必须创建更多的线程。I/O复用模式下在第一个阶段大量的连接统统都可以过来直接注册到Selector复用器上面，同时只要单个或者少量的线程来循环处理这些连接事件就可以了，一旦达到“就绪”的条件，就可以立即执行真正的I/O操作。这就是I/O复用与传统的阻塞式I/O最大的不同。也正是I/O复用的精髓所在。

从应用进程的角度去理解始终是阻塞的，等待数据和将数据复制到用户进程这两个阶段都是阻塞的。这一点我们从应用程序是可以清楚的得知，比如我们调用一个以I/O复用为基础的NIO应用服务。调用端是一直阻塞等待返回结果的。
从内核的角度等待Selector上面的网络事件就绪，是阻塞的，如果没有任何一个网络事件就绪则一直等待直到有一个或者多个网络事件就绪。但是从内核的角度考虑，有一点是不阻塞的，就是复制数据，因为内核不用等待，当有就绪条件满足的时候，它直接复制，其余时间在处理别的就绪的条件。这也是大家一直说的非阻塞I/O。实际上是就是指的这个地方的非阻塞。

作者：程序人生
链接：https://www.zhihu.com/question/28594409/answer/1362084241
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

I/O Multiplexing 的命名中 multiplexing 来自于通讯领域：在一个信道上传输多路信号或者数据流的技术[1]。
Linux 下的事件驱动的 I/O 编程之所以需要 multiplexing，是因为对 I/O ready 事件的通知是以一个监听集合为单位完成的。大家在用 select, poll, 和 epoll 时都是先创建这么一个集合，然后统一的 wait，一次 wait 可以获知多个 fd 的 I/O 事件。所以 multiplex 的是监听集合，并非 I/O 本身。实际发生操作的 I/O fd 都是可以并发读写互不干扰的，不存在 multiplexing 的问题。

其实多路复用，redis使用的是线程模型的多路复用，使用一个线程去监听多个io的操作，其实真正的多路复用，指的是IO上面，同时进行多个请求的包传输，这个是真正的多路复用

作者：安江泽
链接：https://www.zhihu.com/question/28594409/answer/146490923
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。