Nginx工作原理（Master Worker）

1. nginx

首先要明白，nginx 採用的是多程序（單執行緒） & 多路io復用模型。使用了 i/o 多路復用技術的 nginx，就成了」併發事件驅動「的伺服器。

2. 多程序的工作模式

3.注意:

worker 程序數，一般會設定成機器 cpu 核數。因為更多的worker 數，只會導致程序相互競爭 cpu，從而帶來不必要的上下文切換。

使用多程序模式，不僅能提高併發率，而且程序之間相互獨立，乙個 worker 程序掛了不會影響到其他 worker 程序。

4.驚群現象

5.nginx對驚群現象的處理：

nginx 提供了乙個 accept_mutex 這個東西，這是乙個加在accept上的一把互斥鎖。即每個 worker 程序在執行 accept 之前都需要先獲取鎖，獲取不到就放棄執行 accept()。有了這把鎖之後，同一時刻，就只會有乙個程序去 accpet()，這樣就不會有驚群問題了。accept_mutex 是乙個可控選項，我們可以顯示地關掉，預設是開啟的。

6.worker程序工作流程

當乙個 worker 程序在 accept() 這個連線之後，就開始讀取請求，解析請求，處理請求，產生資料後，再返回給客戶端，最後才斷開連線，乙個完整的請求。乙個請求，完全由 worker 程序來處理，而且只能在乙個 worker 程序中處理。

這樣做帶來的好處：

7.多程序模型每個程序/執行緒只能處理一路io，那麼 nginx是如何處理多路io呢？

如果不使用 io 多路復用，那麼在乙個程序中，同時只能處理乙個請求，比如執行 accept()，如果沒有連線過來，那麼程式會阻塞在這裡，直到有乙個連線過來，才能繼續向下執行。

而多路復用，允許我們只在事件發生時才將控制返回給程式，而其他時候核心都掛起程序，隨時待命。

核心：nginx採用的 io多路復用模型epoll

epoll通過在linux核心中申請乙個簡易的檔案系統（檔案系統一般用什麼資料結構實現？b+樹），其工作流程分為三部分：

這樣，註冊好事件之後，只要有 fd 上事件發生，epoll_wait() 就能檢測到並返回給使用者，使用者就能」非阻塞「地進行 i/o 了。

epoll() 中核心則維護乙個鍊錶，epoll_wait 直接檢查鍊錶是不是空就知道是否有檔案描述符準備好了。（epoll 與 select 相比最大的優點是不會隨著 sockfd 數目增長而降低效率，使用 select() 時，核心採用輪訓的方法來檢視是否有fd 準備好，其中的儲存 sockfd 的是類似陣列的資料結構 fd_set，key 為 fd，value 為 0 或者 1。）

能達到這種效果，是因為在核心實現中 epoll 是根據每個 sockfd 上面的與裝置驅動程式建立起來的**函式實現的。那麼，某個 sockfd 上的事件發生時，與它對應的**函式就會被呼叫，來把這個 sockfd 加入鍊錶，其他處於「空閒的」狀態的則不會。在這點上，epoll 實現了乙個」偽」aio。但是如果絕大部分的 i/o 都是「活躍的」，每個 socket 使用率很高的話，epoll效率不一定比 select 高（可能是要維護佇列複雜）。

可以看出，因為乙個程序裡只有乙個執行緒，所以乙個程序同時只能做一件事，但是可以通過不斷地切換來「同時」處理多個請求。

8.例子：

nginx 會註冊乙個事件：「如果來自乙個新客戶端的連線請求到來了，再通知我」，此後只有連線請求到來，伺服器才會執行 accept() 來接收請求。又比如向上游伺服器（比如 php-fpm）**請求，並等待請求返回時，這個處理的 worker 不會在這阻塞，它會在傳送完請求後，註冊乙個事件：「如果緩衝區接收到資料了，告訴我一聲，我再將它讀進來」，於是程序就空閒下來等待事件發生。

這樣，基於多程序+epoll， nginx 便能實現高併發。

使用 epoll 處理事件的乙個框架，****：

for( ; ; )  //
無限迴圈
else
if( events[i].events&epollin ) //
接收到資料，讀socket
else
if(events[i].events&epollout) //
有資料待傳送，寫socket
else}}

9.nginx 與多程序模式 apache 的比較：事件驅動適合於i/o密集型服務，多程序或執行緒適合於cpu密集型服務：