Nginx服務架構刨析

導讀 我們知道Nginx從總體上來講是有許多個模塊構成的。習慣將Nginx分爲5大模塊分別爲:核心模塊,標準HTTP模塊,可選HTTP模塊,郵件服務模塊和第三方模塊。

一.Nginx的模塊化

模塊化結構的思想是一個很久的概念,但也正是成熟的思想造就了Nginx的巨大優越性。

我們知道Nginx從總體上來講是有許多個模塊構成的。習慣將Nginx分爲5大模塊分別爲:核心模塊,標準HTTP模塊,可選HTTP模塊,郵件服務模塊和第三方模塊。這5個模塊由上到下重要性一次遞減。

Nginx服務架構刨析Nginx服務架構刨析

(1)核心模塊

核心模塊是Nginx服務器正常運行必不可少的模塊,如同操作系統的內核。它提供了Nginx最基本的核心服務。像進程管理、權限控制、錯誤日誌記錄等;

(2)標準HTTP模塊

標準HTTP模塊支持標準的HTTP的功能;

(3)可選HTTP模塊

可選HTTP模塊主要用於擴展標準的HTTP功能,讓Nginx能處理一些特殊的服務;

(4)郵件服務模塊

郵件服務模塊主要用於支持Nginx的郵件服務;

(5)第三方模塊

第三方模塊是爲了擴展Nginx服務器應用,完成開發者想要的功能;

*******Nginx中的模塊命名有自己的習慣*********

一般以Ngx_作爲前綴,——module作爲後綴,中間使用一個或者多個英文單詞描述模塊的工能,例如Ngx_core_module表示該模塊提供Nginx的核心功能等;

具體各個模塊中包含哪些模塊可以自己去源碼中查詢,這裏略過;

二.Nginx的web請求處理機制

從架構設計上說,Nginx服務器是與衆不同的。其一在於它的模塊化設計;其二也是更重要的一點在於它對與客戶端請求的處理機制上;

web服務器和客戶端是一對多的關係,Web服務器必須有能力同時爲多個客戶端提供服務。一般來說完成並行處理請求工作有以下三種方式:

(1)多進程方式

多進程方式指,服務器每當收到一個客戶端時。就有服務器主進程生成一個子進程出來和客戶端建立連接進行交互。指導連接斷開。該子進程就結束了。

多進程方式的優點是設計簡單,各個子進程相對獨立,處理客戶端請求時彼此不受干擾;缺點是操作系統生成一個子進程需要進行內存複製等操作,在資源和時間上會產生一定的開銷;當有大量請求時,會導致系統性能下降;

(2)多線程方式

多線程方式指每當服務器接收到一個請求後,會由服務器主進程派生出一個線程出來和客戶端進行交互。由於操作系統產生出一個線程的開銷遠遠小於一個進程的開銷。故多線程方式在很大程度上減輕了Web服務器對系統資源的要求。但同時由於多個線程位於一個進程內,可以訪問同樣的內存空間。所以需要開發者自己對內存進程管理,增大了難度。

(3)異步方式

異步方式適合多進程和多線程完全不同的一種處理客戶端請求的方式。這裏有幾個概念我們需要熟悉一下:同步,異步,阻塞,非阻塞;

在網絡通信中同步和異步是描述通信模式的概念。

同步:發送方發送完請求後,需要等待接收到接收方發回的響應,才能發送下一個請求;所有請求在服務端得到同步,發送方和接收方的步調是一致的;

異步:和同步機制相反,在異步機制中,發送方發出一個請求後,不等接收方響應這個請求,就繼續發送下一個請求;所有來自發送方的請求形成一個隊列,接收方處理完成後通知發送方;

在進程處理調度方式上用阻塞與非阻塞。在網絡通信中主要指套接字socket的阻塞和非阻塞,而socket的實質就是IO操作。

阻塞:調用結果返回之前,當前線程從運行狀態被掛起,一直等到調用結果返回之後,才進入就緒狀態,獲取CPU後繼續執行。

非阻塞:和阻塞方式正好相反,如果調用結果不能馬上返回,當前線程也不會馬上返回,而是立即返回執行下一個調用。

因此就衍生出4中方式:同步阻塞,同步非阻塞,異步阻塞,異步非阻塞

