??前面介紹了很多Nginx實(shí)戰(zhàn)方面的內(nèi)容，本文我們來介紹下Nginx的原理。

Nginx進(jìn)程模型分析

??在介紹Nginx的進(jìn)程模型之前我們先來給大家解釋下一些常見的名詞，這能輔助我們更好的了解Nginx的進(jìn)程模型。作為Web服務(wù)器，設(shè)計(jì)的初衷就是為了能夠處理更多的客戶端的請求，一般來說，完成并行處理請求工作有三種方式可以選擇，多進(jìn)程、多線程、異步方式。

多進(jìn)程方式

??服務(wù)器每接收到一個(gè)客戶端請求，就會由主進(jìn)程生成一個(gè)子進(jìn)程出來和該請求建立連接進(jìn)行交互，直到連接斷開以后子進(jìn)程也就結(jié)束了
??優(yōu)點(diǎn)在于各個(gè)子進(jìn)程之間相互獨(dú)立，各個(gè)客戶端請求之間相互不受干擾。
??缺點(diǎn)是生成一個(gè)子進(jìn)程需要進(jìn)行內(nèi)存復(fù)制、在資源和時(shí)間上會產(chǎn)生一定的額外開銷。如果請求比較多的時(shí)候，會對系統(tǒng)資源造成一定的壓力

多線程方式

??多線程方式和多進(jìn)程方式很相似，服務(wù)器每接收到一個(gè)客戶端請求時(shí)，會產(chǎn)生一個(gè)線程與該客戶端進(jìn)行交互。而產(chǎn)生一個(gè)線程的開銷比進(jìn)程小很多，所以多線程的方式在一定程度上減輕了web服務(wù)器對系統(tǒng)資源的要求。
缺點(diǎn)是多線程之間存在內(nèi)存共享、彼此間存在相互影響的情況

異步方式

??異步方式和前面說的兩種方式完全不一樣，關(guān)于異步這塊，還有幾個(gè)概念同步、異步； 阻塞、非阻塞，在這里一起做一個(gè)講解
??關(guān)于同步和異步，我們很好理解。同步機(jī)制是指發(fā)送方發(fā)送請求后，需要等待接收方返回響應(yīng)后，才能發(fā)送下一個(gè)請求，而異步機(jī)制，發(fā)送方發(fā)送請求后，不等待接收方響應(yīng)這個(gè)請求，就繼續(xù)發(fā)送下個(gè)請求。

??阻塞和非阻塞，主要指socket讀寫數(shù)據(jù)的阻塞和非阻塞方式。Socket的本質(zhì)其實(shí)也是IO操作。每一個(gè)TCP Socket的內(nèi)核中都有一個(gè)發(fā)送緩沖區(qū)和接收緩沖區(qū)。對與阻塞模式來說，如果接收緩沖區(qū)為空，那么socket的read方法的線程就會阻塞，直到有數(shù)據(jù)進(jìn)入接收緩沖區(qū)。而對于寫數(shù)據(jù)到socket中而言，如果待發(fā)送的數(shù)據(jù)長度大于發(fā)送緩沖區(qū)的空余長度，那么write方法會進(jìn)入阻塞。

??乍一看這四個(gè)概念的解釋會瞬間感到頭大，也經(jīng)常講同步異步等同于阻塞非阻塞，其實(shí)，區(qū)分他們非常簡單。

同步異步與阻塞非阻塞的主要區(qū)別是針對對象不同。

??同步異步是針對調(diào)用者來說的，調(diào)用者發(fā)起一個(gè)請求后，一直干等被調(diào)用者的反饋就是同步，不必等去做別的事就是異步。

??阻塞非阻塞是針對被調(diào)用者來說的，被調(diào)用者收到一個(gè)請求后，做完請求任務(wù)后才給出反饋就是阻塞，收到請求直接給出反饋再去做任務(wù)就是非阻塞。

