Nginx的模塊與工作原理

Nginx由內核和模塊組成，其中，內核的設計非常微小和簡潔，完成的工作也非常簡單，僅僅通過查找配置文件將客戶端請求映射到一個location block（location是Nginx配置中的一個指令，用于URL匹配），而在這個location中所配置的每個指令將會啟動不同的模塊去完成相應的工作。

Nginx的模塊從結構上分為核心模塊、基礎模塊和第三方模塊：

• 核心模塊：HTTP模塊、EVENT模塊和MAIL模塊；
• 基礎模塊：HTTP Access模塊、HTTP FastCGI模塊、HTTP Proxy模塊和HTTP Rewrite模塊；
• 第三方模塊：HTTP Upstream Request Hash模塊、Notice模塊和HTTP Access Key模塊。

用戶根據自己的需要開發的模塊都屬于第三方模塊。正是有了這么多模塊的支撐，Nginx的功能才會如此強大。

Nginx的模塊從功能上分為如下三類：

• Handlers（處理器模塊）。此類模塊直接處理請求，并進行輸出內容和修改headers信息等操作。Handlers處理器模塊一般只能有一個。
• Filters（過濾器模塊）。此類模塊主要對其他處理器模塊輸出的內容進行修改操作，最后由Nginx輸出。
• Proxies（代理類模塊）。此類模塊是Nginx的HTTP Upstream之類的模塊，這些模塊主要與后端一些服務比如FastCGI等進行交互，實現服務代理和負載均衡等功能。

下圖展示了Nginx模塊常規的HTTP請求和響應的過程。

Nginx本身做的工作實際很少，當它接到一個HTTP請求時，它僅僅是通過查找配置文件將此次請求映射到一個location block，而此location中所配置的各個指令則會啟動不同的模塊去完成工作，因此模塊可以看做Nginx真正的勞動工作者。通常一個location中的指令會涉及一個handler模塊和多個filter模塊（當然，多個location可以復用同一個模塊）。handler模塊負責處理請求，完成響應內容的生成，而filter模塊對響應內容進行處理。

Nginx的模塊直接被編譯進Nginx，因此屬于靜態編譯方式。啟動Nginx后，Nginx的模塊被自動加載，不像Apache，首先將模塊編譯為一個so文件，然后在配置文件中指定是否進行加載。在解析配置文件時，Nginx的每個模塊都有可能去處理某個請求，但是同一個處理請求只能由一個模塊來完成。

Nginx的進程模型

在工作方式上，Nginx分為單工作進程和多工作進程兩種模式。在單工作進程模式下，除主進程外，還有一個工作進程，工作進程是單線程的；在多工作進程模式下，每個工作進程包含多個線程。Nginx默認為單工作進程模式。

Nginx在啟動后，會有一個master進程和多個worker進程。

master進程

master進程主要用來管理worker進程，包含：

• 接收來自外界的信號；
• 向各worker進程發送信號；
• 監控worker進程的運行狀態，當worker進程退出后(異常情況下)，會自動重新啟動新的worker進程。

master進程充當整個進程組與用戶的交互接口，同時對進程進行監護。它不需要處理網絡事件，不負責業務的執行，只會通過管理worker進程來實現重啟服務、平滑升級、更換日志文件、配置文件實時生效等功能。

我們要控制nginx，只需要通過kill向master進程發送信號就行了。比如kill -HUP pid，則是告訴nginx，從容地重啟nginx，我們一般用這個信號來重啟nginx，或重新加載配置，因為是從容地重啟，因此服務是不中斷的。

master進程在接收到HUP信號后是怎么做的呢？首先master進程在接到信號后，會先重新加載配置文件，然后再啟動新的worker進程，并向所有老的worker進程發送信號，告訴他們可以光榮退休了。新的worker在啟動后，就開始接收新的請求，而老的worker在收到來自master的信號后，就不再接收新的請求，并且在當前進程中的所有未處理完的請求處理完成后，再退出。當然，直接給master進程發送信號，這是比較老的操作方式，nginx在0.8版本之后，引入了一系列命令行參數，來方便我們管理。比如，./nginx -s reload，就是來重啟nginx，./nginx -s stop，就是來停止nginx的運行。

如何做到的呢？我們還是拿reload來說，我們看到，執行命令時，我們是啟動一個新的nginx進程，而新的nginx進程在解析到reload參數后，就知道我們的目的是控制nginx來重新加載配置文件了，它會向master進程發送信號，然后接下來的動作，就和我們直接向master進程發送信號一樣了。

worker進程

而基本的網絡事件，則是放在worker進程中來處理了。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。

worker進程的個數是可以設置的，一般我們會設置與機器cpu核數一致，這里面的原因與nginx的進程模型以及事件處理模型是分不開的。

worker進程之間是平等的，每個進程，處理請求的機會也是一樣的。當我們提供80端口的http服務時，一個連接請求過來，每個進程都有可能處理這個連接，怎么做到的呢？

首先，每個worker進程都是從master進程fork過來，在master進程里面，先建立好需要listen的socket（listenfd）之后，然后再fork出多個worker進程。所有worker進程的listenfd會在新連接到來時變得可讀，為保證只有一個進程處理該連接，所有worker進程在注冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進程注冊listenfd讀事件，在讀事件里調用accept接受該連接。當一個worker進程在accept這個連接之后，就開始讀取請求，解析請求，處理請求，產生數據后，再返回給客戶端，最后才斷開連接，這樣一個完整的請求就是這樣的了。我們可以看到，一個請求，完全由worker進程來處理，而且只在一個worker進程中處理。

nginx的進程模型，可以由下圖來表示：

總結

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

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