理论方法

第一种方法

• 最传统的多进程并发模型 (每进来一个新的I/O流会分配一个新的进程管理)

第二种方法

• I/O多路复用 (单个线程，通过记录跟踪每个I/O流(sock)的状态，来同时管理多个I/O流 )
• 尽量多的提高服务器的吞吐能力。
• 在同一个线程里面， 通过拨开关的方式，来同时传输多个I/O流

技术类型

select

• select 会修改传入的参数数组，这个对于一个需要调用很多次的函数，是非常不友好的。
• select 如果任何一个sock(I/O stream)出现了数据，select 仅仅会返回，但是并不会告诉你是那个sock上有数据，于是你只能自己一个一个的找，10几个sock可能还好，要是几万的sock每次都找一遍...
• select 只能监视1024个链接。
• select 不是线程安全的，如果你把一个sock加入到select, 然后突然另外一个线程发现，这个sock不用，要收回，这个select 不支持的，如果你丧心病狂的竟然关掉这个sock, select的标准行为是不可预测的

 poll

• poll 去掉了1024个链接的限制
• poll仍然不是线程安全的， 这就意味着，不管服务器有多强悍也只能在一个线程里面处理一组I/O流。

epoll

• epoll 可以说是I/O 多路复用最新的一个实现，epoll 修复了poll 和select绝大部分问题
• epoll 现在是线程安全的。  
• epoll 现在不仅告诉你sock组里面数据，还会告诉你具体哪个sock有数据，你不用自己去找了。

epoll是Linux内核​为处理大批量文件描述符​而作了改进的poll，是Linux下多路复用IO​接口select/poll的增强版本，它能显著提高程序在大量并发连接​中只有少量活跃的情况下的系统CPU利用率。另一点原因就是获取事件的时候，它无须遍历整个被侦听的描述符集，只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。epoll除了提供select/poll那种IO事件的水平触发（Level Triggered）外，还提供了边缘触发（Edge Triggered），这就使得用户空间程序有可能缓存IO状态，减少epoll_wait/epoll_pwait的调用，提高应用程序效率。

特点：异步，非阻塞

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

详解：​​https://blog.csdn.net/haogenmin/article/details/118527213​​