Nginx 多進程架構(gòu)是：一個master進程和多個worker 進程。
一個worker 通過非阻塞式論詢，可維護數(shù)千個連接,多個worker共享一個監(jiān)聽套接字.
Master進程
顧名思義,老板進程，主要負(fù)責(zé)有輕而巧的工作.
主要通過進程間通信對工人進程發(fā)號施令或是處理來自bash的start,stop,reload等用戶指令射亏。
Worker 進程
顧名思義,工人進程，主要負(fù)責(zé)重而笨的工作，主要負(fù)責(zé)處理來自瀏覽器的連接返弹。
網(wǎng)站高并發(fā)情況下锈玉，巨大的工作負(fù)荷都是壓到工人進程，老板進程在一旁觀看指揮义起。
在TCP Socket 服務(wù)開發(fā)中,多進程或多線程共享監(jiān)聽套接字時面臨驚群問題.
對于主流的linx版本, accept 阻塞調(diào)用,已經(jīng)不存在驚群問題.
也就是說多個進程同時accept 同一個 監(jiān)聽套接字,只有一個進程獲的連接.對于epoll_wait 非阻塞式的創(chuàng)建連接方式, 存在驚群問題拉背。(即：一個連接請求喚醒多個worker 進程).
Nginx 在linux系統(tǒng)中使用epoll_wait 非阻塞式的方式，存在驚群問題默终。
瀏覽器的請求連接不經(jīng)過master進程椅棺，直接由worker 進程處理,
但是一個請求如何分配到特定的worker進程？
- nginx 默認(rèn)的配置accept_mutex on;
多個worker 進程通過爭鎖獲得連接齐蔽，同時只有一個worker獲得連接两疚。
工人進程搶著活干（讓我來，別和我爭） - accept_mutex off
一個連接請求喚醒多個worker 進程含滴，同時只有一個worker獲得連接诱渤。
存在驚群問題，由于nginx 的worker 進程數(shù)量不大蛙吏，這個驚群問題影響不大源哩。
少了爭鎖，這個配置高并發(fā)時可提高系統(tǒng)的響應(yīng)能力鸦做。 - 開啟SO_REUSEPORT選項: reuseport
http {
server {
listen 80 reuseport;
server_name localhost;
...
}
}
SO_REUSEPORT選項,是Linux 內(nèi)核3.9+處理大并發(fā)連接的新特性励烦。
開啟后，連接請求通過linux內(nèi)核分配到worker 進程泼诱，性能最好坛掠。
此選項的系統(tǒng)需求：
Nginx 1.9.1+
DragonFly BSD/Linux 內(nèi)核3.9+
參考：
http://blog.csdn.net/Marcky/
https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/
