??前面介紹了很多Nginx實戰方面的內容，本文我們來介紹下Nginx的原理。

Nginx進程模型分析

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

多進程方式

??服務器每接收到一個客戶端請求，就會由主進程生成一個子進程出來和該請求建立連接進行交互，直到連接斷開以后子進程也就結束了
??優點在于各個子進程之間相互獨立，各個客戶端請求之間相互不受干擾。
??缺點是生成一個子進程需要進行內存復制、在資源和時間上會產生一定的額外開銷。如果請求比較多的時候，會對系統資源造成一定的壓力

多線程方式

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

異步方式

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

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

??乍一看這四個概念的解釋會瞬間感到頭大，也經常講同步異步等同于阻塞非阻塞，其實，區分他們非常簡單。

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

??同步異步是針對調用者來說的，調用者發起一個請求后，一直干等被調用者的反饋就是同步，不必等去做別的事就是異步。

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

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

同步阻塞：發送方向接收方發送請求后，一直等待接收方響應；接收方在處理請求時進行的IO操作如果不能馬上得到結果，就一直等待結果返回才響應發送方。期間一直處于阻塞狀態；

同步非阻塞：發送方向接收方發送請求后，一直等待響應，接收方在進行IO操作的時候，可以不需要等待直接去做其他事，而因為還沒有獲得結果，發送方仍然處于等待狀態。接收方獲得io的操作完成后，把結果響應給發送方，接收方才進入下一次請求過程

異步阻塞：發送方向接收方發送請求后，不用等待響應，可以接著進行其他操作。接收方處理請求時進行的IO操作如果不能立刻獲得結果，就一直等待返回結果后向發送方響應

異步非阻塞：發送方發送請求后，不用等待響應，可以繼續做其他事情。接收方處理請求時進行的IO操作如果不能馬上得到結果，也不等待，而是去做其他事情。當io操作完成后，把結果通知給接收方，接收方再響應給發送方

Nginx服務器的請求處理過程

??Nginx結合了多進程機制和異步機制對外提供服務
??Nginx服務啟動后，會產生一個主進程和多個工作進程。

??master進程主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控worker進程的運行狀態，當worker進程退出后(異常情況下)，會自動重新啟動新的worker進程
??而基本的網絡事件，則是放在worker進程中來處理了。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的求，worker進程的個數是可以設置的，一般我們會設置與機器cpu核數一致

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

熱部署

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

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

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

worker進程是如何處理請求？

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

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

??worker進程會競爭監聽客戶端的連接請求：這種方式可能會帶來一個問題，就是可能所有的請求都被一個worker進程給競爭獲取了，導致其他進程都比較空閑，而某一個進程會處于忙碌的狀態，這種狀態可能還會導致無法及時響應連接而丟棄discard掉本有能力處理的請求。這種不公平的現象，是需要避免的，尤其是在高可靠web服務器環境下。

??針對這種現象，Nginx采用了一個是否打開accept_mutex選項的值，ngx_accept_disabled標識控制一個worker進程是否需要去競爭獲取accept_mutex選項，進而獲取accept事件

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。