摘要：子進程啟動后監(jiān)控維護區(qū)。每來一個新的連接都會觸發(fā)新的事件，這些事件送給內(nèi)的狀態(tài)機來處理。大部分的邏輯上都有這樣的狀態(tài)機，只是實現(xiàn)方式不一樣。另外通過進程綁定技術(shù)可以進一步減少上下文切換和失效等系統(tǒng)開銷。

Nginx在web開發(fā)者眼中就是高并發(fā)高性能的代名詞，其基于事件的架構(gòu)也被眾多開發(fā)者效仿。我從Nginx的網(wǎng)站找到一篇技術(shù)文章將Nginx是怎樣實現(xiàn)的，文章是Nginx的產(chǎn)品老大Owen
Garrett在加入公司22個月時寫的，深入簡出。這篇博客后面的內(nèi)容盡量保證是對原文的翻譯，如果有個人理解或者延伸閱讀我會加標“譯注”。原文地址Inside NGINX: How We Designed for Performance & Scale

Nginx強勁的高性能表現(xiàn)來自其合理的軟件設(shè)計。傳統(tǒng)的web服務(wù)器和應(yīng)用服務(wù)器架構(gòu)設(shè)計上采用多進程或線程作為其處理業(yè)務(wù)的基本單位，而Nginx更多的使用了事件驅(qū)動的架構(gòu)。正是這種架構(gòu)使得Nginx可以輕松支持數(shù)十萬的并發(fā)鏈接。【譯注：Nginx相比其他的web服務(wù)器使用了更少的進程，將IO事件集中在固定的進程內(nèi)處理，減少了很多系統(tǒng)開銷，可以從下文理解到。】

The Inside NGINX infographic 較為清晰的講訴了Nginx如何在一個進程內(nèi)處理并發(fā)鏈接，下面我們深入看一下細節(jié)。

在講設(shè)計實現(xiàn)之前，有必要先看一下Ngxin如何在linux之上運行的。Nginx啟動會創(chuàng)建一個主進程（主管進程，負責(zé)讀取配置、綁定端口、管理其他子進程）和一些worker進程和輔助進程。

# service nginx restart
# ps -ef --forest | grep nginx
root     32475     1  0 13:36 ?        00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    32476 32475  0 13:36 ?        00:00:00  \_ nginx: worker process
nginx    32477 32475  0 13:36 ?        00:00:00  \_ nginx: worker process
nginx    32479 32475  0 13:36 ?        00:00:00  \_ nginx: worker process
nginx    32480 32475  0 13:36 ?        00:00:00  \_ nginx: worker process
nginx    32481 32475  0 13:36 ?        00:00:00  \_ nginx: cache manager process
nginx    32482 32475  0 13:36 ?        00:00:00  \_ nginx: cache loader process

這個示例運行在4核的server上，Nginx主進程創(chuàng)建4個worker進程和2個cahce輔助進程。

Unix應(yīng)用程序的基本要素是進程或者線程。（Linux OS調(diào)度不區(qū)分進程還是線程，二者的最大區(qū)別在于它們對于memory的共享程度。）進程或線程是一個自包含的可以獨立運行的任務(wù)，OS可以調(diào)度它到某個CPU核上執(zhí)行。有很多復(fù)雜的應(yīng)用程序運行在多進程或線程模式下是基于以下兩點考慮：

可以使用更多CPU資源。【譯注：還有memory、IO等其他資源】

可以輕松做到并行處理（比如，同時處理多個鏈接）。
進程和線程都會消耗資源，需要占用memory和其他OS資源，并且在運行時還有context switch的系統(tǒng)開銷。一般的server可以負擔(dān)幾百數(shù)量級的進程或者線程，當(dāng)進程或線程數(shù)量繼續(xù)上升到更高的數(shù)量級，memory消耗和IO阻塞引起的系統(tǒng)負荷會很高，使得應(yīng)用程序運行比較低效。

在設(shè)計網(wǎng)絡(luò)程序時，開發(fā)者會很自然的設(shè)計成每個進程或線程處理一個網(wǎng)絡(luò)連接。這種架構(gòu)比較簡單容易實現(xiàn)，但是比較難以擴展，尤其是當(dāng)網(wǎng)絡(luò)連接增長到上千以后。

Nginx可配置數(shù)量的進程，推薦配置數(shù)量和CPU的核數(shù)量相當(dāng)：

主進程讀配置，綁定端口，然后啟動一定數(shù)量的子進程。

cache loader子進程在啟動的時候運行，負責(zé)把硬盤上的數(shù)據(jù)搬進內(nèi)存，然后就退出了。因為它是一次性的任務(wù)，系統(tǒng)開銷很小。

cahce manager子進程啟動后監(jiān)控維護cache區(qū)。

worker子進程是真正處理業(yè)務(wù)的進程，負責(zé)處理網(wǎng)絡(luò)連接，讀寫硬盤，跟上游server交互等等。
Nginx推薦配置worker的數(shù)量跟CPU核數(shù)量線性關(guān)系，每個CPU核運行一個worker進程。可以通過配置 worker_processes auto來使用該推薦設(shè)置。

當(dāng)Nginx server處理業(yè)務(wù)時，worker進程們是最繁忙的，每個worker通過非阻塞的IO復(fù)用方式處理很多連接，盡量減少不必要的上下文切換。
每個worker進程都是單線程的進程，接收連接上的request并處理后回應(yīng)。進程間可以通過共享內(nèi)存的方式進行進程間通信。

