為什么nginx性能如此出色?

聲明：本文的內(nèi)容源于http://tengine.taobao.org/相干資料，如果想深入了解，可以到該網(wǎng)站查看。

    nginx的高性能在業(yè)界已是眾人皆知了，性能究竟有多高?官方測試Nginx能夠支持5萬并發(fā)連接，在實際生產(chǎn)環(huán)境中可支持2~4萬并發(fā)的連接數(shù)是沒有啥問題的。根據(jù)實戰(zhàn)Nginx書中描寫，同等硬件環(huán)境下，Nginx的處理能力相當于Apache的5~10倍。而這么高的性能，與其架構是分不開的。

    nginx在啟動后，在unix系統(tǒng)中會以daemon的方式在后臺運行，后臺進程包括1個master進程和多個worker進程。master進程主要用來管理worker進程，包括：接收來自外界的信號、向各worker進程發(fā)送信號和監(jiān)控worker進程的運行狀態(tài)等。當worker進程退出后(異常情況下)，會自動重新啟動新的worker進程。而基本的網(wǎng)絡事件，則是放在worker進程中來處理了。多個worker進程之間是對等的，他們同等競爭來自客戶真?zhèn)€要求，各進程相互之間是獨立的。1個要求，只可能在1個worker進程中處理，1個worker進程，不可能處理其它進程的要求。worker進程的個數(shù)是可以設置的，1般我們會設置與機器cpu核數(shù)1致，這里面的緣由與nginx的進程模型和事件處理模型是分不開的。

    nginx的進程模型，可以由下圖來表示：

    從上圖中我們可以看到，master來管理worker進程，所以我們只需要與master進程通訊就好了。master進程會接收來自外界發(fā)來的信號，再根據(jù)信號做不同的事情。所以我們要控制nginx，只需要通過kill向master進程發(fā)送信號就好了。

    那末，worker進行又是如何處理要求的呢？前面有提到，worker進程之間是同等的，每一個進程，處理要求的機會也是1樣的。首先，每一個worker進程都是從master進程fork過來，在master進程里面，先建立好需要listen的socket（listenfd）以后，然后再fork出多個worker進程。所有worker進程的listenfd會在新連接到來時變得可讀，為保證只有1個進程處理該連接，所有worker進程在注冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進程注冊listenfd讀事件，在讀事件里調(diào)用accept接受該連接。當1個worker進程在accept這個連接以后，就開始讀取要求，解析要求，處理要求，產(chǎn)生數(shù)據(jù)后，再返回給客戶端，最后才斷開連接，這樣1個完全的要求就是這樣的了。我們可以看到，1個要求，完全由worker進程來處理，而且只在1個worker進程中處理。

    nginx采取這類進程模型有甚么好處呢？固然，好處肯定會很多了。首先，對每一個worker進程來講，獨立的進程，不需要加鎖，所以省掉了鎖帶來的開消，同時在編程和問題查找時，也會方便很多。其次，采取獨立的進程，可讓相互之間不會影響，1個進程退出后，其它進程還在工作，服務不會中斷，master進程則很快啟動新的worker進程。固然，worker進程的異常退出，肯定是程序有bug了，異常退出，會致使當前worker上的所有要求失敗，不過不會影響到所有要求，所以下降了風險。固然，好處還有很多，大家可以漸漸體會。

    到這里，有人可能要問了，nginx采取多worker的方式來處理要求，每一個worker里面只有1個主線程，那能夠處理的并發(fā)數(shù)很有限啊，多少個worker就可以處理多少個并發(fā)，何來高并發(fā)呢？非也，這就是nginx的高明的地方，nginx采取了異步非阻塞的方式來處理要求，也就是說，nginx是可以同時處理不計其數(shù)個要求的。想一想apache的經(jīng)常使用工作方式（apache也有異步非阻塞版本，但因其與自帶某些模塊沖突，所以不經(jīng)常使用），每一個要求會獨占1個工作線程，當并發(fā)數(shù)上到幾千時，就同時有幾千的線程在處理要求了。這對操作系統(tǒng)來講，是個不小的挑戰(zhàn)，線程帶來的內(nèi)存占用非常大，線程的上下文切換帶來的cpu開消很大，自然性能就上不去了，而這些開消完全是沒成心義的。

    作甚異步非阻塞？我們先回到原點，看看1個要求的完全進程。首先，要求過來，要建立連接，然后再接收數(shù)據(jù)，接收數(shù)據(jù)后，再發(fā)送數(shù)據(jù)。具體到系統(tǒng)底層，就是讀寫事件，而當讀寫事件沒有準備好時，必定不可操作，如果不用非阻塞的方式來調(diào)用，那就得阻塞調(diào)用了，事件沒有準備好，那就只能等了，等事件準備好了，你再繼續(xù)吧。阻塞調(diào)用會進入內(nèi)核等待，cpu就會讓出去給他人用了，對單線程的worker來講，明顯不適合，當網(wǎng)絡事件越多時，大家都在等待呢，cpu空閑下來沒人用，cpu利用率自然上不去了，更別談高并發(fā)了。好吧，你說加進程數(shù)，這跟apache的線程模型有甚么區(qū)分？注意，別增加無謂的上下文切換。所以，在nginx里面，最忌諱阻塞的系統(tǒng)調(diào)用了。不要阻塞，那就非阻塞嘍。非阻塞就是，事件沒有準備好，馬上返回EAGAIN，告知你，事件還沒準備好呢，你慌甚么，過會再來吧。好吧，你過1會，再來檢查1下事件，直到事件準備好了為止，在這期間，你就能夠先去做其它事情，然后再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查1下事件的狀態(tài)，你可以做更多的事情了，但帶來的開消也是不小的。所以，才會有了異步非阻塞的事件處理機制，具體到系統(tǒng)調(diào)用就是像select/poll/epoll/kqueue這樣的系統(tǒng)調(diào)用。它們提供了1種機制，讓你可以同時監(jiān)控多個事件，調(diào)用他們是阻塞的，但可以設置超時時間，在超時時間以內(nèi)，如果有事件準備好了，就返回。這類機制正好解決了我們上面的兩個問題，拿epoll為例(在后面的例子中，我們多以epoll為例子，以代表這1類函數(shù))，當事件沒準備好時，放到epoll里面，事件準備好了，我們就去讀寫，當讀寫返回EAGAIN時，我們將它再次加入到epoll里面。這樣，只要有事件準備好了，我們就去處理它，只有當所有事件都沒準備好時，才在epoll里面等著。這樣，我們就能夠并發(fā)處理大量的并發(fā)了，固然，這里的并發(fā)要求，是指未處理完的要求，線程只有1個，所以同時能處理的要求固然只有1個了，只是在要求間進行不斷地切換而已，切換也是由于異步事件未準備好，而主動讓出的。這里的切換是沒有任何代價，你可以理解為循環(huán)處理多個準備好的事件，事實上就是這樣的。與多線程相比，這類事件處理方式是有很大的優(yōu)勢的，不需要創(chuàng)建線程，每一個要求占用的內(nèi)存也很少，沒有上下文切換，事件處理非常的輕量級。并發(fā)數(shù)再多也不會致使無謂的資源浪費（上下文切換）。更多的并發(fā)數(shù)，只是會占用更多的內(nèi)存而已。 

    現(xiàn)在的網(wǎng)絡服務器基本都采取這類方式，這也是nginx性能高效的主要緣由。

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學習有所幫助,可以手機掃描二維碼進行捐贈