Nginx爲何快到停不下來？

Nginx 的進程模型

Nginx 服務器，正常運行過程當中：

1.多進程：一個 Master 進程、多個 Worker 進程

2.Master 進程：管理 Worker 進程

3.對外接口：接收外部的操做（信號）

4.對內轉發：根據外部的操做的不一樣，經過信號管理 Worker

5.監控：監控 worker 進程的運行狀態，worker 進程異常終止後，自動重啓 worker 進程

6.Worker 進程：全部 Worker 進程都是平等的

7.實際處理：網絡請求，由 Worker 進程處理；

8.Worker 進程數量：在 nginx.conf 中配置，通常設置爲核心數，充分利用 CPU 資源，同時，避免進程數量過多，避免進程競爭 CPU 資源，增長上下文切換的損耗。

思考：

1.請求是鏈接到 Nginx，Master 進程負責處理和轉發？

2.如何選定哪一個 Worker 進程處理請求？請求的處理結果，是否還要通過 Master 進程？

HTTP 鏈接創建和請求處理過程

1.Nginx 啓動時，Master 進程，加載配置文件

2.Master 進程，初始化監聽的 socket

3.Master 進程，fork 出多個 Worker 進程

4.Worker 進程，競爭新的鏈接，獲勝方經過三次握手，創建 Socket 鏈接，並處理請求

Nginx 高性能、高併發

1.Nginx 採用：多進程 + 異步非阻塞方式（IO 多路複用 epoll）

2.請求的完整過程：

3.創建鏈接

4.讀取請求：解析請求

5.處理請求

6.響應請求

7.請求的完整過程，對應到底層，就是：讀寫 socket 事件

Nginx 的事件處理模型

request：Nginx 中 http 請求。

基本的 HTTP Web Server 工做模式：

1.接收請求：逐行讀取請求行和請求頭，判斷段有請求體後，讀取請求體

2.處理請求

3.返回響應：根據處理結果，生成相應的 HTTP 請求（響應行、響應頭、響應體）

Nginx 也是這個套路，總體流程一致。

模塊化體系結構

nginx的模塊根據其功能基本上能夠分爲如下幾種類型：

1.event module: 搭建了獨立於操做系統的事件處理機制的框架，及提供了各具體事件的處理。包括ngx_events_module， ngx_event_core_module和ngx_epoll_module等。nginx具體使用何種事件處理模塊，這依賴於具體的操做系統和編譯選項。

2.phase handler: 此類型的模塊也被直接稱爲handler模塊。主要負責處理客戶端請求併產生待響應內容，好比ngx_http_static_module模塊，負責客戶端的靜態頁面請求處理並將對應的磁盤文件準備爲響應內容輸出。

3.output filter: 也稱爲filter模塊，主要是負責對輸出的內容進行處理，能夠對輸出進行修改。例如，能夠實現對輸出的全部html頁面增長預約義的footbar一類的工做，或者對輸出的圖片的URL進行替換之類的工做。

4.upstream: upstream模塊實現反向代理的功能，將真正的請求轉發到後端服務器上，並從後端服務器上讀取響應，發回客戶端。upstream模塊是一種特殊的handler，只不過響應內容不是真正由本身產生的，而是從後端服務器上讀取的。

5.oad-balancer: 負載均衡模塊，實現特定的算法，在衆多的後端服務器中，選擇一個服務器出來做爲某個請求的轉發服務器。

常見問題剖析

Nginx vs. Apache

網絡 IO 模型：

1.nginx：IO 多路複用，epoll(freebsd 上是 kqueue )

2.高性能

3.高併發

4.佔用系統資源少

5.apache：阻塞 + 多進程/多線程

6.更穩定，bug 少

7.模塊更豐富

場景：

處理多個請求時，能夠採用：IO 多路複用 或者 阻塞 IO +多線程

• IO 多路服用：一個 線程，跟蹤多個 socket 狀態，哪一個就緒，就讀寫哪一個；

• 阻塞 IO + 多線程：每個請求，新建一個服務線程

思考：IO 多路複用 和 多線程 的適用場景？

• IO 多路複用：單個鏈接的請求處理速度沒有優點，適合 IO 密集型 場景，事件驅動 大併發量：只使用一個線程，處理大量的併發請求，下降上下文環境切換損耗，也不須要考慮併發問題，相對能夠處理更多的請求；

• 消耗更少的系統資源（不須要線程調度開銷）

• 適用於長鏈接的狀況（多線程模式長鏈接容易形成線程過多，形成頻繁調度）

