Apache面对高并发，为什么很无力？
Apache处理一个请求是同步阻塞的模式
每到达一个请求，Apache都会去fork一个子进程去处理这个请求，直到这个请求处理完毕。
面对低并发，这种模式没什么缺点，但是，面对高并发，就是这种模式的软肋了。
-
1个客户端占用1个进程，那么，进程数量有多少，并发处理能力就有多少，但操作系统可以创建的进程数量是有限的。
-
多进程就会有进程间的切换问题，而进程间的切换调度势必会造成CPU的额外消耗。当进程数量达到成千上万的时候，进程间的切换就占了CPU大部分的时间片，而真正进程的执行反而占了CPU的一小部分，这就得不偿失了。
Nginx何以处理高并发的？
传统的服务器模型就是这样，因为其同步阻塞的多进程模型，无法面对高并发。
那么，有没有一种方式，可以让我们在一个进程处理所有的并发I/O呢？
答案是有的，这就是I/O复用技术。
什么是 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时间片了！
上面看了，select、poll因为不知道哪个连接有I/O流事件要处理，性能也挺不好的。
那么，如果发明一个代理，每次能够知道哪个连接有了I/O流事件，不就可以避免无意义的空转了吗？
于是就诞生了 epoll
epoll代理的原理是这样的:
当连接有I/O流事件产生的时候，epoll就会去告诉进程哪个连接有I/O流事件产生，然后进程就去处理这个进程。
有了epoll，理论上1个进程就可以无限数量的连接，而且无需轮询，真正解决了c10k的问题。
Nginx是基于epoll的，异步非阻塞的服务器程序。自然，Nginx能够轻松处理百万级的并发连接，也就无可厚非了。
Swoole是如何处理高并发
Reactor模型介绍
IO复用异步非阻塞程序使用经典的Reactor模型，Reactor顾名思义就是反应堆的意思，它本身不处理任何数据收发。只是可以监视一个socket(也可以是管道、eventfd、信号)句柄的事件变化。
注:什么是句柄？句柄英文为handler，可以形象的比喻为锅柄、勺柄。也就是资源的唯一标识符、资源的ID。通过这个ID可以操作资源。
Reactor只是一个事件发生器，实际对socket句柄的操作，如connect/accept、send/recv、close是在callback中完成的。
Swoole的架构
swoole的处理连接流程图如下：
当请求到达时,swoole是这样处理的：
因为reactor基于epoll，所以每个reactor可以处理无数个连接请求。 如此，swoole就轻松的处理了高并发。
swoole如何实现异步I/O的（异步IO和协程不是一回事）
基于上面的Swoole结构图，我们看到swoole的worker进程有2种类型： 一种是 普通的worker进程，一种是 task worker进程。
worker进程是用来处理普通的耗时不是太长的请求；task worker进程用来处理耗时较长的请求，比如数据库的I/O操作。
我们以异步Mysql举例：
如此，通过worker、task worker结合的方式，我们就实现了异步I/O。