與眾不同的服務(wù)是因為有心

 

 
 

 
 

 
 

 

 

北京it外包 |   Nginx 架構(gòu)詳解

 

Nginx 服務(wù)器是一個高性能的 Web 和反向代理服務(wù)器。Nginx 在激烈的 Web 服務(wù)器競爭中依舊保持良好的發(fā)展勢頭，一度成為 Web 服務(wù)器市場的后期之秀，這一切跟 Nginx 的架構(gòu)設(shè)計是分不開的。
 
Nginx 模塊化設(shè)計

高度模塊化的設(shè)計是 Nginx 的架構(gòu)基礎(chǔ)。Nginx 服務(wù)器被分解為多個模塊，每個模塊就是一個功能模塊，只負責自身的功能，模塊之間嚴格遵循“高內(nèi)聚，低耦合”的原則。
 

 

核心模塊
核心模塊是 Nginx 服務(wù)器正常運行必不可少的模塊，提供錯誤日志記錄、配置文件解析、事件驅(qū)動機制、進程管理等核心功能。

標準 HTTP 模塊

標準 HTTP 模塊提供 HTTP 協(xié)議解析相關(guān)的功能，如：端口配置、網(wǎng)頁編碼設(shè)置、HTTP 響應(yīng)頭設(shè)置等。

可選 HTTP 模塊

可選 HTTP 模塊主要用于擴展標準的 HTTP 功能，讓 Nginx 能處理一些特殊的服務(wù)，如：Flash 多媒體傳輸、解析 GeoIP 請求、SSL 支持等。

郵件服務(wù)模塊

郵件服務(wù)模塊主要用于支持 Nginx 的郵件服務(wù)，包括對 POP3 協(xié)議、IMAP 協(xié)議和 SMTP 協(xié)議的支持。

第三方模塊

第三方模塊是為了擴展 Nginx 服務(wù)器應(yīng)用，完成開發(fā)者自定義功能，如：Json 支持、Lua 支持等。

Nginx 請求處理方式

Nginx 是一個高性能的 Web 服務(wù)器，能夠同時處理大量的并發(fā)請求。它結(jié)合多進程機制和異步機制，異步機制使用的是異步非阻塞方式，接下來就給大家介紹一下 Nginx 的多線程機制和異步非阻塞機制。

多進程

服務(wù)器每當收到一個客戶端時。就有服務(wù)器主進程（master process）生成一個子進程（worker process）出來和客戶端建立連接進行交互，直到連接斷開，該子進程就結(jié)束了。

使用進程的好處是各個進程之間相互獨立，不需要加鎖，減少了使用鎖對性能造成影響，同時降低編程的復(fù)雜度，降低開發(fā)成本。其次，采用獨立的進程，可以讓進程互相之間不會影響，如果一個進程發(fā)生異常退出時，其它進程正常工作，master 進程則很快啟動新的 worker 進程，確保服務(wù)部中斷，將風險降到最低。

缺點是操作系統(tǒng)生成一個子進程需要進行內(nèi)存復(fù)制等操作，在資源和時間上會產(chǎn)生一定的開銷；當有大量請求時，會導(dǎo)致系統(tǒng)性能下降。

異步非阻塞

每個工作進程使用異步非阻塞方式，可以處理多個客戶端請求。當某個工作進程接收到客戶端的請求以后，調(diào)用 IO 進行處理，如果不能立即得到結(jié)果，就去處理其他的請求（即為非阻塞）；而客戶端在此期間也無需等待響應(yīng)，可以去處理其他事情（即為異步）；當 IO 返回時，就會通知此工作進程；該進程得到通知，暫時掛起當前處理的事務(wù)去響應(yīng)客戶端請求。

Nginx 事件驅(qū)動模型

在 Nginx 的異步非阻塞機制中，工作進程在調(diào)用 IO 后，就去處理其他的請求，當 IO 調(diào)用返回后，會通知該工作進程。對于這樣的系統(tǒng)調(diào)用，主要使用 Nginx 服務(wù)器的事件驅(qū)動模型來實現(xiàn)。
 

 

