Nginx 是一個輕量級的HTTP 服務(wù)程序，相比其他服務(wù)器程序如Apache，Nginx占用內(nèi)存少，穩(wěn)定性高，并發(fā)處理能力強。同時Nginx 還是一個反向代理服務(wù)程序，和郵件代理服務(wù)程序。Nginx具有豐富的模塊庫、靈活的配置、較低資源消耗等優(yōu)點。下面，我們一起深入看一下Nginx的工作機制

1. Nginx 如何實現(xiàn)高性能低消耗的呢？

我們從以下幾個方面說明以下：

網(wǎng)絡(luò)事件處理機制

• Nginx 采用異步非阻塞的方式處理請求，可以同時處理上萬的請求
• Nginx 支持 select/epoll 等流行事件處理機制，根據(jù)系統(tǒng)環(huán)境自動選擇
• Nginx 采用獨立于系統(tǒng)的事件處理機制，能夠高效處理請求

資源分配技術(shù)

• Nginx 采用分階段資源分配技術(shù)，使得它的CPU和內(nèi)存消耗非常低

多核處理優(yōu)化

• Nginx 默認(rèn)采用多進程啟動模式
• Nginx 包含Master 進程 和 Worker 進程
• 能夠充分利用 SMP 對稱多處理的優(yōu)勢，減少Worker進程磁盤I/O的阻塞
• Nginx 支持Worker進程和CPU內(nèi)核 一一對應(yīng)綁定，避免進程上下文的切換致使cache失效

基于上面提到技術(shù)，以及Nginx很多地方的優(yōu)化，讓Nginx成為最快的HTTP服務(wù)器。

2.Nginx的進程模型

在Nginx的技術(shù)架構(gòu)中，進程模型是至關(guān)重要的一部分。接下來，我們一起看看Nginx進程模型，以及它們的工作機制。

Linux 系統(tǒng)中，Nginx默認(rèn)以守護進程daemon方式啟動，默認(rèn)采用多進程方式。Nginx包括兩種類型的進程：

• Master 進程，數(shù)量只有一個，管理Nginx本身和Worker進程
• Worker 進程，數(shù)量一般和CPU核數(shù)相等，Nginx的所有請求處理，均是在Worker進程中完成

下面，我們分別深入看一下Master和Worker進程。

2.1 Master 進程工作機制

在Nginx啟動時，Master進程創(chuàng)建，主要負(fù)責(zé)初始化Nginx和相關(guān)模塊、fork Worker進程、接收處理外界信號等工作。

Nginx的初始化過程：

• 解析配置文件，這是Nginx初始化最重要的一個環(huán)節(jié)
• 調(diào)用各個配置指令回調(diào)函數(shù)，完成各個模塊的配置、相互關(guān)聯(lián)等
• 建立listen 的 socket(listenfd)
• 準(zhǔn)備工作都完成后，fork worker子進程和cache子進程

Master 進程信號處理機制

我們通過kill命令發(fā)送信號給Nignx Master 進程，看看Master進程如何處理：

分析流程：

• Master 進程接收到 HUP 信號
• Master 進程重新加載配置文件
• Master 進程啟動新的Worker進程
• Master 進程發(fā)送信號給Worker 進程
• 老的Worker進程不再接收新的請求
• 老的Worker進程處理完當(dāng)前請求，退出
• 至此，Nginx完成平滑重啟

注意：Nginx 0.8 版本以后，提供了 -s參數(shù)，用于管理Nginx服務(wù)的停止和重啟，注意line 11：

2.2 Worker 進程工作機制

Worker進程負(fù)責(zé)所有請求的處理工作，我們通過一個HTTP請求，來梳理一下Worker的工作流程：

• 新的請求到來：所有的Work進程的listenfd都會變得可讀
• 竟搶互斥鎖：所有 Worker 進程在注冊listenfd讀事件前，要先搶accept_mutex
• 搶到互斥鎖的Worker，注冊listenfd讀事件，在事件中調(diào)用accept接受該連接
• 拿到請求后，Worker進程開始讀取請求，解析請求，處理請求，產(chǎn)生數(shù)據(jù)，再返回給客戶端
• Worker進程斷開連接