• 阻塞IO + 多線程：實現簡單，能夠不依賴系統調用，適合 CPU 密集型 場景

• 每一個線程，都須要時間和空間；

• 線程數量增加時，線程調度開銷指數增加

Nginx 最大鏈接數

基礎背景：

1.Nginx 是多進程模型，Worker 進程用於處理請求；

2.單個進程的鏈接數（文件描述符 fd），有上限（nofile）：ulimit -n

3.Nginx 上配置單個 worker 進程的最大鏈接數：worker_connections 上限爲 nofile

4.Nginx 上配置 worker 進程的數量：worker_processes

所以，Nginx 的最大鏈接數：

1.Nginx 的最大鏈接數：Worker 進程數量 x 單個 Worker 進程的最大鏈接數

2.上面是 Nginx 做爲通用服務器時，最大的鏈接數

3.Nginx 做爲反向代理服務器時，可以服務的最大鏈接數：（Worker 進程數量 x 單個 Worker 進程的最大鏈接數）/ 2。

4.Nginx 反向代理時，會創建 Client 的鏈接和後端 Web Server 的鏈接，佔用 2 個鏈接

思考：

每打開一個 socket 佔用一個 fd

爲何，一個進程可以打開的 fd 數量有限制？

IO 模型

場景：

處理多個請求時，能夠採用：IO 多路複用 或者 阻塞 IO +多線程

• IO 多路複用：一個 線程，跟蹤多個 socket 狀態，哪一個就緒，就讀寫哪一個；

• 阻塞 IO + 多線程：每個請求，新建一個服務線程 思考：IO 多路複用 和 多線程 的適用場景？

IO 多路複用：

• 單個鏈接的請求處理速度沒有優點
• 大併發量：只使用一個線程，處理大量的併發請求，下降上下文環境切換損耗，也不須要考慮併發問題，相對能夠處理更多的請求；
• 消耗更少的系統資源（不須要線程調度開銷）
• 適用於長鏈接的狀況（多線程模式長鏈接容易形成線程過多，形成頻繁調度）
• 阻塞IO + 多線程：實現簡單，能夠不依賴系統調用。
• 每一個線程，都須要時間和空間；
• 線程數量增加時，線程調度開銷指數增加

select/poll 和 epoll 比較

詳細內容，參考：

• select poll epoll三者之間的比較 select/poll 系統調用：

// select 系統調用 
 
int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout); 
 
// poll 系統調用 
 
int poll(struct pollfd fds[], nfds_t nfds, int timeout)； 

複製代碼

select

• 查詢 fd_set 中，是否有就緒的 fd，能夠設定一個超時時間，當有 fd (File descripter) 就緒或超時返回；
• fd_set 是一個位集合，大小是在編譯內核時的常量，默認大小爲 1024
• 特色：
• 鏈接數限制，fd_set 可表示的 fd 數量過小了；
• 線性掃描：判斷 fd 是否就緒，須要遍歷一邊 fd_set；
• 數據複製：用戶空間和內核空間，複製鏈接就緒狀態信息

poll：

• 解決了鏈接數限制：
• poll 中將 select 中的 fd_set 替換成了一個 pollfd 數組
• 解決 fd 數量太小的問題
• 數據複製：用戶空間和內核空間，複製鏈接就緒狀態信息

epoll：event 事件驅動

*事件機制：避免線性掃描 *爲每一個 fd，註冊一個監聽事件 *fd 變動爲就緒時，將 fd 添加到就緒鏈表 *fd 數量：無限制（OS 級別的限制，單個進程能打開多少個 fd）

select，poll，epoll：

1.I/O多路複用的機制； 2.I/O多路複用就經過一種機制，能夠監視多個描述符，一旦某個描述符就緒（通常是讀就緒或者寫就緒），可以通知程序進行相應的讀寫操做。 3.監視多個文件描述符 4.但select，poll，epoll本質上都是同步I/O： 5.用戶進程負責讀寫（從內核空間拷貝到用戶空間），讀寫過程當中，用戶進程是阻塞的； 6.異步 IO，無需用戶進程負責讀寫，異步IO，會負責從內核空間拷貝到用戶空間；

Nginx 的併發處理能力

關於 Nginx 的併發處理能力：

*併發鏈接數，通常優化後，峯值能保持在 1~3w 左右。（內存和 CPU 核心數不一樣，會有進一步優化空間）

想得到更多的學習資料，在評論下方回覆【學習資料】就能拿到哦