如上圖所示，Nginx 的事件驅(qū)動模型由事件收集器、事件發(fā)送器和事件處理器三部分基本單元組成。其中，事件收集器負責收集 worker 進程的各種 IO 請求，事件發(fā)送器負責將 IO 事件發(fā)送到事件處理器，而事件處理器負責各種事件的響應(yīng)工作。事件發(fā)送器將每個請求放入一個待處理事件的列表，使用非阻塞 I/O 方式調(diào)用“事件處理器”來處理該請求。其處理方式稱為“多路 IO 復(fù)用方法”，常見的包括以下三種：select 模型、poll 模型、epoll 模型。

針對上面的技術(shù)我特意整理了一下，有很多技術(shù)不是靠幾句話能講清楚，所以干脆找朋友錄制了一些視頻，很多問題其實答案很簡單，但是背后的思考和邏輯不簡單，要做到知其然還要知其所以然。


Nginx 設(shè)計架構(gòu)

Nginx 服務(wù)器使用 master/worker 多進程模式。多線程啟動和執(zhí)行的流程如下：主程序 Master process 啟動后，通過一個 for 循環(huán)來接收和處理外部信號；主進程通過 fork() 函數(shù)產(chǎn)生子進程，每個子進程執(zhí)行一個 for 循環(huán)來實現(xiàn) Nginx 服務(wù)器對事件的接收和處理。一般推薦 worker 進程數(shù)與 cpu 內(nèi)核數(shù)一致，這樣一來不存在大量的子進程生成和管理任務(wù)，避免了進程之間競爭 CPU 資源和進程切換的開銷。而且 Nginx 為了更好的利用多核特性，提供了 cpu 親緣性的綁定選項，我們可以將某一個進程綁定在某一個核上，這樣就不會因為進程的切換帶來 cache 的失效。對于每個請求，有且只有一個工作進程對其處理。首先，每個 worker 進程都是從 master 進程 fork 過來，在 master 進程里面，先建立好需要 listen 的 socket（listenfd）之后，然后再 fork 出多個 worker 進程。所有 worker 進程的 listenfd 會在新連接到來時變得可讀，為保證只有一個進程處理該連接，所有 worker 進程在注冊 listenfd 讀事件前搶 accept_mutex，搶到互斥鎖的那個進程注冊 listenfd 讀事件，在讀事件里調(diào)用 accept 接受該連接。當一個 worker 進程在 accept 這個連接之后，就開始讀取請求，解析請求，處理請求，產(chǎn)生數(shù)據(jù)后，再返回給客戶端，最后才斷開連接，這樣一個完整的請求就是這樣的了。我們可以看到，一個請求，完全由 worker 進程來處理，而且只在一個 worker 進程中處理。
 

 

在 Nginx 服務(wù)器的運行過程中，主進程和工作進程需要進程交互。交互依賴于 Socket 實現(xiàn)的管道來實現(xiàn)。

Master-Worker 交互

這條管道與普通的管道不同，它是由主進程指向工作進程的單向管道，包含主進程向工作進程發(fā)出的指令，工作進程 ID 等；同時主進程與外界通過信號通信；每個子進程具備接收信號，并處理相應(yīng)的事件的能力。

worker-worker 交互

這種交互是和 Master-Worker 交互是基本一致的，但是會通過主進程。工作進程之間是相互隔離的，所以當工作進程 W1 需要向工作進程 W2 發(fā)指令時，首先找到 W2 的進程 ID，然后將正確的指令寫入指向 W2 的通道。W2 收到信號采取相應(yīng)的措施。
 
總結(jié)

通過這篇文章，我們對 Nginx 服務(wù)器的整體架構(gòu)有了一個整體的認識。包括其模塊化的設(shè)計、多進程和異步非阻塞的請求處理方式、事件驅(qū)動模型等。通過這些理論知識，對于我們以后學習 Nginx 的源碼有很大的幫助；也推薦大家多看看 Nginx 的源碼，才能更好地領(lǐng)悟 Nginx 的設(shè)計思想。