??而對于非阻塞模式來說，通過事件觸發(fā)的方式來達(dá)到目的。我們可以認(rèn)為NIO底層中存在一個(gè)I/O調(diào)度線程，它不斷的掃描每個(gè)Socket的緩沖區(qū)，當(dāng)發(fā)現(xiàn)寫入緩沖區(qū)為空的時(shí)候，它會產(chǎn)生一個(gè)Socket可寫事件，此時(shí)程序就可以把數(shù)據(jù)寫入到Socket中。如果一次寫不完，就等待下一次的可寫事件通知；反之，當(dāng)發(fā)現(xiàn)緩沖區(qū)里有數(shù)據(jù)的時(shí)候，它會產(chǎn)生一個(gè)Socket可讀事件，程序收到這個(gè)通知事件就可以從Socket讀取數(shù)據(jù)了。
??那么基于這些概念又引除了四個(gè)概念： 同步阻塞、同步非阻塞、異步阻塞、異步非阻塞

同步阻塞：發(fā)送方向接收方發(fā)送請求后，一直等待接收方響應(yīng)；接收方在處理請求時(shí)進(jìn)行的IO操作如果不能馬上得到結(jié)果，就一直等待結(jié)果返回才響應(yīng)發(fā)送方。期間一直處于阻塞狀態(tài)；

同步非阻塞：發(fā)送方向接收方發(fā)送請求后，一直等待響應(yīng)，接收方在進(jìn)行IO操作的時(shí)候，可以不需要等待直接去做其他事，而因?yàn)檫€沒有獲得結(jié)果，發(fā)送方仍然處于等待狀態(tài)。接收方獲得io的操作完成后，把結(jié)果響應(yīng)給發(fā)送方，接收方才進(jìn)入下一次請求過程

異步阻塞：發(fā)送方向接收方發(fā)送請求后，不用等待響應(yīng)，可以接著進(jìn)行其他操作。接收方處理請求時(shí)進(jìn)行的IO操作如果不能立刻獲得結(jié)果，就一直等待返回結(jié)果后向發(fā)送方響應(yīng)

異步非阻塞：發(fā)送方發(fā)送請求后，不用等待響應(yīng)，可以繼續(xù)做其他事情。接收方處理請求時(shí)進(jìn)行的IO操作如果不能馬上得到結(jié)果，也不等待，而是去做其他事情。當(dāng)io操作完成后，把結(jié)果通知給接收方，接收方再響應(yīng)給發(fā)送方

Nginx服務(wù)器的請求處理過程

??Nginx結(jié)合了多進(jìn)程機(jī)制和異步機(jī)制對外提供服務(wù)
??Nginx服務(wù)啟動后，會產(chǎn)生一個(gè)主進(jìn)程和多個(gè)工作進(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)程中來處理了。多個(gè)worker進(jìn)程之間是對等的，他們同等競爭來自客戶端的請求，各進(jìn)程互相之間是獨(dú)立的。一個(gè)請求，只可能在一個(gè)worker進(jìn)程中處理，一個(gè)worker進(jìn)程，不可能處理其它進(jìn)程的求，worker進(jìn)程的個(gè)數(shù)是可以設(shè)置的，一般我們會設(shè)置與機(jī)器cpu核數(shù)一致

Master進(jìn)程的作用是？
讀取并驗(yàn)證配置文件nginx.conf；管理worker進(jìn)程；
Worker進(jìn)程的作用是？
每一個(gè)Worker進(jìn)程都維護(hù)一個(gè)線程（避免線程切換），處理連接和請求；注意Worker進(jìn)程的個(gè)數(shù)由配置文件決定，一般和CPU個(gè)數(shù)相關(guān)（有利于進(jìn)程切換），配置幾個(gè)就有幾個(gè)Worker進(jìn)程。

熱部署

master來管理worker進(jìn)程，所以我們只需要與master進(jìn)程通信就行了。master進(jìn)程會接收來自外界發(fā)來的信號，再根據(jù)信號做不同的事情,比如我們前面常用的

./sbin/nginx -c conf/nginx.conf -s reload

