因為 nginx 執行在企業內網的最外層也就是邊緣節點，那麼他處理的的流量是其他應用伺服器處理流量的數倍，甚至幾個數量級，我們知道任何一種問題在不同的數量級下，他的解決方案是完全不同的，所以在 nginx 它所處理的應用場景中，所有的問題都會被放大，所以我們必須要去理解，為什麼 nginx 採用 master-worker 這樣的一種架構模型，為什麼 worker 程序的數量要和 cpu 的核數相匹配？當我們需要在多個 worker 程序之間共享資料的時候，為什麼在 tls 或者說限流、限速這樣的場景，他們的共享方式是有所不同的，那麼這些都需要我們對 nginx 的架構有乙個清晰的了解。
下面我們先來看一下 nginx 的請求處理流程。
為什麼要去看 nginx 中的請求處理流程呢？因為其實在之前中我們了解到 nginx 會記錄 access 日誌和 error 日誌，也可以處理靜態的資源，那麼也可以做反向**，那麼這些東西我們從 nginx 內部去看他究竟是怎樣處理這些請求，它包含一些什麼樣的組成部分呢？
我們從這張圖的最左邊來看，最左邊在 web、email 和 tcp，也就是說大致有三種流量從這裡進入 nginx 以後，我們 nginx 中有三個大的狀態機，乙個是處理 tcp/udp 的 4 層的傳輸層狀態機和處理應用層的 http 狀態以及處理郵件的 mail 狀態機。
那麼為什麼我們叫它狀態機呢？是因為 nginx 核心的這個大綠色的框他是用非阻塞的事件驅動處理引擎就是用我們所熟知的 epoll，那麼一旦我們使用這種非同步處理引擎以後，通常都是需要用狀態機來把這個請求正確的識別和處理。
基於這樣的一種事件狀態處理機，我們在解析出請求需要訪問靜態資源的時候，我們看到走左下方的這個箭頭，那麼它就找到了靜態資源，如果我們去做反向**的時候呢，那麼對反向**的內容，我可以做磁碟快取，快取到磁碟上，也在下面左下方這條線，但是我們在處理靜態資源的時候，會有乙個問題就是當整個記憶體已經不足以完全的快取所有的檔案和資訊的時候，那麼像 send file 這樣的呼叫或者 aio 會退化成阻塞的磁碟呼叫，所以在這裡我們需要有乙個執行緒池來處理，對於每乙個處理完成的請求呢，我們會進入 access 日誌或 error 日誌。
那麼這裡也是進入了磁碟中的，當然我們可以通過 syslog 協議把它進入到遠端的機器上，那麼更多的時候我們的 nginx 是作為負載均衡或者反向**來使用的，就是我們可以把請求通過協議級（http，mail 及 stream（tcp））傳輸到後面的伺服器，也可以通過例如應用層的一些協議（fastcgi、uwsgi、scgi、memcached）**到相應的應用伺服器。以上就是 nginx 的請求處理流程。
Nginx處理請求的流程
nginx處理請求過程 nginx使用乙個多程序模型來對外提供服務，乙個master程序和多個worker程序，master程序負責管理nginx本身和其他worker程序。所有實際上的業務處理邏輯都在worker程序。worker程序中有乙個函式，執行無限迴圈，不斷處理收到的來自客戶端的請求，並進...
nginx處理http請求完整流程
在nginx的worker程序啟動後，便阻塞在epoll wait函式 ngx epoll process events 等待http請求的到來，那麼當乙個http請求到來之時，nginx是如何作出相應的呢？下面介紹該過程。首先，在ngx event process init函式中，可看到rev h...
Nginx模組和請求處理流程簡介
nginx由核心和模組組成的，其中核心完成的工作比較簡單，僅僅通過查詢配置檔案見客戶端請求對映到乙個location block，然後又這個location block中所配置的每個指令將會啟動不同的模組去完成相應的工作。一 nginx模組 1 從結構上nginx分為核心模組，基礎模組和第三方模組，...