网络服务的两种处理模型 Nginx为什么比Apache好

任何一个任务都可以分解为三个要素，即“谁”，“什么时间”，”干什么“。如果我们把这三个要素画在一个笛卡尔坐标系中，就显得很有意思了：

我以单CPU多任务操作系统为例，来看一个简单的Web服务是如何映射到上图的：

一般情况下都是按照上图处理的。每来到一个连接，便会新建一个进程或者线程单独服务那个连接，连接结束后，进程或者线程随即销毁。

??然而，鉴于进程/线程的创建会有比较可观的系统开销，所以说一般会预创建比较多的进程或者线程，然后为新建的连接分配一个即可，连接结束后进程或者线程便回到空闲资源池中了。

??显然，这种优化会大大降低进程，线程的创建，销毁的开销，我们知道这种开销主要集中于数据结构的分配与回收，内核基础设施的刷新等。再看上图，可以看得出，每一个进程就像一块板子一样插在Who，When，What构成的立方体中，这就好像热插拔刀片服务器一般，当然这里只是比喻，我想呈现的事情是，即便是刀片的插拔也是有昂贵开销的。

??除了刀片插拔的开销，还有另外一种开销，那就是切换的开销，这里就不具体展开了，一般人都知道进程，线程切换所要付出的操作系统级别的代价。

??特别是当同时在线的连接数据巨大的时候，比如10万量级，就意味着有10万量级的进程或者线程要在单一的系统中频繁切换…怎么办？

按照能量守恒定律，只要CPU维持100%的运转，它单位时间内完成的工作量就是一定的，想最大化吞吐最好的办法就是只要让干一件事，而不是搞多个任务频繁切换。我们知道多任务分时调度只是一种假象，代价是切换开销引起的吞吐量降低，收益是高品质低时延的交互性。使用Linux的都知道，一般情况下，服务器的内核HZ都是100或者250，而桌面系统的内核HZ都是1000，这意味着对于服务器而言，吞吐相比交互的响应性更重要，理解了这个例子，就能理解我接下来要说的了。

还记得我曾经大力推崇的nf-HiPAC，以及我自己设计的DxRPro++，iptables规则优化等故事里关于优化的根本原则吗？就是换一种切法。好吧，这次我们把Web服务器处理单条连接的整个处理流程切分成两个部分，而不再按照连接来切分，看看能不能避免创建多个进程或者线程。

??先上图再解释：

非常Perfect！

??整个系统就只有两个进程，一个进程处理所有的新建连接，另一个进程处理真正的HTTP逻辑，换了一种切分方法，意味着只需要两个进程就够了，就这样，切换开销完美避免。在这里，其实还可以说得更多。

??首先，连接管理进程依靠Linux内核中高效的epoll机制可以非常好的应对海量新建连接，毕竟该进程只是把新建连接pendding给后面的逻辑处理进程，所以处理是非常高效的，通过pendding可以把对CPU的时间要求转换为内存的空间要求，这正是换一种切法带来的直接收益。

??其次，如果你怀疑连接处理进程能否真正应对海量新建连接，那么你可以了解一下泊松分布的知识，新建连接分布是一个泊松分布，它并不是持续海量，你的系统只需要调优到其到达率的数学期望值稍高一点就足够了！当然，如果遇到了DDoS，那便可以另说，我有专门讨论DDoS的文章，本文不说这个。

??另外，我说一点，其实上面两个图正是体现了Apache和Nginx之间的区别。

??Nginx为什么比Apache在应对高并发是表现更好？其实就用因为其独立的异步的事件处理，当一个连接处理进入IO等待的时候进程并不阻塞，同一个进程就可以去处理别的连接，这就大大减小了系统进程的数量，从而净节省了系统开销。如果让Apache去应对泊松分布的连接到达，那就只能寄希望于内核了…当然，Apache也有优点，就是它的编程模型以及可扩展模块。

??经理喜欢Apache，极客喜欢Nginx。

??如果有时间，我会把上面关于“谁”，“什么时间”，”干什么“的模型的玩法全部展示一遍，比如它的高度代表什么，它的宽度和厚度分别代表什么等等，另外如果是多个CPU，这个图又该怎么画…是不是在多CPU系统中，又要再加一个H呢？这样就成了“谁”，“什么时间”，在哪里，”干什么“(Who，When，Where，What)了。

??周五上午走了7公里健步行，微信运动统计步数正常一万步左右吧，然而我通过摇手机的方式为我们团队平均成绩增加了近900步…第二天醒来手有点酸…这就是teamwork吧，唉。可能是因为上周《龙珠超》停播了一周，然后我就改看《古惑仔》了吧，前者都是单打独斗，后者就是teamwork了，也就学会了？嗯，也是，反正周五跟同事们一起喝完酒是比自己喝完酒爽很多的…

————–勘误与补遗————–
王姐姐如是说：Nginx并不比Apache好，Apache适合做服务器，而Nginx只适合做代理。不过确实如此。