.jpg)
nginx在啟動后，在unix系統(tǒng)中會以daemon的方式在后臺運(yùn)行，后臺進(jìn)程包含一個master進(jìn)程和多個worker進(jìn)程。我們也可以手動地關(guān)掉后臺模式，讓nginx在前臺運(yùn)行，并且通過配置讓nginx取消master進(jìn)程，從而可以使nginx以單進(jìn)程方式運(yùn)行。
很顯然，生產(chǎn)環(huán)境下我們肯定不會這么做，所以關(guān)閉后臺模式，一般是用來調(diào)試用的，在后面的章節(jié)里面，我們會詳細(xì)地講解如何調(diào)試nginx。
所以，我們可以看到，nginx是以多進(jìn)程的方式來工作的，當(dāng)然nginx也是支持多線程的方式的，只是我們主流的方式還是多進(jìn)程的方式，也是nginx的默認(rèn)方式。nginx采用多進(jìn)程的方式有諸多好處，所以我就主要講解nginx的多進(jìn)程模式吧。
剛才講到，nginx在啟動后，會有一個master進(jìn)程和多個worker進(jìn)程。master進(jìn)程主要用來管理worker進(jìn)程，包含：接收來自外界的信號，向各worker進(jìn)程發(fā)送信號，監(jiān)控worker進(jìn)程的運(yùn)行狀態(tài)，當(dāng)worker進(jìn)程退出后(異常情況下)，會自動重新啟動新的worker進(jìn)程。
而基本的網(wǎng)絡(luò)事件，則是放在worker進(jìn)程中來處理了。多個worker進(jìn)程之間是對等的，他們同等競爭來自客戶端的請求，各進(jìn)程互相之間是獨立的。一個請求，只可能在一個worker進(jìn)程中處理，一個worker進(jìn)程，不可能處理其它進(jìn)程的請求。worker進(jìn)程的個數(shù)是可以設(shè)置的，一般我們會設(shè)置與機(jī)器cpu核數(shù)一致，這里面的原因與nginx的進(jìn)程模型以及事件處理模型是分不開的。
在nginx啟動后，如果我們要操作nginx，要怎么做呢？
從上文中我們可以看到，master來管理worker進(jìn)程，所以我們只需要與master進(jìn)程通信就行了。master進(jìn)程會接收來自外界發(fā)來的信號，再根據(jù)信號做不同的事情。所以我們要控制nginx，只需要通過kill向master進(jìn)程發(fā)送信號就行了。比如kill -HUP pid，則是告訴nginx，從容地重啟nginx，我們一般用這個信號來重啟nginx，或重新加載配置，因為是從容地重啟，因此服務(wù)是不中斷的。master進(jìn)程在接收到HUP信號后是怎么做的呢？
首先master進(jìn)程在接到信號后，會先重新加載配置文件，然后再啟動新的worker進(jìn)程，并向所有老的worker進(jìn)程發(fā)送信號，告訴他們可以光榮退休了。
新的worker在啟動后，就開始接收新的請求，而老的worker在收到來自master的信號后，就不再接收新的請求，并且在當(dāng)前進(jìn)程中的所有未處理完的請求處理完成后，再退出。
當(dāng)然，直接給master進(jìn)程發(fā)送信號，這是比較老的操作方式，nginx在0.8版本之后，引入了一系列命令行參數(shù)，來方便我們管理。比如，./nginx -s reload，就是來重啟nginx，./nginx -s stop，就是來停止nginx的運(yùn)行。
如何做到的呢？
我們還是拿reload來說，我們看到，執(zhí)行命令時，我們是啟動一個新的nginx進(jìn)程，而新的nginx進(jìn)程在解析到reload參數(shù)后，就知道我們的目的是控制nginx來重新加載配置文件了，它會向master進(jìn)程發(fā)送信號，然后接下來的動作，就和我們直接向master進(jìn)程發(fā)送信號一樣了。
現(xiàn)在，我們知道了當(dāng)我們在操作nginx的時候，nginx內(nèi)部做了些什么事情，那么，worker進(jìn)程又是如何處理請求的呢？我們前面有提到，worker進(jìn)程之間是平等的，每個進(jìn)程，處理請求的機(jī)會也是一樣的。當(dāng)我們提供80端口的http服務(wù)時，一個連接請求過來，每個進(jìn)程都有可能處理這個連接，怎么做到的呢？
首先，每個worker進(jìn)程都是從master進(jìn)程fork過來，在master進(jìn)程里面，先建立好需要listen的socket（listenfd）之后，然后再fork出多個worker進(jìn)程。所有worker進(jìn)程的listenfd會在新連接到來時變得可讀，為保證只有一個進(jìn)程處理該連接，所有worker進(jìn)程在注冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進(jìn)程注冊listenfd讀事件，在讀事件里調(diào)用accept接受該連接。
當(dāng)一個worker進(jìn)程在accept這個連接之后，就開始讀取請求，解析請求，處理請求，產(chǎn)生數(shù)據(jù)后，再返回給客戶端，最后才斷開連接，這樣一個完整的請求就是這樣的了。我們可以看到，一個請求，完全由worker進(jìn)程來處理，而且只在一個worker進(jìn)程中處理。
多線程模型 VS 多進(jìn)程模型，這是個問題！
那么，nginx采用這種進(jìn)程模型有什么好處呢？當(dāng)然，好處肯定會很多了。首先，對于每個worker進(jìn)程來說，獨立的進(jìn)程，不需要加鎖，所以省掉了鎖帶來的開銷，同時在編程以及問題查找時，也會方便很多。其次，采用獨立的進(jìn)程，可以讓互相之間不會影響，一個進(jìn)程退出后，其它進(jìn)程還在工作，服務(wù)不會中斷，master進(jìn)程則很快啟動新的worker進(jìn)程。當(dāng)然，worker進(jìn)程的異常退出，肯定是程序有bug了，異常退出，會導(dǎo)致當(dāng)前worker上的所有請求失敗，不過不會影響到所有請求，所以降低了風(fēng)險。當(dāng)然，好處還有很多，大家可以慢慢體會。
上面講了很多關(guān)于nginx的進(jìn)程模型，接下來，我們來看看nginx是如何處理事件的。
有人可能要問了，nginx采用多worker的方式來處理請求，每個worker里面只有一個主線程，那能夠處理的并發(fā)數(shù)很有限啊，多少個worker就能處理多少個并發(fā)，何來高并發(fā)呢？非也，這就是nginx的高明之處，nginx采用了異步非阻塞的方式來處理請求，也就是說，nginx是可以同時處理成千上萬個請求的。
想想apache的常用工作方式（apache也有異步非阻塞版本，但因其與自帶某些模塊沖突，所以不常用），每個請求會獨占一個工作線程，當(dāng)并發(fā)數(shù)上到幾千時，就同時有幾千的線程在處理請求了。這對操作系統(tǒng)來說，是個不小的挑戰(zhàn)，線程帶來的內(nèi)存占用非常大，線程的上下文切換帶來的cpu開銷很大，自然性能就上不去了，而這些開銷完全是沒有意義的。
同步阻塞 VS 異步非阻塞
為什么nginx可以采用異步非阻塞的方式來處理呢，或者異步非阻塞到底是怎么回事呢？我們先回到原點，看看一個請求的完整過程。首先，請求過來，要建立連接，然后再接收數(shù)據(jù)，接收數(shù)據(jù)后，再發(fā)送數(shù)據(jù)。具體到系統(tǒng)底層，就是讀寫事件，而當(dāng)讀寫事件沒有準(zhǔn)備好時，必然不可操作，如果不用非阻塞的方式來調(diào)用，那就得阻塞調(diào)用了，事件沒有準(zhǔn)備好，那就只能等了，等事件準(zhǔn)備好了，你再繼續(xù)吧。阻塞調(diào)用會進(jìn)入內(nèi)核等待，cpu就會讓出去給別人用了，對單線程的worker來說，顯然不合適，當(dāng)網(wǎng)絡(luò)事件越多時，大家都在等待呢，cpu空閑下來沒人用，cpu利用率自然上不去了，更別談高并發(fā)了。
好吧，你說加進(jìn)程數(shù)，這跟apache的線程模型有什么區(qū)別，注意，別增加無謂的上下文切換。所以，在nginx里面，最忌諱阻塞的系統(tǒng)調(diào)用了。不要阻塞，那就非阻塞嘍。非阻塞就是，事件沒有準(zhǔn)備好，馬上返回EAGAIN，告訴你，事件還沒準(zhǔn)備好呢，你慌什么，過會再來吧。好吧，你過一會，再來檢查一下事件，直到事件準(zhǔn)備好了為止，在這期間，你就可以先去做其它事情，然后再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態(tài)，你可以做更多的事情了，但帶來的開銷也是不小的。所以，才會有了異步非阻塞的事件處理機(jī)制，具體到系統(tǒng)調(diào)用就是像select/poll/epoll/kqueue這樣的系統(tǒng)調(diào)用。
它們提供了一種機(jī)制，讓你可以同時監(jiān)控多個事件，調(diào)用他們是阻塞的，但可以設(shè)置超時時間，在超時時間之內(nèi)，如果有事件準(zhǔn)備好了，就返回。這種機(jī)制正好解決了我們上面的兩個問題，拿epoll為例(在后面的例子中，我們多以epoll為例子，以代表這一類函數(shù))，當(dāng)事件沒準(zhǔn)備好時，放到epoll里面，事件準(zhǔn)備好了，我們就去讀寫，當(dāng)讀寫返回EAGAIN時，我們將它再次加入到epoll里面。這樣，只要有事件準(zhǔn)備好了，我們就去處理它，只有當(dāng)所有事件都沒準(zhǔn)備好時，才在epoll里面等著。這樣，我們就可以并發(fā)處理大量的并發(fā)了，當(dāng)然，這里的并發(fā)請求，是指未處理完的請求，線程只有一個，所以同時能處理的請求當(dāng)然只有一個了，只是在請求間進(jìn)行不斷地切換而已，切換也是因為異步事件未準(zhǔn)備好，而主動讓出的。這里的切換是沒有任何代價，你可以理解為循環(huán)處理多個準(zhǔn)備好的事件，事實上就是這樣的。
與多線程相比，這種事件處理方式是有很大的優(yōu)勢的，不需要創(chuàng)建線程，每個請求占用的內(nèi)存也很少，沒有上下文切換，事件處理非常的輕量級。并發(fā)數(shù)再多也不會導(dǎo)致無謂的資源浪費(fèi)（上下文切換）。更多的并發(fā)數(shù)，只是會占用更多的內(nèi)存而已。 我之前有對連接數(shù)進(jìn)行過測試，在24G內(nèi)存的機(jī)器上，處理的并發(fā)請求數(shù)達(dá)到過200萬。現(xiàn)在的網(wǎng)絡(luò)服務(wù)器基本都采用這種方式，這也是nginx性能高效的主要原因。
我們之前說過，推薦設(shè)置worker的個數(shù)為cpu的核數(shù)，在這里就很容易理解了，更多的worker數(shù)，只會導(dǎo)致進(jìn)程來競爭cpu資源了，從而帶來不必要的上下文切換。
而且，nginx為了更好的利用多核特性，提供了cpu親緣性的綁定選項，我們可以將某一個進(jìn)程綁定在某一個核上，這樣就不會因為進(jìn)程的切換帶來cache的失效。像這種小的優(yōu)化在nginx中非常常見，同時也說明了nginx作者的苦心孤詣。比如，nginx在做4個字節(jié)的字符串比較時，會將4個字符轉(zhuǎn)換成一個int型，再作比較，以減少cpu的指令數(shù)等等。
現(xiàn)在，知道了nginx為什么會選擇這樣的進(jìn)程模型與事件模型了。對于一個基本的web服務(wù)器來說，事件通常有三種類型，網(wǎng)絡(luò)事件、信號、定時器。從上面的講解中知道，網(wǎng)絡(luò)事件通過異步非阻塞可以很好的解決掉。如何處理信號與定時器？
首先，信號的處理。
對nginx來說，有一些特定的信號，代表著特定的意義。信號會中斷掉程序當(dāng)前的運(yùn)行，在改變狀態(tài)后，繼續(xù)執(zhí)行。如果是系統(tǒng)調(diào)用，則可能會導(dǎo)致系統(tǒng)調(diào)用的失敗，需要重入。關(guān)于信號的處理，大家可以學(xué)習(xí)一些專業(yè)書籍，這里不多說。對于nginx來說，如果nginx正在等待事件（epoll_wait時），如果程序收到信號，在信號處理函數(shù)處理完后，epoll_wait會返回錯誤，然后程序可再次進(jìn)入epoll_wait調(diào)用。
另外，再來看看定時器。由于epoll_wait等函數(shù)在調(diào)用的時候是可以設(shè)置一個超時時間的，所以nginx借助這個超時時間來實現(xiàn)定時器。nginx里面的定時器事件是放在一顆維護(hù)定時器的紅黑樹里面，每次在進(jìn)入epoll_wait前，先從該紅黑樹里面拿到所有定時器事件的最小時間，在計算出epoll_wait的超時時間后進(jìn)入epoll_wait。
所以，當(dāng)沒有事件產(chǎn)生，也沒有中斷信號時，epoll_wait會超時，也就是說，定時器事件到了。這時，nginx會檢查所有的超時事件，將他們的狀態(tài)設(shè)置為超時，然后再去處理網(wǎng)絡(luò)事件。由此可以看出，當(dāng)我們寫nginx代碼時，在處理網(wǎng)絡(luò)事件的回調(diào)函數(shù)時，通常做的第一個事情就是判斷超時，然后再去處理網(wǎng)絡(luò)事件。
更多Nginx相關(guān)知識，訪問Nginx使用教程欄目！?
.png)