需要注意：一個HTTP請求，完全由Worker進程處理，而且只在一個Worker中處理

2.3 Master-Worker 進程架構(gòu)機制的優(yōu)勢有哪些？？

對于每個Worker 進程來說，獨立的進程，不需要加鎖，節(jié)約鎖導(dǎo)致的資源開銷；worker進程之間，互不干擾，平滑重啟就是很好的例子，服務(wù)不中斷。

2.4 網(wǎng)絡(luò)事件處理機制

Nginx 采用的是異步非阻塞事件處理機制，支持select/poll/epoll/kqueue 等等。Nginx 同時會監(jiān)控多個事件，調(diào)用他們是阻塞的。但是調(diào)用有超時時間，在超時時間內(nèi)，如果有事件準(zhǔn)備好了，就返回，否則重新放入epoll中。當(dāng)讀寫返回EAGAIN時，事件將會被再次放入epoll中。

處理線程只有一個，同時處理的請求也只有一個，所謂多請求并發(fā)，只是在不斷的切換請求而已。雖然是切換，但這種切換不涉及上下文切換，相比十分輕量。更多的并發(fā)，只是會占用更多的內(nèi)存。

進程相關(guān)的還有，信號和定時器，這部分另外單獨講解。

3. Nginx 包含哪些模塊

Nginx是模塊化架構(gòu)的服務(wù)，豐富的模塊，松散耦合，也讓Nginx更加強大！我看看Nginx 都有哪些模塊

內(nèi)核模塊

實現(xiàn)了底層的通訊協(xié)議，為其他模塊/進程構(gòu)建運行環(huán)境、協(xié)作基礎(chǔ)，打開listen 的端口，啟動worker進程

HTTP/Mail模塊

兩個特殊模塊，位于內(nèi)核模塊和各功能模塊間；在內(nèi)核模塊之上實現(xiàn)了另一層的抽象；處理HTTP/MAIL協(xié)議事件；確保調(diào)用功能模塊順序正確。

Event模塊

負(fù)責(zé)監(jiān)聽accept后建立的連接，對讀寫事件進行添加刪除；與非阻塞 I/O 模型結(jié)合使用；支持select/poll/epoll/kqueue等；注意驚群效應(yīng)，后面有解釋。

Handler模塊

負(fù)責(zé)接受客戶端請求并產(chǎn)生輸出；通過配置文件中l(wèi)ocation指令配置 content handler 模塊。

Filter模塊

負(fù)責(zé)輸出內(nèi)容處理，修改輸出內(nèi)容；Fiter模塊在獲取回復(fù)內(nèi)容之后，向用戶發(fā)送響應(yīng)之前，執(zhí)行處理動作；調(diào)用順序在編譯時就確定了。

Upstream模塊

實現(xiàn)反向代理的功能，負(fù)責(zé)將請求轉(zhuǎn)發(fā)到后端服務(wù)器上，并讀取響應(yīng)，發(fā)回客戶端；跨越單機的限制，完成網(wǎng)絡(luò)數(shù)據(jù)的接收、處理和轉(zhuǎn)發(fā)；

LoadBalancer模塊

根據(jù)配置指定算法，在眾多的后端服務(wù)器中選擇一個，完成請求的轉(zhuǎn)發(fā)服務(wù)器；都有哪些算法呢？

驚群效應(yīng)：

• 當(dāng)內(nèi)核 accept 一個連接時，會喚醒所有等待中的進程
• 但實際上只有一個進程能獲取連接，其他的進程都是被無效喚醒的
• 所以 Nginx 采用了自有的一套 accept 加鎖機制，避免多個進程同時調(diào)用 accept
• Nginx 多進程的鎖在底層默認(rèn)是通過 CPU 自旋鎖來實現(xiàn)。如果操作系統(tǒng)不支持自旋鎖，就采用文件鎖。