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/