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