驚呆,這樣操作 Nginx 并發數就能達到3w?

Nginx 以其高性能,穩定性,豐富的功能,簡單的配置和低資源消耗而聞名。本文從底層原理分析 Nginx 為什么這么快!

Nginx 的進程模型

image.png

Nginx 服務器,正常運行過程中:

  • 多進程:一個 Master 進程、多個 Worker 進程。Java面試寶典PDF完整版

  • Master 進程:管理 Worker 進程。對外接口:接收外部的操作(信號);對內轉發:根據外部的操作的不同,通過信號管理 Worker;監控:監控 Worker 進程的運行狀態,Worker 進程異常終止后,自動重啟 Worker 進程。

  • Worker 進程:所有 Worker 進程都是平等的。實際處理:網絡請求,由 Worker 進程處理。Worker 進程數量:在 nginx.conf 中配置,一般設置為核心數,充分利用 CPU 資源,同時,避免進程數量過多,避免進程競爭 CPU 資源,增加上下文切換的損耗。

思考:

  • 請求是連接到 Nginx,Master 進程負責處理和轉發?

  • 如何選定哪個 Worker 進程處理請求?請求的處理結果,是否還要經過 Master 進程?

image.png

HTTP 連接建立和請求處理過程

HTTP 連接建立和請求處理過程如下:

  • Nginx 啟動時,Master 進程,加載配置文件。

  • Master 進程,初始化監聽的 Socket。

  • Master 進程,Fork 出多個 Worker 進程。

  • Worker 進程,競爭新的連接,獲勝方通過三次握手,建立 Socket 連接,并處理請求。

Nginx 高性能、高并發

Nginx 為什么擁有高性能并且能夠支撐高并發?

  • Nginx 采用多進程+異步非阻塞方式(IO 多路復用 Epoll)。

  • 請求的完整過程:建立連接→讀取請求→解析請求→處理請求→響應請求。

  • 請求的完整過程對應到底層就是:讀寫 Socket 事件。

Nginx 的事件處理模型

Request:Nginx 中 HTTP 請求。

基本的 HTTP Web Server 工作模式:

  • 接收請求:逐行讀取請求行和請求頭,判斷段有請求體后,讀取請求體。

  • 處理請求。

  • 返回響應:根據處理結果,生成相應的 HTTP 請求(響應行、響應頭、響應體)。

Nginx 也是這個套路,整體流程一致:

image.png

模塊化體系結構

image.png

Nginx 的模塊根據其功能基本上可以分為以下幾種類型:

①event module:搭建了獨立于操作系統的事件處理機制的框架,及提供了各具體事件的處理。包括 ngx_events_module,ngx_event_core_module 和 ngx_epoll_module 等。

Nginx 具體使用何種事件處理模塊,這依賴于具體的操作系統和編譯選項。

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

③output filter:也稱為 filter 模塊,主要是負責對輸出的內容進行處理,可以對輸出進行修改。

例如,可以實現對輸出的所有 html 頁面增加預定義的 footbar 一類的工作,或者對輸出的圖片的 URL 進行替換之類的工作。

④upstream:upstream 模塊實現反向代理的功能,將真正的請求轉發到后端服務器上,并從后端服務器上讀取響應,發回客戶端。

upstream 模塊是一種特殊的 handler,只不過響應內容不是真正由自己產生的,而是從后端服務器上讀取的。

⑤load-balancer:負載均衡模塊,實現特定的算法,在眾多的后端服務器中,選擇一個服務器出來作為某個請求的轉發服務器。

常見問題剖析

Nginx vs Apache

Nginx:

  • IO 多路復用,Epoll(freebsd 上是 kqueue)

  • 高性能

  • 高并發

  • 占用系統資源少

Apache:

  • 阻塞+多進程/多線程

  • 更穩定,Bug 少

  • 模塊更豐富

參考文章:

http://www.oschina.net/translate/nginx-vs-apache

Nginx 最大連接數

基礎背景:

  • Nginx 是多進程模型,Worker 進程用于處理請求。

  • 單個進程的連接數(文件描述符 fd),有上限(nofile):ulimit -n。

  • Nginx 上配置單個 Worker 進程的最大連接數:worker_connections 上限為 nofile。

  • Nginx 上配置 Worker 進程的數量:worker_processes。

因此,Nginx 的最大連接數:

  • Nginx 的最大連接數:Worker 進程數量 x 單個 Worker 進程的最大連接數。

  • 上面是 Nginx 作為通用服務器時,最大的連接數。

  • Nginx 作為反向代理服務器時,能夠服務的最大連接數:(Worker 進程數量 x 單個 Worker 進程的最大連接數)/ 2。

  • Nginx 反向代理時,會建立 Client 的連接和后端 Web Server 的連接,占用 2 個連接。

思考:

  • 每打開一個 Socket 占用一個 fd?

  • 為什么,一個進程能夠打開的 fd 數量有限制?

HTTP 請求和響應

HTTP 請求:

  • 請求行:method、uri、http version

  • 請求頭

  • 請求體

HTTP 響應:

  • 響應行:http version、status code

  • 響應頭

  • 響應體

IO 模型

處理多個請求時,可以采用:IO 多路復用或者阻塞 IO+多線程:

  • IO 多路復用:一個線程,跟蹤多個 Socket 狀態,哪個就緒,就讀寫哪個。

  • 阻塞 IO+多線程:每一個請求,新建一個服務線程。

IO 多路復用和多線程的適用場景?

  • IO 多路復用:單個連接的請求處理速度沒有優勢。

  • 大并發量:只使用一個線程,處理大量的并發請求,降低上下文環境切換損耗,也不需要考慮并發問題,相對可以處理更多的請求。

  • 消耗更少的系統資源(不需要線程調度開銷)。

  • 適用于長連接的情況(多線程模式長連接容易造成線程過多,造成頻繁調度)。

  • 阻塞 IO +多線程:實現簡單,可以不依賴系統調用。

  • 每個線程,都需要時間和空間。

  • 線程數量增長時,線程調度開銷指數增長。

select/poll 和 epoll 比較如下:

詳細內容,參考:

https://www.cnblogs.com/wiessharling/p/4106295.html

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:

  • I/O 多路復用的機制。

  • I/O 多路復用就通過一種機制,可以監視多個描述符,一旦某個描述符就緒(一般是讀就緒或者寫就緒),能夠通知程序進行相應的讀寫操作;監視多個文件描述符。

  • 但 select,poll,epoll 本質上都是同步 I/O:用戶進程負責讀寫(從內核空間拷貝到用戶空間),讀寫過程中,用戶進程是阻塞的;異步 IO,無需用戶進程負責讀寫,異步 IO,會負責從內核空間拷貝到用戶空間。

Nginx 的并發處理能力

關于 Nginx 的并發處理能力:并發連接數,一般優化后,峰值能保持在 1~3w 左右。(內存和 CPU 核心數不同,會有進一步優化空間)。Java面試寶典PDF完整版

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,797評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,179評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,628評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,642評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,444評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,948評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,040評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,185評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,717評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,602評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,794評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,316評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,045評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,418評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,671評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,414評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,750評論 2 370

推薦閱讀更多精彩內容