佳木斯湛栽影视文化发展公司

主頁 > 知識(shí)庫 > 深入理解nginx如何實(shí)現(xiàn)高性能和可擴(kuò)展性

深入理解nginx如何實(shí)現(xiàn)高性能和可擴(kuò)展性

熱門標(biāo)簽:網(wǎng)站建設(shè) 百度競(jìng)價(jià)點(diǎn)擊價(jià)格的計(jì)算公式 阿里云 智能手機(jī) 檢查注冊(cè)表項(xiàng) 美圖手機(jī) 使用U盤裝系統(tǒng) 硅谷的囚徒呼叫中心

NGINX的整體架構(gòu)的特點(diǎn)是由一組進(jìn)程協(xié)同工作:

主進(jìn)程:負(fù)責(zé)執(zhí)行特權(quán)操作,如閱讀配置文件、綁定套接字、創(chuàng)建/通知協(xié)調(diào)(Signalling)子進(jìn)程。

工作進(jìn)程:負(fù)責(zé)接收和處理連接請(qǐng)求,讀取和寫入磁盤,并與上游服務(wù)器通信。當(dāng)NGINX處于活躍狀態(tài)時(shí),只有工作進(jìn)程是忙碌的。

緩存加載器進(jìn)程:負(fù)責(zé)將磁盤高速緩存加載到內(nèi)存中。這個(gè)進(jìn)程在啟動(dòng)時(shí)運(yùn)行后隨即退出。

緩存管理器進(jìn)程:負(fù)責(zé)整理磁盤緩存的數(shù)據(jù)保證其不越界。這個(gè)進(jìn)程會(huì)間歇性運(yùn)行。

NGINX能夠?qū)崿F(xiàn)高性能和可擴(kuò)展性的關(guān)鍵取決于兩個(gè)基本的設(shè)計(jì)選型:

盡可能限制工作進(jìn)程的數(shù)量,從而減少上下文切換帶來的開銷。默認(rèn)和推薦配置是讓每個(gè)CPU內(nèi)核對(duì)應(yīng)一個(gè)工作進(jìn)程,從而高效利用硬件資源。

工作進(jìn)程采用單線程,并以非阻塞的方式處理多個(gè)并發(fā)連接。

NGINX的每個(gè)工作進(jìn)程通過狀態(tài)機(jī)處理多個(gè)連接請(qǐng)求,這個(gè)狀態(tài)機(jī)被實(shí)現(xiàn)為非阻塞的工作方式:

每個(gè)工作進(jìn)程需要處理若干套接字,包括監(jiān)聽套接字或者連接套接字。

當(dāng)監(jiān)聽套接字收到新的請(qǐng)求時(shí),會(huì)打開一個(gè)新的連接套接字來處理與客戶端的通信。

當(dāng)一個(gè)事件到達(dá)連接套接字時(shí),工作進(jìn)程迅速完成響應(yīng),并轉(zhuǎn)而處理其他任何套接字新收到的事件。

Garrett說,NGINX選擇這樣的設(shè)計(jì),使它從根本上區(qū)別于其他Web服務(wù)器。通常的Web服務(wù)器會(huì)選用將每個(gè)連接分配給獨(dú)立線程的模式,這使得多個(gè)連接的處理非常容易,因?yàn)槊總€(gè)連接可以被認(rèn)為是包含多個(gè)步驟的一個(gè)線性序列,但這樣會(huì)產(chǎn)生上下文切換的開銷。事實(shí)上,工作線程大部分的時(shí)間處于阻塞的狀態(tài),在等待客戶端或其它上游服務(wù)器。當(dāng)試圖執(zhí)行I/O等操作的并發(fā)連接數(shù)/線程數(shù)的規(guī)模超過一定閾值,或是內(nèi)存消耗殆盡的時(shí)候,上下文切換的成本就顯現(xiàn)出來了。

從另一方面講,NGINX的設(shè)計(jì)是不讓工作進(jìn)程阻止網(wǎng)絡(luò)流量,除非沒有任何工作要做。此外,每一個(gè)新的連接只消耗很少的資源,僅包括一個(gè)文件描述符和少量的工作進(jìn)程內(nèi)存。

總的來說,NGINX的這種工作模式在系統(tǒng)調(diào)優(yōu)后,它的每個(gè)工作進(jìn)程都能夠處理成百上千的HTTP并發(fā)連接。

深入NGINX:我們?nèi)绾卧O(shè)計(jì)它的性能和擴(kuò)展性

NGINX之所以能在性能上如此優(yōu)越,是由于其背后的設(shè)計(jì)。許多web服務(wù)器和應(yīng)用服務(wù)器使用簡(jiǎn)單的線程的(threaded)、或基于流程的(process-based)架構(gòu),NGINX則以一種復(fù)雜的事件驅(qū)動(dòng)(event-driven)的架構(gòu)脫穎而出,這種架構(gòu)能支持現(xiàn)代硬件上成千上萬的并發(fā)連接。

Inside NGINX infographic涉及了從高層次進(jìn)程架構(gòu)的挖掘,到NGINX的單進(jìn)程處理多連接的圖解。本篇文章講解了這些工作細(xì)節(jié)。

設(shè)置場(chǎng)景——NGINX進(jìn)程模型

Setting the Scene ? the NGINX Process Model

為了更好地理解設(shè)計(jì),你需要了解NGINX是如何工作的。NGINX有一個(gè)主進(jìn)程(master process)(執(zhí)行特權(quán)操作,如讀取配置、綁定端口)和一系列工作進(jìn)程(worker process)和輔助進(jìn)程(helper process)。

這個(gè)四核服務(wù)器內(nèi),NGINX主進(jìn)程創(chuàng)建了4個(gè)工作進(jìn)程和2個(gè)緩存輔助進(jìn)程(cache helper processes)來管理磁盤內(nèi)容緩存(on-disk content cache)。

為什么架構(gòu)很重要?

Why Is Architecture Important?

任何Unix應(yīng)用程序的根本基礎(chǔ)都是線程或進(jìn)程。(從Linux操作系統(tǒng)的角度看,線程和進(jìn)程基本上是相同的,主要區(qū)別是他們共享內(nèi)存的程度。) 進(jìn)程或線程,是一組操作系統(tǒng)可調(diào)度的、運(yùn)行在CPU內(nèi)核上的獨(dú)立指令集。大多數(shù)復(fù)雜的應(yīng)用程序都并行運(yùn)行多個(gè)線程或進(jìn)程,原因有兩個(gè):

● 可以同時(shí)使用更多的計(jì)算機(jī)內(nèi)核。

●線程和進(jìn)程使并行操作很容易實(shí)現(xiàn)(例如,同時(shí)處理多個(gè)連接)。

進(jìn)程和線程都消耗資源。它們都使用內(nèi)存和其他OS資源,導(dǎo)致內(nèi)核頻繁切換(被稱作上下文切換(context switch)的操作)。大多數(shù)現(xiàn)代服務(wù)器可以同時(shí)處理數(shù)百個(gè)小的、活躍的(active)線程或進(jìn)程,但一旦內(nèi)存耗盡,或高I/O負(fù)載導(dǎo)致大量的上下文切換時(shí),服務(wù)器的性能就會(huì)嚴(yán)重下降。

對(duì)于網(wǎng)絡(luò)應(yīng)用,通常會(huì)為每個(gè)連接(connection)分配一個(gè)線程或進(jìn)程。這種架構(gòu)易于實(shí)現(xiàn),但是當(dāng)應(yīng)用程序需要處理成千上萬的并發(fā)連接時(shí),這種架構(gòu)的擴(kuò)展性就會(huì)出現(xiàn)問題。

NGINX是如何工作的?

How Does NGINX Work?

NGINX使用一個(gè)了可預(yù)見式的(predictable)進(jìn)程模型,調(diào)度可用的硬件資源:

1.主進(jìn)程執(zhí)行特權(quán)操作,如讀取配置和綁定端口,還負(fù)責(zé)創(chuàng)建子進(jìn)程(下面的三種類型)。

2.緩存加載進(jìn)程(cache loader process)在啟動(dòng)時(shí)運(yùn)行,把基于磁盤的緩存(disk-based cache)加載到內(nèi)存中,然后退出。對(duì)它的調(diào)度很謹(jǐn)慎,所以其資源需求很低。

3.緩存管理進(jìn)程(cache manager process)周期性運(yùn)行,并削減磁盤緩存(prunes entries from the disk caches),以使其保持在配置范圍內(nèi)。

4.工作進(jìn)程(worker processes)才是執(zhí)行所有實(shí)際任務(wù)的進(jìn)程:處理網(wǎng)絡(luò)連接、讀取和寫入內(nèi)容到磁盤,與上游服務(wù)器通信等。

多數(shù)情況下,NGINX建議每1個(gè)CPU核心都運(yùn)行1個(gè)工作進(jìn)程,使硬件資源得到最有效的利用。你可以在配置中設(shè)置如下指令:

worker_processes auto

當(dāng)NGINX服務(wù)器在運(yùn)行時(shí),只有工作進(jìn)程在忙碌。每個(gè)工作進(jìn)程都以非阻塞的方式處理多個(gè)連接,以消減上下文切換的開銷。

每個(gè)工作進(jìn)程都是單線程且獨(dú)立運(yùn)行的,抓取并處理新的連接。進(jìn)程間通過共享內(nèi)存的方式,來共享緩存數(shù)據(jù)、會(huì)話持久性數(shù)據(jù)(session persistence data)和其他共享資源。

NGINX內(nèi)部的工作進(jìn)程

Inside the NGINX Worker Process

每一個(gè)NGINX的工作進(jìn)程都是NGINX配置(NGINX configuration)初始化的,并被主進(jìn)程設(shè)置了一組監(jiān)聽套接字(listen sockets)。

NGINX工作進(jìn)程會(huì)監(jiān)聽套接字上的事件(accept_mutex和kernel socket sharding),來決定什么時(shí)候開始工作。事件是由新的連接初始化的。這些連接被會(huì)分配給狀態(tài)機(jī)(state machine)——HTTP狀態(tài)機(jī)是最常用的,但NGINX還為流(原生TCP)和大量的郵件協(xié)議(SMTP,IMAP和POP3)實(shí)現(xiàn)了狀態(tài)機(jī)。

狀態(tài)機(jī)本質(zhì)上是一組告知NGINX如何處理請(qǐng)求的指令。大多數(shù)和NGINX具有相同功能的web服務(wù)器也使用類似的狀態(tài)機(jī)——只是實(shí)現(xiàn)不同。

調(diào)度狀態(tài)機(jī)

Scheduling the State Machine

把狀態(tài)機(jī)想象成國(guó)際象棋的規(guī)則。每個(gè)HTTP事務(wù)(HTTP transaction)都是一局象棋比賽。棋盤的一邊是web服務(wù)器——坐著一位可以迅速做出決定的大師級(jí)棋手。另一邊是遠(yuǎn)程客戶端——在相對(duì)較慢的網(wǎng)絡(luò)中,訪問站點(diǎn)或應(yīng)用程序的web瀏覽器。

然而,比賽的規(guī)則可能會(huì)很復(fù)雜。例如,web服務(wù)器可能需要與各方溝通(代理一個(gè)上游的應(yīng)用程序),或者和認(rèn)證服務(wù)器交流。web服務(wù)器的第三方模塊也可以拓展比賽規(guī)則。

阻塞狀態(tài)機(jī)

A Blocking State Machine

回憶一下我們之前對(duì)進(jìn)程和線程的描述:是一組操作系統(tǒng)可調(diào)度的、運(yùn)行在CPU內(nèi)核上的獨(dú)立指令集。大多數(shù)web服務(wù)器和web應(yīng)用都使用一個(gè)連接 /一個(gè)進(jìn)程或一個(gè)連接/一個(gè)線程的模型來進(jìn)行這局國(guó)際象棋比賽。每個(gè)進(jìn)程或線程都包含一個(gè)將比賽玩到最后的指令。在這個(gè)過程中,進(jìn)程是由服務(wù)器來運(yùn)行的,它的大部分時(shí)間都花在“阻塞(blocked)”上,等待客戶端完成其下一個(gè)動(dòng)作。

1.web服務(wù)器進(jìn)程(web server process)在監(jiān)聽套接字上,監(jiān)聽新的連接(客戶端發(fā)起的新比賽)。

2.一局新的比賽發(fā)起后,進(jìn)程就開始工作,每一步棋下完后都進(jìn)入阻塞狀態(tài),等待客戶端走下一步棋。

3.一旦比賽結(jié)束,web服務(wù)器進(jìn)程會(huì)看看客戶是否想開始新的比賽(這相當(dāng)于一個(gè)存活的連接)。如果連接被關(guān)閉(客戶端離開或者超時(shí)),web服務(wù)器進(jìn)程會(huì)回到監(jiān)聽狀態(tài),等待全新的比賽。

記住重要的一點(diǎn):每一個(gè)活躍的HTTP連接(每局象棋比賽)都需要一個(gè)專用的進(jìn)程或線程(一位大師級(jí)棋手)。這種架構(gòu)非常易于擴(kuò)展第三方模塊 (“新規(guī)則”)。然而,這里存在著一個(gè)巨大的不平衡:一個(gè)以文件描述符(file descriptor)和少量?jī)?nèi)存為代表的輕量級(jí)HTTP連接,會(huì)映射到一個(gè)單獨(dú)的進(jìn)程或線程——它們是非常重量級(jí)的操作系統(tǒng)對(duì)象。這在編程上是方便的,但它造成了巨大的浪費(fèi)。

NGINX是真正的大師

NGINX is a True Grandmaster

也許你聽說過車輪表演賽,在比賽中一個(gè)象棋大師要在同一時(shí)間對(duì)付幾十個(gè)對(duì)手。

Kiril Georgiev在保加利亞首都索菲亞同時(shí)對(duì)陣360名棋手,最終取得284勝,70平,6負(fù)的戰(zhàn)績(jī)。

這就是NGINX工作進(jìn)程玩“國(guó)際象棋”的方式。每一個(gè)工作進(jìn)程都是一位大師(記住:通常情況下,每個(gè)工作進(jìn)程占用一個(gè)CPU內(nèi)核),能夠同時(shí)對(duì)戰(zhàn)上百棋手(實(shí)際上是成千上萬)。

1.工作進(jìn)程在監(jiān)聽套接字和連接套接字上等待事件。

2.事件發(fā)生在套接字上,工作進(jìn)程會(huì)處理這些事件。

●監(jiān)聽套接字上的事件意味著:客戶端開始了一局新的游戲。工作進(jìn)程創(chuàng)建了一個(gè)新的連接套接字。

●連接套接字上的事件意味著:客戶端移動(dòng)了棋子。工作進(jìn)程會(huì)迅速響應(yīng)。

工作進(jìn)程從不會(huì)在網(wǎng)絡(luò)上停止,它時(shí)時(shí)刻刻都在等待其“對(duì)手”(客戶端)做出回應(yīng)。當(dāng)它已經(jīng)移動(dòng)了這局比賽的棋子,它會(huì)立即去處理下一局比賽,或者迎接新的對(duì)手。

為什么它會(huì)比阻塞式多進(jìn)程的架構(gòu)更快?

Why Is This Faster than a Blocking, Multi-Process Architecture?

NGINX的規(guī)??梢院芎玫刂С置總€(gè)工作進(jìn)程上數(shù)以萬計(jì)的連接。每個(gè)新連接都會(huì)創(chuàng)建另一個(gè)文件描述符,并消耗工作進(jìn)程中少量的額外內(nèi)存。每一個(gè)連接的額外消耗都很少。NGINX進(jìn)程可以保持固定的CPU占用率。當(dāng)沒有工作時(shí),上下文切換也較少。

在阻塞式的、一個(gè)連接/一個(gè)進(jìn)程的模式中,每個(gè)連接需要大量的額外資源和開銷,并且上下文切換(從一個(gè)進(jìn)程到另一個(gè)進(jìn)程)非常頻繁。

如果想了解更多,請(qǐng)查看由NGINX公司發(fā)展和聯(lián)合創(chuàng)始人副總裁Andrew Alexeev編寫的有關(guān)NGINX體系結(jié)構(gòu)的文章。

通過適當(dāng)?shù)南到y(tǒng)調(diào)優(yōu),NGINX能大規(guī)模地處理每個(gè)工作進(jìn)程數(shù)十萬并發(fā)的HTTP連接,并且能在流量高峰期間不丟失任何信息(新比賽開始)。

配置更新和NGINX升級(jí)

Updating Configuration and Upgrading NGINX

僅包含少量工作進(jìn)程的NGINX進(jìn)程架構(gòu),使得配置、甚至是二進(jìn)制文件本身的更新都非常高效。

更新NGINX的配置,是一個(gè)非常簡(jiǎn)單的、輕量級(jí)的、可靠的操作。運(yùn)行nginx ?s reload命令即可,該命令會(huì)檢查磁盤上的配置,并給主進(jìn)程發(fā)送一個(gè)SIGHUP信號(hào)。

當(dāng)主進(jìn)程接收到SIGHUP信號(hào)后,會(huì)做兩件事:

1.重新加載配置,fork一套新的工作進(jìn)程。這些新的工作進(jìn)程會(huì)立即開始接受連接和處理流量(traffic)(使用新的配置)。

2.發(fā)出信號(hào),通知舊的工作進(jìn)程安靜地退出。這些舊進(jìn)程不會(huì)再接受新的連接了。只要它們處理的HTTP請(qǐng)求結(jié)束了,它們就會(huì)干凈地關(guān)閉連接。一旦所有的連接都被關(guān)閉,工作進(jìn)程也就退出了。

這個(gè)過程會(huì)導(dǎo)致CPU占用率和內(nèi)存使用的一個(gè)小高峰,但相比于從活動(dòng)連接中加載資源,這個(gè)小高峰可忽略不計(jì)。你可以在一秒內(nèi)重新加載配置多次。極少情況下,一代又一代工作進(jìn)程等待連接關(guān)閉時(shí)會(huì)出現(xiàn)問題,但即便出現(xiàn)問題,它們也會(huì)被立即解決掉。

NGINX的二進(jìn)制升級(jí)過程更加神奇——你可以飛速地升級(jí)NGINX本身,服務(wù)器不會(huì)有任何的丟連接、宕機(jī)、或服務(wù)中斷等情況。

二進(jìn)制升級(jí)過程與配置更新相似。新的NGINX主進(jìn)程與原來的主進(jìn)程并行,它們共享監(jiān)聽套接字。兩個(gè)進(jìn)程都是活躍的(active),它們各自的工作進(jìn)程處理各自的流量(traffic)。然后,你可以通知舊的主進(jìn)程與其工作進(jìn)程完美退出。

在Controlling NGINX中,整個(gè)過程有更詳細(xì)的描述。

結(jié)論

Conclusion

NGINX的內(nèi)部圖表高度概述了NGINX是如何運(yùn)作的,但在這簡(jiǎn)單的解釋背后是超過十年的創(chuàng)新與優(yōu)化。這些創(chuàng)新與優(yōu)化,使NGINX在多種硬件上表現(xiàn)出良好的性能,同時(shí)還具備現(xiàn)代web應(yīng)用所需要的安全性和可靠性。

以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。

標(biāo)簽:湘潭 煙臺(tái) 湖北 黃山 山南 賀州 通遼 懷化

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《深入理解nginx如何實(shí)現(xiàn)高性能和可擴(kuò)展性》,本文關(guān)鍵詞  ;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 收縮
    • 微信客服
    • 微信二維碼
    • 電話咨詢

    • 400-1100-266
    萍乡市| 英超| 界首市| 砚山县| 景宁| 兴和县| 威宁| 安康市| 自治县| 绿春县| 百色市| 苏州市| 白朗县| 穆棱市| 乐都县| 甘南县| 福贡县| 迁安市| 东宁县| 武宁县| 壤塘县| 花莲市| 额济纳旗| 孝感市| 梁平县| 昌吉市| 三穗县| 女性| 乌兰浩特市| 大连市| 舒城县| 逊克县| 方正县| 浑源县| 巴中市| 祁阳县| 邹平县| 岐山县| 通州市| 台前县| 永德县|