Nginx进程模型

目录

1.Nginx管理/工作进程模式

2.“惊群”问题

---

1.Nginx管理/工作进程模式

为了支持现在流行的多CPU和多核架构，Nginx使用了管理进程和工作进程的设计。架构设计如下图所示：

管理进程为工作进程的父进程，负责外部指令的接收，工作进程的状态监管，负载均衡等；工作进程负责客户端请求的处理和响应，工作进程一般是按照CPU的核数配置的，并且可以和处理器一一绑定，降低进程间切换的开销。

管理进程作为工作进程的管理进程和父进程，还可以带来高可靠性：工作进程终止，管理进程可以及时启动新的实例接替。这种模式的优点体现在一下3个方面：

• 充分利用多核系统的并发处理能力。Nginx中所有的工作进程都是平等的，并且可以在nginx.conf中将工作进程和处理器一一绑定，这样配合负载均衡机制，不会让某核繁忙，整体处理能力得到提高。
• 负载均衡：工作进程和管理进程通过进程间通信实现负载均衡，请求容易被分配到负载较轻的工作进程中，提高系统的整体性能。
• 方便状态监管：管理进程任务很轻，只负责启动、停止、监控工作进程，当某个工作进程不正常工作时，可立即启动新的进程接管。同时，管理进程支持服务运行中的程序升级、配置项修改等操作，使系统整体具备了动态扩展性、动态可定制性、动态可进化性。

Apache的每个进程在一个时刻只处理一个请求，因此在多任务处理阶段，Apache的进程数或线程数要设置的很多，这种情况下大量的进程间切换将带来无谓的系统资源消耗。Nginx的工作进程之间处理并发请求时几乎没有同步锁的问题，而且工作进程采用全异步的操作模式，处理速度快，占用内存小。事件驱动适合于IO密集型服务，多进程或者线程适合于CPU密集型服务。所以Nginx适合代理服务器，apache适合后端应用服务器

2.“惊群”问题

管理进程＋工作进程模式有很多优点，同时存在一些问题需要解决。

Nginx里的工作进程一般是按系统CPU核数配置的，有多少个CPU核心，就会配置多少个工作进程，工作进程启动时就会利用fork函数创建多少个工作进程，并且所有的工作进程都监听在nginx.conf内配置的监听端口上，这样可以充分利用多核机器的性能。

网络事件通过底层的events模块管理，当客户端连接请求到来时，一个新连接事件会上报，各个工作进程就会发生对事件的抢夺，这就是“惊群”问题。工作进程越多，问题越明显，这会造成系统性能下降，所以，必须避免“惊群”问题。详细来说，“惊群”问题的典型场景是这样的：在没有用户请求的时候，所有的工作进程都在休眠，此时，一个用户向服务器发起了连接请求，例如在epoll模式下，内核在收到了TCP的SYN包时，会激活所有休眠的工作进程，最先接收连接请求的工作进程可以成功建立新连接，其他工作进程的接收会失败。这些失败的唤醒是不必要的，引发了不必要的进程上下文切换，增加了系统开销，这就是“惊群”问题。

Nginx应用层制定了一个机制解决这个问题：规定同一时刻只能有唯一一个工作进程监听Web端口，这样，新的连接事件只能唤醒唯一一个工作进程。内部的实现实际上是使用了一个进程间的同步锁，工作进程每次唤醒都先尝试这把锁，保证同一时间只有一个工作进程可以进入锁，获得锁的进程设置监听连接的读事件，未能进入监听锁的工作进程则不监听新连接事件，只处理已连接上的事件。

设置了连接事件监听的进程在连接事件到来时会被唤醒并检查系统变量，发现新连接队列中有连接则释放锁，并调用对应事件的handler方法。这种技术既解决了“惊群”问题，也避免了一个进程过长占用锁使新连接得不到及时处理的问题，接收了一个连接后，把连接放入队列后马上释放锁，如果恰巧有新连接马上进来，则会由一个新的工作进程接收连接，起到一定的负载均衡作用。放入队列的请求事件会在后续阶段处理。