nginx和 apache比较

nginx 相对 apache 的优点：

• 轻量级，同样起web 服务，比apache 占用更少的内存及资源
• 抗并发，nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能
• 高度模块化的设计，编写模块相对简单
• 社区活跃，各种高性能模块出品迅速啊

apache 相对nginx 的优点：

• rewrite ，比nginx 的rewrite 强大
• 模块超多，基本想到的都可以找到
• 少bug ，nginx 的bug 相对较多
• 超稳定（不知道原因，希望有朋友赐教）

nginx的高并发得益于epoll模型。

传统的apache都是对进程（prefork）或者多线程（worker）工作，假如是prefork,Apache会先生成几个进程，类似进程池，只不过这里的进程池会随着请求数目的增加而增加。对于每一个连接，Apache都是在一个进程内处理完毕，具体是recv()以及根据URI去进行磁盘IO寻找文件，还有send（）都是阻塞的，阻塞意味着进程就得挂起进入sleep状态，那么一旦连接数很多，Apache必然要生成更多的进程来响应请求，一旦进程多了，CPU对于进程的切换就频繁了，很耗资源和时间，所以就导致Apache性能下降，就是处理不过来那么多的进程。

nginx采用epoll模型，异步非阻塞，对于nginx来说，把一个完整的链接请求处理都划分成了事件，一个一个的事件，比如accept,recv,send,磁盘IO，每部分都有相应的模块去处理，一个完整的请求可能是由几百个模块去处理，真正核心的就是事件手机和分发模块，这就是管理所有模块的核心，只有核心模块的调度才能让对应的模块占用CPU资源，从而处理请求，例如http请求：首先在事件手机分发木块注册感兴趣的监听事件，注册号以后不阻塞直接返回，接下来就不需要再管了，等待有链接来了内核就会通知，CPU就可以处理其他事情。一旦有请求来，那么对整个请求分配相应的上下文（其实已经预先分配好），这时候再注册新的感兴趣的事件(read函数)，同样客户端数据来了内核会自动通知进程可以去读数据了，读了数据之后就是解析，解析完后去磁盘找资源（I/O），一旦I/O完成会通知进程，进程开始给客户端发回数据send()，这时候也不是阻塞的，调用后就等内核发回通知发送的结果就行。整个下来把一个请求分成了很多个阶段，每个阶段都很很多模块去注册，然后处理，都是异步非阻塞。异步这里指的就是做一个事情，不需要等返回结果，做好了会自动通知你。

 

可以举一个简单的例子来说明Apache的工作流程，我们平时去餐厅吃饭。餐厅的工作模式是一个服务员全程服务客户，流程是这样，服务员在门口等候客人(listen)，客人到了就接待安排的餐桌上(accept)，等着客户点菜(request uri)，去厨房叫师傅下单做菜（磁盘I/O），等待厨房做好（read），然后给客人上菜(send)，整个下来服务员(进程)很多地方是阻塞的。这样客人一多（HTTP请求一多），餐厅只能通过叫更多的服务员来服务（fork进程），但是由于餐厅资源是有限的（CPU），一旦服务员太多管理成本很高（CPU上下文切换），这样就进入一个瓶颈。 
再来看看Nginx得怎么处理？餐厅门口挂个门铃（注册epoll模型的listen），一旦有客人（HTTP请求）到达，派一个服务员去接待（accept），之后服务员就去忙其他事情了（比如再去接待客人），等这位客人点好餐就叫服务员（数据到了read()），服务员过来拿走菜单到厨房（磁盘I/O），服务员又做其他事情去了，等厨房做好了菜也喊服务员（磁盘I/O结束），服务员再给客人上菜（send()），厨房做好一个菜就给客人上一个，中间服务员可以去干其他事情。整个过程被切分成很多个阶段，每个阶段都有相应的服务模块。我们想想，这样一旦客人多了，餐厅也能招待更多的人。