這裏簡單解釋一下異步非阻塞:發送方向接收方發送請求後,不用等待響應,可以繼續其他工作;接收方處理請求時進行的IO操作如果不能馬上得到結果,也不必等待,而是馬上返回去去做其他事情。當IO操作完成以後,將完成狀態和結果通知接收方,接收方再響應發送方。

與此同時Nginx服務器處理請求是怎樣的呢???

Nginx服務器的一個顯著的優勢就是能夠同時處理大量的併發請求。它結合多進程機制和異步機制。異步機制使用的是異步非阻塞方式。(Master-Worker)。

每個工作進程使用異步非阻塞方式,可以處理多個客戶端請求。當某個工作進程接收到客戶端的請求以後,調用IO進行處理,如果不能立即得到結果,就去處理其他的請求;而客戶端在此期間也無需等待響應,可以去處理其他事情;當IO返回時,就會通知此工作進程;該進程得到通知,暫時掛起當前處理的失誤去響應客戶端請求。

也就是:

Nginx採用異步非阻塞方式來處理請求,處理請求具體到系統底層就是讀寫事件(所謂阻塞調用方式即請求事件還沒準備好,線程只能一直去等,等事件準備好了再處理;而非阻塞即事件沒準備好,馬上返回ENGAIN,告訴你事件還沒準準備好,而在這期間可以先去做其他事,再回頭看看事件準備好了嗎,時不時會看,需要的開銷也是不小的)

異步可以理解爲循環處理多個準備好的事件,不會導致無謂的資源浪費,當有更多的併發數只會佔用更多的內存而已;

三.Nginx服務器的實踐驅動模型

從上面我們可以知道,Nginx服務器的工作進程調用IO後,就取進行其他工作了;當IO調用返回後,會通知工作進程。但IO調用時如何把自己的狀態通知給工作進程的呢??

一般解決這個問題有兩種方法:

(1)讓工作進程在進行其他工作的過程中間隔一段時間就去檢查一下IO的狀態,如果完成就響應客戶端,如果未完成,繼續工作。

(2)IO調用在完成後能主動通知工作進程。

當然最好的就是用第二種方法了;像select/poll/epoll等這樣的系統調用就是用來支持第二種解決方案的。這些系統調用也常被稱爲事件驅動模型。他們提供了一種機制就只讓進程同時處理多個併發請求,不用關心IO調用的具體狀態。IO調用完全由事件驅動模型來管理。

Nginx中的事件驅動模型

就是用事件驅動處理庫(多路IO複用),最常用的就是select模型,poll模型,epoll模型。

關於這三個模型的詳解在這裏可以看到:https://segmentfault.com/a/1190000003063859

四.架構簡介

通過這個上面的簡單講解,再加上服務器的架構的瞭解,可以對Nginx有一個簡單的瞭解,希望對之後的源碼剖析有幫助。
Nginx服務架構刨析Nginx服務架構刨析

大致上Nginx的架構就是這樣:

1.Nginx啓動後,會產生一個主進程,主進程執行一系列的工作後會產生一個或者多個工作進程;

2.在客戶端請求動態站點的過程中,Nginx服務器還涉及和後端服務器的通信。Nginx將接收到的Web請求通過代理轉發到後端服務器,由後端服務器進行數據處理和組織;

3.Nginx爲了提高對請求的響應效率,降低網絡壓力,採用了緩存機制,將歷史應答數據緩存到本地。保障對緩存文件的快速訪問;

工作進程

工作進程的主要工作有以下幾項:

1、接收客戶端請求:將請求一次送入各個功能模塊進行過濾處理;

2、IO調用,獲取響應數據:與後端服務器通信,接收後端服務器處理結果;

3、數據緩存:響應客戶端請求;

進程交互

Nginx服務器在使用Master-Worker模型時,會涉及到主進程和工作進程的交互和工作進程之間的交互。這兩類交互都依賴於管道機制。

1.Master-Worker交互
這條管道與普通的管道不同,它是由主進程指向工作進程的單向管道,包含主進程向工作進程發出的指令,工作進程ID等;同時主進程與外界通過信號通信;

2.worker-worker交互

這種交互是和Master-Worker交互是基本一致的。但是會通過主進程。工作進程之間是相互隔離的,所以當工作進程W1需要向工作進程W2發指令時,首先找到W2的進程ID,然後將正確的指令寫入指向W2的通道。W2收到信號採取相應的措施。

原文來自:https://www.linuxprobe.com/nginx-service-architecture.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章