從底層原理分析Nginx為什么這么快
作者：IT知識(shí)課堂
請求是連接到 Nginx，Master 進(jìn)程負(fù)責(zé)處理和轉(zhuǎn)發(fā)?如何選定哪個(gè) Worker 進(jìn)程處理請求?請求的處理結(jié)果，是否還要經(jīng)過 Master 進(jìn)程?
Nginx 的進(jìn)程模型
Nginx 服務(wù)器，正常運(yùn)行過程中：
- 多進(jìn)程：一個(gè) Master 進(jìn)程、多個(gè) Worker 進(jìn)程
- Master 進(jìn)程：管理 Worker 進(jìn)程
- 對外接口：接收外部的操作(信號(hào))
- 對內(nèi)轉(zhuǎn)發(fā)：根據(jù)外部的操作的不同，通過信號(hào)管理 Worker
- 監(jiān)控：監(jiān)控 worker 進(jìn)程的運(yùn)行狀態(tài)，worker 進(jìn)程異常終止后，自動(dòng)重啟 worker 進(jìn)程
- Worker 進(jìn)程：所有 Worker 進(jìn)程都是平等的
- 實(shí)際處理：網(wǎng)絡(luò)請求，由 Worker 進(jìn)程處理;
- Worker 進(jìn)程數(shù)量：在 nginx.conf 中配置，一般設(shè)置為核心數(shù)，充分利用 CPU 資源，同時(shí)，避免進(jìn)程數(shù)量過多，避免進(jìn)程競爭 CPU 資源，增加上下文切換的損耗。
思考：
請求是連接到 Nginx，Master 進(jìn)程負(fù)責(zé)處理和轉(zhuǎn)發(fā)?
如何選定哪個(gè) Worker 進(jìn)程處理請求?請求的處理結(jié)果，是否還要經(jīng)過 Master 進(jìn)程?
HTTP 連接建立和請求處理過程：
- Nginx 啟動(dòng)時(shí)，Master 進(jìn)程，加載配置文件
- Master 進(jìn)程，初始化監(jiān)聽的 socket
- Master 進(jìn)程，fork 出多個(gè) Worker 進(jìn)程
- Worker 進(jìn)程，競爭新的連接，獲勝方通過三次握手，建立 Socket 連接，并處理請求
Nginx 高性能、高并發(fā)：
- Nginx 采用：多進(jìn)程 + 異步非阻塞方式(IO 多路復(fù)用 epoll)
- 請求的完整過程：
- 建立連接
- 讀取請求：解析請求
- 處理請求
- 響應(yīng)請求
- 請求的完整過程，對應(yīng)到底層，就是：讀寫 socket 事件
Nginx 的事件處理模型
request：Nginx 中 http 請求。
基本的 HTTP Web Server 工作模式：
- 接收請求：逐行讀取請求行和請求頭，判斷段有請求體后，讀取請求體
- 處理請求
- 返回響應(yīng)：根據(jù)處理結(jié)果，生成相應(yīng)的 HTTP 請求(響應(yīng)行、響應(yīng)頭、響應(yīng)體)
Nginx 也是這個(gè)套路，整體流程一致。
模塊化體系結(jié)構(gòu)
nginx的模塊根據(jù)其功能基本上可以分為以下幾種類型：
- event module: 搭建了獨(dú)立于操作系統(tǒng)的事件處理機(jī)制的框架，及提供了各具體事件的處理。包括ngx_events_module， ngx_event_core_module和ngx_epoll_module等。nginx具體使用何種事件處理模塊，這依賴于具體的操作系統(tǒng)和編譯選項(xiàng)。
- phase handler: 此類型的模塊也被直接稱為handler模塊。主要負(fù)責(zé)處理客戶端請求并產(chǎn)生待響應(yīng)內(nèi)容，比如ngx_http_static_module模塊，負(fù)責(zé)客戶端的靜態(tài)頁面請求處理并將對應(yīng)的磁盤文件準(zhǔn)備為響應(yīng)內(nèi)容輸出。
- output filter: 也稱為filter模塊，主要是負(fù)責(zé)對輸出的內(nèi)容進(jìn)行處理，可以對輸出進(jìn)行修改。例如，可以實(shí)現(xiàn)對輸出的所有html頁面增加預(yù)定義的footbar一類的工作，或者對輸出的圖片的URL進(jìn)行替換之類的工作。
- upstream: upstream模塊實(shí)現(xiàn)反向代理的功能，將真正的請求轉(zhuǎn)發(fā)到后端服務(wù)器上，并從后端服務(wù)器上讀取響應(yīng)，發(fā)回客戶端。upstream模塊是一種特殊的handler，只不過響應(yīng)內(nèi)容不是真正由自己產(chǎn)生的，而是從后端服務(wù)器上讀取的。
- load-balancer: 負(fù)載均衡模塊，實(shí)現(xiàn)特定的算法，在眾多的后端服務(wù)器中，選擇一個(gè)服務(wù)器出來作為某個(gè)請求的轉(zhuǎn)發(fā)服務(wù)器。
常見問題剖析
Nginx vs. Apache
網(wǎng)絡(luò) IO 模型：
- nginx：IO 多路復(fù)用，epoll(freebsd 上是 kqueue )
- 高性能
- 高并發(fā)
- 占用系統(tǒng)資源少
- apache：阻塞 + 多進(jìn)程/多線程
- 更穩(wěn)定，bug 少
- 模塊更豐富
場景：
處理多個(gè)請求時(shí)，可以采用：IO 多路復(fù)用 或者 阻塞 IO +多線程
- IO 多路服用：一個(gè) 線程，跟蹤多個(gè) socket 狀態(tài)，哪個(gè)就緒，就讀寫哪個(gè);
- 阻塞 IO + 多線程：每一個(gè)請求，新建一個(gè)服務(wù)線程
思考：IO 多路復(fù)用 和 多線程 的適用場景?
- IO 多路復(fù)用：單個(gè)連接的請求處理速度沒有優(yōu)勢，適合 IO 密集型 場景，事件驅(qū)動(dòng)
- 大并發(fā)量：只使用一個(gè)線程，處理大量的并發(fā)請求，降低上下文環(huán)境切換損耗，也不需要考慮并發(fā)問題，相對可以處理更多的請求;
- 消耗更少的系統(tǒng)資源(不需要線程調(diào)度開銷)
- 適用于長連接的情況(多線程模式長連接容易造成線程過多，造成頻繁調(diào)度)
- 阻塞IO + 多線程：實(shí)現(xiàn)簡單，可以不依賴系統(tǒng)調(diào)用，適合 CPU 密集型 場景
- 每個(gè)線程，都需要時(shí)間和空間;
- 線程數(shù)量增長時(shí)，線程調(diào)度開銷指數(shù)增長
Nginx 最大連接數(shù)
基礎(chǔ)背景：
- Nginx 是多進(jìn)程模型，Worker 進(jìn)程用于處理請求;
- 單個(gè)進(jìn)程的連接數(shù)(文件描述符 fd)，有上限(nofile)：ulimit -n
- Nginx 上配置單個(gè) worker 進(jìn)程的最大連接數(shù)：worker_connections 上限為 nofile
- Nginx 上配置 worker 進(jìn)程的數(shù)量：worker_processes
因此，Nginx 的最大連接數(shù)：
- Nginx 的最大連接數(shù)：Worker 進(jìn)程數(shù)量 x 單個(gè) Worker 進(jìn)程的最大連接數(shù)
- 上面是 Nginx 作為通用服務(wù)器時(shí)，最大的連接數(shù)
- Nginx 作為反向代理服務(wù)器時(shí)，能夠服務(wù)的最大連接數(shù)：(Worker 進(jìn)程數(shù)量 x 單個(gè) Worker 進(jìn)程的最大連接數(shù))/ 2。
- Nginx 反向代理時(shí)，會(huì)建立 Client 的連接和后端 Web Server 的連接，占用 2 個(gè)連接
思考：
- 每打開一個(gè) socket 占用一個(gè) fd
- 為什么，一個(gè)進(jìn)程能夠打開的 fd 數(shù)量有限制?
IO 模型
場景：
處理多個(gè)請求時(shí)，可以采用：IO 多路復(fù)用 或者 阻塞 IO +多線程
- IO 多路服用：一個(gè) 線程，跟蹤多個(gè) socket 狀態(tài)，哪個(gè)就緒，就讀寫哪個(gè);
- 阻塞 IO + 多線程：每一個(gè)請求，新建一個(gè)服務(wù)線程
思考：IO 多路復(fù)用 和 多線程 的適用場景?
- IO 多路復(fù)用：單個(gè)連接的請求處理速度沒有優(yōu)勢
- 大并發(fā)量：只使用一個(gè)線程，處理大量的并發(fā)請求，降低上下文環(huán)境切換損耗，也不需要考慮并發(fā)問題，相對可以處理更多的請求;
- 消耗更少的系統(tǒng)資源(不需要線程調(diào)度開銷)
- 適用于長連接的情況(多線程模式長連接容易造成線程過多，造成頻繁調(diào)度)
- 阻塞IO + 多線程：實(shí)現(xiàn)簡單，可以不依賴系統(tǒng)調(diào)用。
- 每個(gè)線程，都需要時(shí)間和空間;
- 線程數(shù)量增長時(shí)，線程調(diào)度開銷指數(shù)增長
select/poll 和 epoll 比較
詳細(xì)內(nèi)容，參考：
- select poll epoll三者之間的比較
select/poll 系統(tǒng)調(diào)用：
- // select 系統(tǒng)調(diào)用
- int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout);
- // poll 系統(tǒng)調(diào)用
- int poll(struct pollfd fds[], nfds_t nfds, int timeout)；
select：
- 查詢 fd_set 中，是否有就緒的 fd，可以設(shè)定一個(gè)超時(shí)時(shí)間，當(dāng)有 fd (File descripter) 就緒或超時(shí)返回;
- fd_set 是一個(gè)位集合，大小是在編譯內(nèi)核時(shí)的常量，默認(rèn)大小為 1024
特點(diǎn)：
- 連接數(shù)限制，fd_set 可表示的 fd 數(shù)量太小了;
- 線性掃描：判斷 fd 是否就緒，需要遍歷一邊 fd_set;
- 數(shù)據(jù)復(fù)制：用戶空間和內(nèi)核空間，復(fù)制連接就緒狀態(tài)信息
poll：
- 解決了連接數(shù)限制：
- poll 中將 select 中的 fd_set 替換成了一個(gè) pollfd 數(shù)組
- 解決 fd 數(shù)量過小的問題
- 數(shù)據(jù)復(fù)制：用戶空間和內(nèi)核空間，復(fù)制連接就緒狀態(tài)信息
epoll： event 事件驅(qū)動(dòng)
- 事件機(jī)制：避免線性掃描
- 為每個(gè) fd，注冊一個(gè)監(jiān)聽事件
- fd 變更為就緒時(shí)，將 fd 添加到就緒鏈表
- fd 數(shù)量：無限制(OS 級別的限制，單個(gè)進(jìn)程能打開多少個(gè) fd)
select，poll，epoll：
- I/O多路復(fù)用的機(jī)制;
- I/O多路復(fù)用就通過一種機(jī)制，可以監(jiān)視多個(gè)描述符，一旦某個(gè)描述符就緒(一般是讀就緒或者寫就緒)，能夠通知程序進(jìn)行相應(yīng)的讀寫操作。
- 監(jiān)視多個(gè)文件描述符
- 但select，poll，epoll本質(zhì)上都是同步I/O：
- 用戶進(jìn)程負(fù)責(zé)讀寫(從內(nèi)核空間拷貝到用戶空間)，讀寫過程中，用戶進(jìn)程是阻塞的;
- 異步 IO，無需用戶進(jìn)程負(fù)責(zé)讀寫，異步IO，會(huì)負(fù)責(zé)從內(nèi)核空間拷貝到用戶空間;
Nginx 的并發(fā)處理能力
關(guān)于 Nginx 的并發(fā)處理能力：
并發(fā)連接數(shù)，一般優(yōu)化后，峰值能保持在 1~3w 左右。(內(nèi)存和 CPU 核心數(shù)不同，會(huì)有進(jìn)一步優(yōu)化空間)
責(zé)任編輯：武曉燕
來源：
今日頭條
