Nginx爲何高效？一文搞明白Nginx核心原理

Nginx 的進程模型

Nginx 服務器，正常運行過程當中：

• 多進程：一個 Master 進程、多個 Worker 進程
• Master 進程：管理 Worker 進程
• 對外接口：接收外部的操做（信號）
• 對內轉發：根據外部的操做的不一樣，經過信號管理 Worker
• 監控：監控 worker 進程的運行狀態，worker 進程異常終止後，自動重啓 worker 進程
• Worker 進程：全部 Worker 進程都是平等的
• 實際處理：網絡請求，由 Worker 進程處理；
• Worker 進程數量：在 nginx.conf 中配置，通常設置爲核心數，充分利用 CPU 資源，同時，避免進程數量過多，避免進程競爭 CPU 資源，增長上下文切換的損耗。

思考：

• 請求是鏈接到 Nginx，Master 進程負責處理和轉發？
• 如何選定哪一個 Worker 進程處理請求？請求的處理結果，是否還要通過 Master 進程？

HTTP 鏈接創建和請求處理過程：

• Nginx 啓動時，Master 進程，加載配置文件
• Master 進程，初始化監聽的 socket
• Master 進程，fork 出多個 Worker 進程
• Worker 進程，競爭新的鏈接，獲勝方經過三次握手，創建 Socket 鏈接，並處理請求

Nginx 高性能、高併發：

1. Nginx 採用：多進程 + 異步非阻塞方式（IO 多路複用 epoll）
2. 請求的完整過程：
3. 創建鏈接
4. 讀取請求：解析請求
5. 處理請求
6. 響應請求
7. 請求的完整過程，對應到底層，就是：讀寫 socket 事件

Nginx 的事件處理模型

request：Nginx 中 http 請求。

基本的 HTTP Web Server 工做模式：

1. 接收請求：逐行讀取請求行和請求頭，判斷段有請求體後，讀取請求體
2. 處理請求
3. 返回響應：根據處理結果，生成相應的 HTTP 請求（響應行、響應頭、響應體）

Nginx 也是這個套路，總體流程一致。

模塊化體系結構

nginx的模塊根據其功能基本上能夠分爲如下幾種類型：

• event module: 搭建了獨立於操做系統的事件處理機制的框架，及提供了各具體事件的處理。包括ngx_events_module， ngx_event_core_module和ngx_epoll_module等。nginx具體使用何種事件處理模塊，這依賴於具體的操做系統和編譯選項。
• phase handler: 此類型的模塊也被直接稱爲handler模塊。主要負責處理客戶端請求併產生待響應內容，好比ngx_http_static_module模塊，負責客戶端的靜態頁面請求處理並將對應的磁盤文件準備爲響應內容輸出。
• output filter: 也稱爲filter模塊，主要是負責對輸出的內容進行處理，能夠對輸出進行修改。例如，能夠實現對輸出的全部html頁面增長預約義的footbar一類的工做，或者對輸出的圖片的URL進行替換之類的工做。
• upstream: upstream模塊實現反向代理的功能，將真正的請求轉發到後端服務器上，並從後端服務器上讀取響應，發回客戶端。upstream模塊是一種特殊的handler，只不過響應內容不是真正由本身產生的，而是從後端服務器上讀取的。
• load-balancer: 負載均衡模塊，實現特定的算法，在衆多的後端服務器中，選擇一個服務器出來做爲某個請求的轉發服務器。

版權申明：文章源自原文：http://ningg.top/nginx-series...，版權歸原創者全部。除非沒法確認，咱們都會標明做者及出處，若有侵權煩請告知，咱們會當即刪除並表示歉意，謝謝。