Nginx模型 & 惊群问题

这篇写的不错

http://www.cnblogs.com/linguoguo/p/5511293.html

Nginx为啥性能高－多进程异步IO模型

1. 对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查找时，也会方便很多。

2. 采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断. master进程则很快启动新的worker进程。(当然了，要报警查错)

当Nginx上的进程数与CPU核心数相等时（最好每一个worker进程都绑定特定的CPU核心），进程间切换的代价是最小的。

绑定cpu也就是CPU Affinity。有类似sched_setaffinity这样的函数，可还没有完全了解。

Nginx的master/worker模型

一个master，不接收请求，只负责管理worker。以前是通过信号管理，现在有命令，来处理reload, restart等命令。比如restart，不是先kill，而是先启动新的worker，并且发送kill到原来的worker。原来的worker处理结束手上的请求之后，就可以结束了。

worker进程都是从master fork出来的，需要listen的端口socket listenfd是继承过来的，大家一起监听。

那么就有可能出现惊群现象。在之前的文章里有讨论。

http://www.cnblogs.com/charlesblc/p/6491422.html

注意，nginx里面worker的epoll_create是在fork之后调用的，也就是说epoll里面使用的红黑树，是每个进程独立的，那么系统层面就不会避免惊群。

之后调用的原因是，accept之后不同的端口要分别由不同的进程来分别用epoll来侦听。

nginx通过加了一个accept_mutex来避免多个进程的惊群现象。但是Nginx作者也说了：

简单点说：Apache动辄就会启动成百上千的进程，如果发生惊群问题的话，影响相对较大；但是对Nginx而言，一般来说，worker_processes会设置成CPU个数，所以最多也就几十个，即便发生惊群问题的话，影响相对也较小。

Nginx缺省激活了accept_mutex，是一种保守的选择。如果关闭了它，可能会引起一定程度的惊群问题，表现为上下文切换增多（sar -w）或者负载上升，但是如果你的网站访问量比较大，为了系统的吞吐量，我还是建议大家关闭它。

（见这篇文章：http://os.51cto.com/art/201308/408261.htm）

事件模型：异步非阻塞

nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的。一个worker进程可以同时处理的请求数只受限于内存大小，而且在架构设计上，不同的worker进程之间处理并发请求时几乎没有同步锁的限制，worker进程通常不会进入睡眠状态。

当它接到一个HTTP请求时，它仅仅是通过查找配置文件将此次请求映射到一个location block。

通常一个location中的指令会涉及一个handler模块和多个filter模块（当然，多个location可以复用同一个模块）。handler模块负责处理请求，完成响应内容的生成，而filter模块对响应内容进行处理。

注：handler应该就是跟下游fast-cgi打交道的地方。