執(zhí)行這個(gè)命令時(shí)，master收到這個(gè)信號以后先啟動一個(gè)新的Nginx進(jìn)程，而新的Nginx進(jìn)程在解析到reload參數(shù)后，就知道是要控制Nginx來重新加載配置文件，它會向master進(jìn)程發(fā)送信號，然后master會重新加載配置文件，在啟動新的worker進(jìn)程，并向所有老的worker進(jìn)程發(fā)送信號，告訴他們可以退休了，新的worker啟動之后就可以以新的配置文件接收新的請求了 – 熱部署的原理

worker進(jìn)程是如何處理請求？

??我們基本上知道了在操作nginx時(shí)，nginx內(nèi)部所做的事情，那么worker進(jìn)程是如何處理請求的呢？ 在Nginx中，所有的worker進(jìn)程都是平等的，每個(gè)進(jìn)程處理每個(gè)請求的機(jī)會是一樣的。當(dāng)我們提供80端口的http服務(wù)時(shí)，一個(gè)連接請求過來，每個(gè)進(jìn)程都可能處理這個(gè)連接。
??worker進(jìn)程是從master進(jìn)程fork過來的，而在master進(jìn)程中，會先建立好需要listen的socket，然后fork出多個(gè)worker進(jìn)程，當(dāng)有新連接請求過來時(shí)work進(jìn)程可以去處理，為了避免驚群效應(yīng)，worker進(jìn)程在處理請求之前先要去搶占accept_mutex，也就是互斥鎖，當(dāng)獲得鎖成功以后，就可以去解析處理這個(gè)請求。請求處理完以后再返回給客戶端。

??進(jìn)程模型的處理方式帶來的一些好處就是：進(jìn)程之間是獨(dú)立的，也就是一個(gè)worker進(jìn)程出現(xiàn)異常退出，其他worker進(jìn)程是不會受到影響的；此外，獨(dú)立進(jìn)程也會避免一些不需要的鎖操作，這樣子會提高處理效率，并且開發(fā)調(diào)試也更容易。

??worker進(jìn)程會競爭監(jiān)聽客戶端的連接請求：這種方式可能會帶來一個(gè)問題，就是可能所有的請求都被一個(gè)worker進(jìn)程給競爭獲取了，導(dǎo)致其他進(jìn)程都比較空閑，而某一個(gè)進(jìn)程會處于忙碌的狀態(tài)，這種狀態(tài)可能還會導(dǎo)致無法及時(shí)響應(yīng)連接而丟棄discard掉本有能力處理的請求。這種不公平的現(xiàn)象，是需要避免的，尤其是在高可靠web服務(wù)器環(huán)境下。

??針對這種現(xiàn)象，Nginx采用了一個(gè)是否打開accept_mutex選項(xiàng)的值，ngx_accept_disabled標(biāo)識控制一個(gè)worker進(jìn)程是否需要去競爭獲取accept_mutex選項(xiàng)，進(jìn)而獲取accept事件

ngx_accept_disabled值：nginx單進(jìn)程的所有連接總數(shù)的八分之一，減去剩下的空閑連接數(shù)量，得到的這個(gè)ngx_accept_disabled。
當(dāng)ngx_accept_disabled大于0時(shí)，不會去嘗試獲取accept_mutex鎖，并且將ngx_accept_disabled減1，于是，每次執(zhí)行到此處時(shí)，都會去減1，直到小于0。不去獲取accept_mutex鎖，就是等于讓出獲取連接的機(jī)會，很顯然可以看出，當(dāng)空閑連接越少時(shí)，ngx_accept_disable越大，于是讓出的機(jī)會就越多，這樣其它進(jìn)程獲取鎖的機(jī)會也就越大。不去accept，自己的連接就控制下來了，其它進(jìn)程的連接池就會得到利用，這樣，nginx就控制了多進(jìn)程間連接的平衡了。

好了~本文先介紹到這里，有問題的歡迎留言交流

總結(jié)

以上是生活随笔為你收集整理的Nginx-详解其原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。