Nginx 多进程架构和惊群问题

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/