每個Nginx worker進程由主進程讀取配置創(chuàng)建，通過accept_mutex競爭獲得要listen的socket并加入自己的IO監(jiān)聽列表中。
每來一個新的連接都會觸發(fā)新的事件，這些事件送給worker內(nèi)的狀態(tài)機來處理。（Nginx支持各種類型的狀態(tài)機，如http/tcp/SMTP/IMAP/POP3等）。大部分的web server邏輯上都有這樣的狀態(tài)機，只是實現(xiàn)方式不一樣。

我們可以想象類比狀態(tài)機是象棋游戲的規(guī)則。每個HTTP transaction(譯注：一組的Http請求，可以對應(yīng)成某個socket上發(fā)生的所有http請求）就是一個象棋游戲。對弈的一方是web server，可以類比為象棋大師。另一方為client，類比為象棋愛好者。
游戲的規(guī)則可以很復(fù)雜，比如web server需要跟其他application溝通協(xié)作完成業(yè)務(wù)處理，第三方的nginx模塊甚至可以擴展規(guī)則。

大多數(shù)的web服務(wù)器和應(yīng)用程序使用每個連接對應(yīng)一個進程或線程的模式來玩象棋游戲。每個進程或線程給一個client完成對弈直到游戲結(jié)束。在整個過程中，進程大部分時間都是處在阻塞狀態(tài)--等待client完成下一步走棋。

web服務(wù)器主進程在服務(wù)端口上監(jiān)聽新的連接（客戶端發(fā)起的新游戲的請求）。

有新的游戲請求時，主進程創(chuàng)建子進程負責(zé)完成跟客戶端的對弈。主進程繼續(xù)監(jiān)聽服務(wù)端口。

當(dāng)游戲結(jié)束時，子進程要么等待client開始新游戲（通過keepalive機制保活一段時間連接）要么退出（keepalive超時后）。
這種模型每玩一局server都要創(chuàng)建一個對應(yīng)的進程來完成對弈。這種架構(gòu)簡單并且容易容易擴展新功能，但有些大炮打蚊子，殺雞用牛刀的感覺。進程是個重器，系統(tǒng)開銷比較大，而解決的問題是個輕量級的問題。容易編程實現(xiàn)但是浪費比較大。

你可能聽說過一人同時對戰(zhàn)多人的象棋大賽

這就是Nginx worker進程的工作方式。每個worker進程（一般每個CPU核有一個worker進程）都是一個象棋大師，可以同時對弈數(shù)十萬對手。

worker進程等待listen和connection sockets的事件。（譯注：listen socket就是server用來監(jiān)聽新建連接的socket，connection socket是accept系統(tǒng)調(diào)用返回的新建socket，詳細可參加accept的手冊）

事件發(fā)生后，worker進程來處理這些事件：

listen socket的事件表示有新的客戶端要開始新的游戲。worker通過accept()創(chuàng)建新的connection socket，并加入監(jiān)聽列表。

connection socket的事件表示客戶端走了一步棋，worker進程可以做下一步應(yīng)對。
worker進程從不會在網(wǎng)絡(luò)IO上阻塞，當(dāng)它應(yīng)對完客戶端的走棋走出自己的一步后，可以馬上應(yīng)對下一個客戶端的走棋或接收新的連接請求。

Nginx的worker進程很容易擴展支持數(shù)十萬并發(fā)連接。每個新接入的連接只需要創(chuàng)建新的socket消耗少量的內(nèi)存，每個連接的系統(tǒng)開銷相對要比進程開銷小很多。另外通過Nginx worker進程綁定CPU技術(shù)可以進一步減少上下文切換和cache失效等系統(tǒng)開銷。
而阻塞式每個進程服務(wù)一個連接的方式，每個連接都會消耗很多資源，而且進程切換比較頻繁導(dǎo)致系統(tǒng)開銷比較大。
更詳細的解釋，可以參考這篇文章--Nginx架構(gòu)，作者是Ngxin的VP和共同創(chuàng)始人，Andrew Alexeev.

Nginx的這種少量進程的架構(gòu)使得更新配置和升級Nginx版本很容易。

更新Ngxin配置是一件非常容易事情而且非常可靠。很簡單的nginx -s reload就搞定了。運行這個命令實際上是給Nginx主進程發(fā)送了一個SIGHUP的信號，主進程收到該信號后做了兩件事情：

重新加載配置并且根據(jù)新的配置創(chuàng)建一組新的worker進程，這些新的進程可以馬上開始干活。

通知老的worker進程優(yōu)雅地退出。
重新裝載的過程會引起短暫的CPU和內(nèi)存的使用高峰，但這種影響總體來說比較微小，你甚至可以每秒多次做這個操作。

Nginx程序的升級就更加漂亮了，根本不會影響正在處理的連接，輕輕松松升級完成用戶根本沒有感覺。

Ngxin程序升級跟更新配置相似。啟動新的Nginx主進程，它會跟舊的主進程共享listen sockets。新的進程起來后，你可以發(fā)送信號給舊的進程退出。詳細過程可以參看Controlling Nginx.

The Inside NGINX infographic描述了Nginx的整體功能，其實它概括性描述的背后是Nginx開發(fā)人員十幾年的創(chuàng)新和優(yōu)化。如果你想了解更多，可以參看這些材料：
Installing and Tuning Nginx for Performance
Tuning Nginx for Performance
The Architecture of Open Source Applications – NGINX
Socket Sharding in NGINX Release 1.9.1 (using the SO_REUSEPORT socket option)