Nginx 的請求處理流程，你瞭解嗎？

以前咱們已經講解了 Nginx 的基礎內容，接下來咱們開始介紹 Nginx 的架構基礎。

爲何咱們要討論 Nginx 的架構基礎？

由於 Nginx 運行在企業內網的最外層也就是邊緣節點，那麼他處理的的流量是其餘應用服務器處理流量的數倍，甚至幾個數量級，咱們知道任何一種問題在不一樣的數量級下，他的解決方案是徹底不一樣的，因此在 Nginx 它所處理的應用場景中，全部的問題都會被放大，因此咱們必需要去理解，爲何 Nginx 採用 master-worker 這樣的一種架構模型，爲何 worker 進程的數量要和 CPU 的核數相匹配？當咱們須要在多個 worker 進程之間共享數據的時候，爲何在 TLS 或者說限流、限速這樣的場景，他們的共享方式是有所不一樣的，那麼這些都須要咱們對 Nginx 的架構有一個清晰的瞭解。

下面咱們先來看一下 Nginx 的請求處理流程。

爲何要去看 Nginx 中的請求處理流程呢？由於其實在以前中咱們瞭解到 Nginx 會記錄 access 日誌和 error 日誌，也能夠處理靜態的資源，那麼也能夠作反向代理，那麼這些東西咱們從 Nginx 內部去看他到底是怎樣處理這些請求，它包含一些什麼樣的組成部分呢？

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 的請求處理流程。