Nginx 多程序架構和驚群問題

Nginx 多程序 · 發表 2019-03-11 20:14:42

摘要： Nginx 多程序架構是：一個master程序和多個worker 程序。一個worker 通過非阻塞式論詢，可維護數千個連線,多個worker共享一個監聽套接字. Master程序顧名思義,老闆程序，主要負責有輕而巧的工作. 主要通過程序間通訊對工人...

Nginx 多程序架構是：一個master程序和多個worker 程序。

一個worker 通過非阻塞式論詢，可維護數千個連線,多個worker共享一個監聽套接字.

顧名思義,老闆程序，主要負責有輕而巧的工作.

主要通過程序間通訊對工人程序發號施令或是處理來自bash的start,stop,reload等使用者指令。

顧名思義,工人程序，主要負責重而笨的工作，主要負責處理來自瀏覽器的連線。

網站高併發情況下，巨大的工作負荷都是壓到工人程序，老闆程序在一旁觀看指揮。

在TCP Socket 服務開發中,多程序或多執行緒共享監聽套接字時面臨驚群問題.

Nginx 在linux系統中使用epoll_wait 非阻塞式的方式，存在驚群問題。

瀏覽器的請求連線不經過master程序，直接由worker 程序處理,

但是一個請求如何分配到特定的worker程序？

nginx 預設的配置accept_mutex on;
多個worker 程序通過爭鎖獲得連線，同時只有一個worker獲得連線。
工人程序搶著活幹（讓我來，別和我爭）
accept_mutex off
一個連線請求喚醒多個worker 程序，同時只有一個worker獲得連線。
存在驚群問題，由於nginx 的worker 程序數量不大，這個驚群問題影響不大。
少了爭鎖，這個配置高併發時可提高系統的響應能力。
開啟SO_REUSEPORT選項:reuseport

http {
server {
listen 80 reuseport;
server_namelocalhost;
...
}
}

SO_REUSEPORT選項,是Linux 核心3.9+處理大併發連線的新特性。

開啟後，連線請求通過linux核心分配到worker 程序，效能最好。

此選項的系統需求：

Nginx 1.9.1+

DragonFly BSD/Linux 核心3.9+

參考：