Nginx進程模型分析
在介紹Nginx的進程模型以前咱們先來給你們解釋下一些常見的名詞，這能輔助咱們更好的瞭解Nginx的進程模型。做爲Web服務器，設計的初衷就是爲了可以處理更多的客戶端的請求，通常來講，完成並行處理請求工做有三種方式能夠選擇，多進程、多線程、異步方式。nginx
多進程方式
服務器每接收到一個客戶端請求，就會由主進程生成一個子進程出來和該請求創建鏈接進行交互，直到鏈接斷開之後子進程也就結束了
優勢在於各個子進程之間相互獨立，各個客戶端請求之間相互不受干擾。
缺點是生成一個子進程須要進行內存複製、在資源和時間上會產生必定的額外開銷。若是請求比較多的時候，會對系統資源形成必定的壓力web
多線程方式
多線程方式和多進程方式很類似，服務器每接收到一個客戶端請求時，會產生一個線程與該客戶端進行交互。而產生一個線程的開銷比進程小不少，因此多線程的方式在必定程度上減輕了web服務器對系統資源的要求。
缺點是多線程之間存在內存共享、彼此間存在相互影響的狀況json
異步方式
異步方式和前面說的兩種方式徹底不同，關於異步這塊，還有幾個概念同步、異步； 阻塞、非阻塞，在這裏一塊兒作一個講解
關於同步和異步，咱們很好理解。同步機制是指發送方發送請求後，須要等待接收方返回響應後，才能發送下一個請求，而異步機制，發送方發送請求後，不等待接收方響應這個請求，就繼續發送下個請求。服務器
阻塞和非阻塞，主要指socket讀寫數據的阻塞和非阻塞方式。Socket的本質其實也是IO操做。每個TCP Socket的內核中都有一個發送緩衝區和接收緩衝區。對與阻塞模式來講，若是接收緩衝區爲空，那麼socket的read方法的線程就會阻塞，直到有數據進入接收緩衝區。而對於寫數據到socket中而言，若是待發送的數據長度大於發送緩衝區的空餘長度，那麼write方法會進入阻塞。
網絡
乍一看這四個概念的解釋會瞬間感到頭大，也常常講同步異步等同於阻塞非阻塞，其實，區分他們很是簡單。多線程
同步異步與阻塞非阻塞的主要區別是針對對象不一樣。異步
同步異步是針對調用者來講的，調用者發起一個請求後，一直乾等被調用者的反饋就是同步，沒必要等去作別的事就是異步。socket
阻塞非阻塞是針對被調用者來講的，被調用者收到一個請求後，作完請求任務後纔給出反饋就是阻塞，收到請求直接給出反饋再去作任務就是非阻塞。線程
而對於非阻塞模式來講，經過事件觸發的方式來達到目的。咱們能夠認爲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就控制了多進程間鏈接的平衡了。
好了~本文先介紹到這裏，有問題的歡迎留言交流 ~