Nginx 的請求處理流程

本篇內(nèi)容主要講解“Nginx 的請求處理流程”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Nginx 的請求處理流程”吧!

為什么我們要討論 Nginx 的架構(gòu)基礎(chǔ)？

因?yàn)?Nginx 運(yùn)行在企業(yè)內(nèi)網(wǎng)的最外層也就是邊緣節(jié)點(diǎn)，那么他處理的的流量是其他應(yīng)用服務(wù)器處理流量的數(shù)倍，甚至幾個(gè)數(shù)量級，我們知道任何一種問題在不同的數(shù)量級下，他的解決方案是完全不同的，所以在 Nginx 它所處理的應(yīng)用場景中，所有的問題都會(huì)被放大，所以我們必須要去理解，為什么 Nginx 采用 master-worker 這樣的一種架構(gòu)模型，為什么 worker 進(jìn)程的數(shù)量要和 CPU 的核數(shù)相匹配？當(dāng)我們需要在多個(gè) worker 進(jìn)程之間共享數(shù)據(jù)的時(shí)候，為什么在 TLS 或者說限流、限速這樣的場景，他們的共享方式是有所不同的，那么這些都需要我們對 Nginx 的架構(gòu)有一個(gè)清晰的了解。

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

為什么要去看 Nginx 中的請求處理流程呢？因?yàn)槠鋵?shí)在之前中我們了解到 Nginx 會(huì)記錄 access 日志和 error 日志，也可以處理靜態(tài)的資源，那么也可以做反向代理，那么這些東西我們從 Nginx 內(nèi)部去看他究竟是怎樣處理這些請求，它包含一些什么樣的組成部分呢？

Nginx 的請求處理流程

我們從這張圖的最左邊來看，最左邊在 WEB、EMAIL 和 TCP，也就是說大致有三種流量從這里進(jìn)入 Nginx 以后，我們 Nginx 中有三個(gè)大的狀態(tài)機(jī)，一個(gè)是處理 TCP/UDP 的 4 層的傳輸層狀態(tài)機(jī)和處理應(yīng)用層的 HTTP 狀態(tài)以及處理郵件的 MAIL 狀態(tài)機(jī)。

那么為什么我們叫它狀態(tài)機(jī)呢？是因?yàn)?Nginx 核心的這個(gè)大綠色的框他是用非阻塞的事件驅(qū)動(dòng)處理引擎就是用我們所熟知的 epoll，那么一旦我們使用這種異步處理引擎以后，通常都是需要用狀態(tài)機(jī)來把這個(gè)請求正確的識(shí)別和處理。

基于這樣的一種事件狀態(tài)處理機(jī)，我們在解析出請求需要訪問靜態(tài)資源的時(shí)候，我們看到走左下方的這個(gè)箭頭，那么它就找到了靜態(tài)資源，如果我們?nèi)プ龇聪虼淼臅r(shí)候呢，那么對反向代理的內(nèi)容，我可以做磁盤緩存，緩存到磁盤上，也在下面左下方這條線，但是我們在處理靜態(tài)資源的時(shí)候，會(huì)有一個(gè)問題就是當(dāng)整個(gè)內(nèi)存已經(jīng)不足以完全的緩存所有的文件和信息的時(shí)候，那么像 send File 這樣的調(diào)用或者 AIO 會(huì)退化成阻塞的磁盤調(diào)用，所以在這里我們需要有一個(gè)線程池來處理，對于每一個(gè)處理完成的請求呢，我們會(huì)進(jìn)入 access 日志或 error 日志。

那么這里也是進(jìn)入了磁盤中的，當(dāng)然我們可以通過 syslog 協(xié)議把它進(jìn)入到遠(yuǎn)程的機(jī)器上，那么更多的時(shí)候我們的 Nginx 是作為負(fù)載均衡或者反向代理來使用的，就是我們可以把請求通過協(xié)議級（HTTP，Mail 及 stream（TCP））傳輸?shù)胶竺娴姆?wù)器，也可以通過例如應(yīng)用層的一些協(xié)議（FastCGI、uWSGI、SCGI、memcached）代理到相應(yīng)的應(yīng)用服務(wù)器。以上就是 Nginx 的請求處理流程。

到此，相信大家對“Nginx 的請求處理流程”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！