Nginx 多进程架构是:一个master进程和多个worker 进程。
一个worker 通过非阻塞式论询,可维护数千个连接,多个worker共享一个监听套接字.

Master进程

顾名思义,老板进程,主要负责有轻而巧的工作.
主要通过进程间通信对工人进程发号施令或是处理来自bash的start,stop,reload等用户指令。

Worker 进程

顾名思义,工人进程,主要负责重而笨的工作,主要负责处理来自浏览器的连接。
网站高并发情况下,巨大的工作负荷都是压到工人进程,老板进程在一旁观看指挥。

在TCP Socket 服务开发中,多进程或多线程共享监听套接字时面临惊群问题.

  1. 对于主流的linx版本, accept 阻塞调用,已经不存在惊群问题.
    也就是说多个进程同时accept 同一个 监听套接字,只有一个进程获的连接.
  2. 对于epoll_wait 非阻塞式的创建连接方式, 存在惊群问题。(即:一个连接请求唤醒多个worker 进程).

Nginx 在linux系统中使用epoll_wait 非阻塞式的方式,存在惊群问题。

浏览器的请求连接不经过master进程,直接由worker 进程处理,
但是一个请求如何分配到特定的worker进程?

  1. nginx 默认的配置accept_mutex on;
    多个worker 进程通过争锁获得连接,同时只有一个worker获得连接。
    工人进程抢着活干(让我来,别和我争)
  2. accept_mutex off
    一个连接请求唤醒多个worker 进程,同时只有一个worker获得连接。
    存在惊群问题,由于nginx 的worker 进程数量不大,这个惊群问题影响不大。
    少了争锁,这个配置高并发时可提高系统的响应能力。
  3. 开启SO_REUSEPORT选项: reuseport
http {
        server {
          listen 80 reuseport;
          server_name  localhost;
          ...
     }
}

SO_REUSEPORT选项,是Linux 内核3.9+处理大并发连接的新特性。
开启后,连接请求通过linux内核分配到worker 进程,性能最好。
此选项的系统需求:
Nginx 1.9.1+
DragonFly BSD/Linux 内核3.9+

参考:
http://blog.csdn.net/Marcky/
https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/

Nginx 多进程架构和惊群问题
标签: