為了更好地理解設(shè)計(jì)，你需要了解NGINX是如何工作的。
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)代硬件上成千上萬(wà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)程（cachehelper processes）來(lái)管理磁盤(pán)內(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)核頻繁切換(被稱(chēng)作上下文切換（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)用程序需要處理成千上萬(wàn)的并發(fā)連接時(shí)，這種架構(gòu)的擴(kuò)展性就會(huì)出現(xiàn)問(wèn)題。
NGINX是如何工作的?
How Does NGINX Work?
NGINX使用一個(gè)了可預(yù)見(jiàn)式的（predictable）進(jìn)程模型，調(diào)度可用的硬件資源：
1.主進(jìn)程執(zhí)行特權(quán)操作，如讀取配置和綁定端口，還負(fù)責(zé)創(chuàng)建子進(jìn)程(下面的三種類(lèi)型)。
2.緩存加載進(jìn)程（cache loader process）在啟動(dòng)時(shí)運(yùn)行，把基于磁盤(pán)的緩存（disk-based cache）加載到內(nèi)存中，然后退出。對(duì)它的調(diào)度很謹(jǐn)慎，所以其資源需求很低。
3.緩存管理進(jìn)程（cache manager process）周期性運(yùn)行，并削減磁盤(pán)緩存（prunes entries from the disk caches），以使其保持在配置范圍內(nèi)。
4.工作進(jìn)程（worker processes）才是執(zhí)行所有實(shí)際任務(wù)的進(jìn)程：處理網(wǎng)絡(luò)連接、讀取和寫(xiě)入內(nèi)容到磁盤(pán)，與上游服務(wù)器通信等。
多數(shù)情況下，NGINX建議每1個(gè)CPU核心都運(yùn)行1個(gè)工作進(jìn)程，使硬件資源得到最有效的利用。你可以在配置中設(shè)置如下指令： worker_processesauto 當(dāng)NGINX服務(wù)器在運(yùn)行時(shí)，只有工作進(jìn)程在忙碌。每個(gè)工作進(jìn)程都以非阻塞的方式處理多個(gè)連接，以消減上下文切換的開(kāi)銷(xiāo)。 每個(gè)工作進(jìn)程都是單線程且獨(dú)立運(yùn)行的，抓取并處理新的連接。進(jìn)程間通過(guò)共享內(nèi)存的方式，來(lá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)聽(tīng)套接字（listen sockets）。

NGINX工作進(jìn)程會(huì)監(jiān)聽(tīng)套接字上的事件(accept_mutex和kernel socketsharding)，來(lái)決定什么時(shí)候開(kāi)始工作。事件是由新的連接初始化的。這些連接被會(huì)分配給狀態(tài)機(jī)（statemachine）—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ù)器也使用類(lèi)似的狀態(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）都是一局象棋比賽。棋盤(pán)的一邊是web服務(wù)器—坐著一位可以迅速做出決定的大師級(jí)棋手。另一邊是遠(yuǎn)程客戶(hù)端—在相對(duì)較慢的網(wǎng)絡(luò)中，訪問(wèn)站點(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è)線程的模型來(lái)進(jìn)行這局國(guó)際象棋比賽。每個(gè)進(jìn)程或線程都包含一個(gè)將比賽玩到最后的指令。在這個(gè)過(guò)程中，進(jìn)程是由服務(wù)器來(lái)運(yùn)行的，它的大部分時(shí)間都花在“阻塞（blocked）”上，等待客戶(hù)端完成其下一個(gè)動(dòng)作。

1.web服務(wù)器進(jìn)程（web server process）在監(jiān)聽(tīng)套接字上，監(jiān)聽(tīng)新的連接（客戶(hù)端發(fā)起的新比賽）。
2.一局新的比賽發(fā)起后，進(jìn)程就開(kāi)始工作，每一步棋下完后都進(jìn)入阻塞狀態(tài)，等待客戶(hù)端走下一步棋。
3.一旦比賽結(jié)束，web服務(wù)器進(jìn)程會(huì)看看客戶(hù)是否想開(kāi)始新的比賽（這相當(dāng)于一個(gè)存活的連接）。如果連接被關(guān)閉（客戶(hù)端離開(kāi)或者超時(shí)），web服務(wù)器進(jìn)程會(huì)回到監(jiān)聽(tīng)狀態(tài)，等待全新的比賽。
記住重要的一點(diǎn)：每一個(gè)活躍的HTTP連接（每局象棋比賽）都需要一個(gè)專(zhuān)用的進(jìn)程或線程（一位大師級(jí)棋手）。這種架構(gòu)非常易于擴(kuò)展第三方模塊(“新規(guī)則”)。然而，這里存在著一個(gè)巨大的不平衡：一個(gè)以文件描述符（file detor）和少量?jī)?nèi)存為代表的輕量級(jí)HTTP連接，會(huì)映射到一個(gè)單獨(dú)的進(jìn)程或線程—它們是非常重量級(jí)的操作系統(tǒng)對(duì)象。這在編程上是方便的，但它造成了巨大的浪費(fèi)。
NGINX是真正的大師
NGINX is a True Grandmaster
也許你聽(tīng)說(shuō)過(guò)車(chē)輪表演賽，在比賽中一個(gè)象棋大師要在同一時(shí)間對(duì)付幾十個(gè)對(duì)手。

Kiril Georgiev在保加利亞首都索菲亞同時(shí)對(duì)陣360名棋手，最終取得284勝，70平，6負(fù)的戰(zhàn)績(jī)。
這就是 NGINX工作進(jìn)程玩“國(guó)際象棋”的方式。每一個(gè)工作進(jìn)程都是一位大師（記?。和ǔＧ闆r下，每個(gè)工作進(jìn)程占用一個(gè)CPU內(nèi)核），能夠同時(shí)對(duì)戰(zhàn)上百棋手（實(shí)際上是成千上萬(wàn)）。

1.工作進(jìn)程在監(jiān)聽(tīng)套接字和連接套接字上等待事件。
2.事件發(fā)生在套接字上，工作進(jìn)程會(huì)處理這些事件。
監(jiān)聽(tīng)套接字上的事件意味著：客戶(hù)端開(kāi)始了一局新的游戲。工作進(jìn)程創(chuàng)建了一個(gè)新的連接套接字。
連接套接字上的事件意味著：客戶(hù)端移動(dòng)了棋子。工作進(jìn)程會(huì)迅速響應(yīng)。
工作進(jìn)程從不會(huì)在網(wǎng)絡(luò)上停止，它時(shí)時(shí)刻刻都在等待其“對(duì)手”（客戶(hù)端）做出回應(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ù)以萬(wàn)計(jì)的連接。每個(gè)新連接都會(huì)創(chuàng)建另一個(gè)文件描述符，并消耗工作進(jìn)程中少量的額外內(nèi)存。每一個(gè)連接的額外消耗都很少。NGINX進(jìn)程可以保持固定的CPU占用率。當(dāng)沒(méi)有工作時(shí)，上下文切換也較少。
在阻塞式的、一個(gè)連接/一個(gè)進(jìn)程的模式中，每個(gè)連接需要大量的額外資源和開(kāi)銷(xiāo)，并且上下文切換(從一個(gè)進(jìn)程到另一個(gè)進(jìn)程)非常頻繁。
如果想了解更多，請(qǐng)查看由NGINX公司發(fā)展和聯(lián)合創(chuàng)始人副總裁Andrew Alexeev編寫(xiě)的有關(guān) NGINX體系結(jié)構(gòu)的文章。
通過(guò)適當(dāng)?shù)南到y(tǒng)調(diào)優(yōu)，NGINX能大規(guī)模地處理每個(gè)工作進(jìn)程數(shù)十萬(wàn)并發(fā)的HTTP連接，并且能在流量高峰期間不丟失任何信息（新比賽開(kāi)始）。
配置更新和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ì)檢查磁盤(pán)上的配置，并給主進(jìn)程發(fā)送一個(gè)SIGHUP信號(hào)。
當(dāng)主進(jìn)程接收到SIGHUP信號(hào)后，會(huì)做兩件事：
1.重新加載配置，fork一套新的工作進(jìn)程。這些新的工作進(jìn)程會(huì)立即開(kāi)始接受連接和處理流量（traffic）（使用新的配置）。
2.發(fā)出信號(hào)，通知舊的工作進(jìn)程安靜地退出。這些舊進(jìn)程不會(huì)再接受新的連接了。只要它們處理的HTTP請(qǐng)求結(jié)束了，它們就會(huì)干凈地關(guān)閉連接。一旦所有的連接都被關(guān)閉，工作進(jìn)程也就退出了。
這個(gè)過(guò)程會(huì)導(dǎo)致CPU占用率和內(nèi)存使用的一個(gè)小高峰，但相比于從活動(dòng)連接中加載資源，這個(gè)小高峰可忽略不計(jì)。你可以在一秒內(nèi)重新加載配置多次。極少情況下，一代又一代工作進(jìn)程等待連接關(guān)閉時(shí)會(huì)出現(xiàn)問(wèn)題，但即便出現(xiàn)問(wèn)題，它們也會(huì)被立即解決掉。
NGINX的二進(jìn)制升級(jí)過(guò)程更加神奇—你可以飛速地升級(jí)NGINX本身，服務(wù)器不會(huì)有任何的丟連接、宕機(jī)、或服務(wù)中斷等情況。

二進(jìn)制升級(jí)過(guò)程與配置更新相似。新的NGINX主進(jìn)程與原來(lái)的主進(jìn)程并行，它們共享監(jiān)聽(tīng)套接字。兩個(gè)進(jìn)程都是活躍的（active），它們各自的工作進(jìn)程處理各自的流量（traffic）。然后，你可以通知舊的主進(jìn)程與其工作進(jìn)程完美退出。
在Controlling NGINX中，整個(gè)過(guò)程有更詳細(xì)的描述。
結(jié)論
Conclusion
NGINX的內(nèi)部圖表高度概述了NGINX是如何運(yùn)作的，但在這簡(jiǎn)單的解釋背后是超過(guò)十年的創(chuàng)新與優(yōu)化。這些創(chuàng)新與優(yōu)化，使NGINX在多種硬件上表現(xiàn)出良好的性能，同時(shí)還具備現(xiàn)代web應(yīng)用所需要的安全性和可靠性。
如果你想閱讀更多關(guān)于NGINX優(yōu)化的資料，可以看看這些很棒的資源：
l NGINX安裝和性能調(diào)優(yōu)(webinar; slides at Speaker Deck)
l NGINX的性能調(diào)優(yōu)
l 開(kāi)源應(yīng)用架構(gòu)—NGINX
l NGINX1.9.1套接字切分（Socket Sharding）(使用SO_REUSEPORT套接字選項(xiàng))
翻譯：張迪
原文出處：Inside NGINX: How We Designed for Performance & Scale
如果您發(fā)現(xiàn)這篇譯文的任何問(wèn)題，可隨時(shí)與我們聯(lián)系。
我們水平有限，但理想高遠(yuǎn)。我們旨在分享優(yōu)質(zhì)的內(nèi)容。
我們也同樣期待理想的您對(duì)這個(gè)世界的貢獻(xiàn)。歡迎任何目的的聯(lián)系。
我們的郵箱是：weikan@jointforce.com。
我們的QQ是：3272840549。（來(lái)源：cnBeta.COM）