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 高性能、高併發
- Nginx 採用：多進程 + 異步非阻塞方式（IO 多路複用 epoll）
- 請求的完整過程：
- 建立連接
- 讀取請求：解析請求
- 處理請求
- 響應請求
- 請求的完整過程，對應到底層，就是：讀寫 socket 事件
Nginx 的事件處理模型
request：Nginx 中 http 請求。
基本的 HTTP Web Server 工作模式：
- 接收請求：逐行讀取請求行和請求頭，判斷段有請求體後，讀取請求體
- 處理請求
- 返回響應：根據處理結果，生成相應的 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: 負載均衡模塊，實現特定的算法，在眾多的後端服務器中，選擇一個服務器出來作為某個請求的轉發服務器。
常見問題剖析
Nginx vs. Apache
網絡 IO 模型：
- nginx：IO 多路複用，epoll(freebsd 上是 kqueue )
- 高性能
- 高併發
- 佔用系統資源少
- apache：阻塞 + 多進程/多線程
- 更穩定，bug 少
- 模塊更豐富
場景：
處理多個請求時，可以採用：IO 多路複用 或者 阻塞 IO +多線程
- IO 多路服用：一個 線程，跟蹤多個 socket 狀態，哪個就緒，就讀寫哪個；
- 阻塞 IO + 多線程：每一個請求，新建一個服務線程
思考：IO 多路複用 和 多線程 的適用場景？
- IO 多路複用：單個連接的請求處理速度沒有優勢，適合 IO 密集型 場景，事件驅動
- 大併發量：只使用一個線程，處理大量的併發請求，降低上下文環境切換損耗，也不需要考慮併發問題，相對可以處理更多的請求；
- 消耗更少的系統資源（不需要線程調度開銷）
- 適用於長連接的情況（多線程模式長連接容易造成線程過多，造成頻繁調度）
- 阻塞IO + 多線程：實現簡單，可以不依賴系統調用，適合 CPU 密集型 場景
- 每個線程，都需要時間和空間；
- 線程數量增長時，線程調度開銷指數增長
Nginx 最大連接數
基礎背景：
- Nginx 是多進程模型，Worker 進程用於處理請求；
- 單個進程的連接數（文件描述符 fd），有上限（nofile）：ulimit -n
- Nginx 上配置單個 worker 進程的最大連接數：worker_connections 上限為 nofile
- Nginx 上配置 worker 進程的數量：worker_processes
因此，Nginx 的最大連接數：
- Nginx 的最大連接數：Worker 進程數量 x 單個 Worker 進程的最大連接數
- 上面是 Nginx 作為通用服務器時，最大的連接數
- Nginx 作為反向代理服務器時，能夠服務的最大連接數：（Worker 進程數量 x 單個 Worker 進程的最大連接數）/ 2。
- Nginx 反向代理時，會建立 Client 的連接和後端 Web Server 的連接，佔用 2 個連接
思考：
每打開一個 socket 佔用一個 fd
為什麼，一個進程能夠打開的 fd 數量有限制？
IO 模型
場景：
處理多個請求時，可以採用：IO 多路複用 或者 阻塞 IO +多線程
- IO 多路複用：一個 線程，跟蹤多個 socket 狀態，哪個就緒，就讀寫哪個；
- 阻塞 IO + 多線程：每一個請求，新建一個服務線程
思考：IO 多路複用 和 多線程 的適用場景？
- IO 多路複用：單個連接的請求處理速度沒有優勢
- 大併發量：只使用一個線程，處理大量的併發請求，降低上下文環境切換損耗，也不需要考慮併發問題，相對可以處理更多的請求；
- 消耗更少的系統資源（不需要線程調度開銷）
- 適用於長連接的情況（多線程模式長連接容易造成線程過多，造成頻繁調度）
- 阻塞IO + 多線程：實現簡單，可以不依賴系統調用。
- 每個線程，都需要時間和空間；
- 線程數量增長時，線程調度開銷指數增長
select/poll 和 epoll 比較
詳細內容，參考：
- select poll epoll三者之間的比較
select/poll 系統調用：
<code>//select系統調用
intselect(intmaxfdp,fd_set*readfds,fd_set*writefds,fd_set*errorfds,structtimeval*timeout);
//poll系統調用
intpoll(structpollfdfds[],nfds_tnfds,inttimeout)；/<code>
select：
- 查詢 fd_set 中，是否有就緒的 fd，可以設定一個超時時間，當有 fd (File descripter) 就緒或超時返回；
- fd_set 是一個位集合，大小是在編譯內核時的常量，默認大小為 1024
- 特點：
- 連接數限制，fd_set 可表示的 fd 數量太小了；
- 線性掃描：判斷 fd 是否就緒，需要遍歷一邊 fd_set；
- 數據複製：用戶空間和內核空間，複製連接就緒狀態信息
poll：
- 解決了連接數限制：
- poll 中將 select 中的 fd_set 替換成了一個 pollfd 數組
- 解決 fd 數量過小的問題
- 數據複製：用戶空間和內核空間，複製連接就緒狀態信息
- epoll：event 事件驅動
epoll：event 事件驅動
- 事件機制：避免線性掃描
- 為每個 fd，註冊一個監聽事件
- fd 變更為就緒時，將 fd 添加到就緒鏈表
- fd 數量：無限制（OS 級別的限制，單個進程能打開多少個 fd）
select，poll，epoll：
- I/O多路複用的機制；
- I/O多路複用就通過一種機制，可以監視多個描述符，一旦某個描述符就緒（一般是讀就緒或者寫就緒），能夠通知程序進行相應的讀寫操作。
- 監視多個文件描述符
- 但select，poll，epoll本質上都是同步I/O：
- 用戶進程負責讀寫（從內核空間拷貝到用戶空間），讀寫過程中，用戶進程是阻塞的；
- 異步 IO，無需用戶進程負責讀寫，異步IO，會負責從內核空間拷貝到用戶空間；
Nginx 的併發處理能力
關於 Nginx 的併發處理能力：
- 併發連接數，一般優化後，峰值能保持在 1~3w 左右。（內存和 CPU 核心數不同，會有進一步優化空間）
最後
覺得此文不錯的大佬們可以多多關注或者幫忙轉發分享一下哦，感謝！！！！
分享到:
閱讀更多 程序媛拾玖 的文章
