nginx架構分析

Nginx模塊化
#Nginx基于模塊化設計，每個模塊是一個功能實現，分布式開發，團隊協作
#核心模塊、標準HTTP模塊、可選HTTP模塊、郵件模塊、第三方模塊
#編譯后的源碼目錄objs/ngx_modules.c
#https://coding.net/u/aminglinux/p/nginx/git/blob/master/4z/module.md
Nginx的web請求機制
#并行處理：多進程、多線程、異步
#https://coding.net/u/aminglinux/p/nginx/git/blob/master/4z/IO.md
Nginx事件驅動模型
#https://coding.net/u/aminglinux/p/nginx/git/blob/master/4z/event.md
設計架構概覽
#Nginx基于模塊化設計、基于事件驅動模型處理請求、主進程和工作進程
#https://coding.net/u/aminglinux/p/nginx/git/blob/master/4z/jg.md

Nginx模塊化結構

Nginx涉及到的模塊分為核心模塊、標準HTTP模塊、可選HTTP模塊、郵件服務模塊以及第三方模塊等五大類。

核心模塊

核心模塊是指Nginx服務器正常運行時必不可少的模塊，它們提供了Nginx最基本最核心的服務，如進程管理、權限控制、錯誤日志記錄等。
主要包含對兩類功能的支持，一類是主體功能，包括進程管理、權限控制、錯誤日志記錄、配置解析等，
另一類是用于響應請求事件必需的功能，包括事件驅動機制、正則表達式解析等。

ngx_core_module
ngx_errlog_module
ngx_conf_module
ngx_regex_module
ngx_events_module
ngx_event_core_module
ngx_epoll_module

標準HTTP模塊

標準HTTP模塊是編譯Nginx后包含的模塊，其支持Nginx服務器的標準HTTP功能。

模塊 功能
ngx_http_core 配置端口，URI分析，服務器響應錯誤處理，別名控制以及其他HTTP核心事務
ngx_http_access_module 基于IP地址的訪問控制（允許/拒絕）
ngx_http_auth_basic_module 基于HTTP的身份認證
ngx_http_autoindex_module 處理以“/”結尾的請求并自動生成目錄列表
ngx_http_browser_module 解析HTTP請求頭中的“User-Agent”域的值
ngx_http_charset_module 指定網頁編碼
ngx_http_empty_gif_module 從內存創建一個1 x 1的透明gif圖片，可以快速調用
ngx_http_fastcgi_module 對FastCGI的支持
ngx_http_geo_module 將客戶端的IP轉化為鍵值對變量，該模塊主要用來針對客戶的的IP來定義變量
ngx_http_gzip_module 壓縮請求響應，可以減少數據傳輸
ngx_http_headers_filter_module 設置HTTP響應頭
ngx_http_index_module 處理以“/”結尾的請求，如果沒有找到該目錄下的index頁，就將請求轉給ngx_http_autoindex_module模塊處理
ngx_http_limit_req_module 限制來自客戶端的請求的響應和處理速率
ngx_http_limit_conn_module 限制來自客戶端的連接的響應和處理速率
ngx_http_log_module 自定義access日志
ngx_http_map_module 創建任意鍵值對變量
ngx_http_memcached_module 對Memcached的支持
ngx_http_proxy_module 支持代理事務
ngx_http_referer_module 對HTTP頭中的"referer"進行過濾處理，比如，實現防盜鏈功能
ngx_http_rewrite_module 實現nginx的rewrite功能
ngx_http_scgi_module 對SCGI的支持
ngx_http_upstream_module 定義一組服務器，可以接收來自代理、Fastcgi、Memcached的中重定向，主要用于負載均衡
可選HTTP模塊

可選HTTP模塊主要用于擴展標準的HTTP功能，使其能夠處理一些特殊的HTTP請求。在編譯Nginx時，如果不指定這些模塊，默認是不會安裝的。

模塊 功能
ngx_http_addition_module 在響應請求的頁面開始或者結尾添加文本信息
ngx_http_degradation_module 在低內存的情形下允許Nginx服務器返回444錯誤或204錯誤
ngx_http_perl_module 在Nginx的配置文件中可以使用Perl腳本
ngx_http_flv_module 支持將Flash多媒體信息按照流文件傳輸，可以根據客戶端指定的開始位置返回Flash
ngx_http_geoip_module 支持解析基于GeoIP數據庫的客戶端請求
ngx_google_perflools_module 支持Google Performance Tools的一套用于C++Profile的工具集
ngx_http_image_filter_module 支持將H.264/AAC編碼的多媒體信息（后綴名通常為mp4、m4v或m4a）按照流文件傳輸，常與ngx_http_flv_module模塊一起使用
ngx_http_random_index_module Nginx接收到以“/”結尾的請求時，在對應的目錄下隨機選擇一個文件作為index文件
ngx_http_secure_link_module 支持對請求鏈接的有效性檢查
ngx_http_ssl_module 對HTTPS/SSL支持
ngx_http_stub_status_module 支持返回Nginx服務器的統計信息，一般包括處理連接的數量、連接成功的數量、處理的請求數、讀取和返回的Header信息數等信息
ngx_http_sub_module 使用指定的字符串替換響應信息中的信息
ngx_http_dav_module 支持HTTP協議和WebDAV協議中PUT、DELETE、MKCOL、COPY和MOVE方法
ngx_http_xslt_module 將XML響應信息使用XSLT（拓展樣式表轉換語言）進行轉換
郵件服務模塊

主要用于支持Ningx的郵件服務。

第三方模塊

并非有Nginx官方提供，而是由第三方機構或者個人開發的模塊，用于實現某種特殊功能。
echo-nginx-module 支持在Nginx配置文件中使用echo、sleep、time以及exec等類shell命令
lua-nginx-module 使Nginx支持lua腳本語言

同步機制

同步、異步發生在當客戶端發起請求后，服務端處理客戶端的請求時。
同步機制，是指客戶端發送請求后，需要等待服務端（內核）返回信息后，再繼續發送下一個請求。
在同步機制中，所有的請求在服務器端得到同步，即發送方和接收方對請求的處理步調是一致的。

異步機制

異步機制，是指客戶端發出一個請求后，不等待服務端（內核）返回信息，就繼續發送下一個請求。
在異步機制中，所有來自發送方的請求形成一個隊列，接收方處理完后再通知發送方。

舉例：一家酒店前臺，在旺季的高峰時間段會接很多預定酒席的電話。
如果是同步機制情況下，前臺每接一個電話后先不掛掉電話，而是去查詢有無剩余酒席，查到結果后，告訴客戶。
如果是異步機制情況下，前臺每接一個預定電話直接回復客戶，一會回復，此時前臺把查詢這件事情交給了另外的同事，
該前臺掛掉電話后，繼續處理其他客戶的事情，當另外的同事查詢到結果后再通知給前臺，前臺再通知客戶。

阻塞

阻塞與非阻塞發生在IO調度中，比如內核到磁盤IO。
阻塞方式下，進程/線程在獲取最終結果之前，被系統掛起了，也就是所謂的阻塞了，在阻塞過程中該進程什么都干不了，
直到最終結果反饋給它時，它才恢復運行狀態。

非阻塞

非阻塞方式和阻塞相反，進程/線程在獲取最終結果之前，并沒有進入被掛起的狀態，而是該進程可以繼續執行新的任務。
當有最終結果反饋給該進程時，它再把結果交給客戶端。

舉例：依然是酒店前臺接待預定酒席電話的案例。
此時角色不再是前臺，而是她的查詢有無剩余酒席的同事。如果是阻塞方式，該同事在查詢有無剩余酒席的過程中，需要傻傻地
等待酒店管理系統給他返回結果，在此期間不能做其他事情。
如果是非阻塞，該同事在等待酒店管理系統給他返回結果這段時間，可以做其他事情，比如可以通知前臺剩余酒席的情況。

Nginx的請求機制

Nginx之所以可以支持高并發，是因為Nginx用的是異步非阻塞的機制，而Nginx是靠事件驅動模型來實現這種機制的。

在Nginx的事件驅動模型下，客戶端發起的所有請求在服務端都會被標記為一個事件，Nginx會把這些事件收集到“事件收集器”里，
然后再把這些事件交給內核去處理。

事件驅動模型

事件驅動模型是實現異步非阻塞的一個手段。事件驅動模型中，一個進程（線程）就可以了。

對于web服務器來說，客戶端A的請求連接到服務端時，服務端的某個進程（Nginx worker process）會處理該請求，
此進程在沒有返回給客戶端A結果時，它又去處理了客戶端B的請求。
服務端把客戶端A以及客戶端B發來的請求作為事件交給了“事件收集器”，
而“事件收集器”再把收集到的事件交由“事件發送器”發送給“事件處理器”進行處理。
最后“事件處理器”處理完該事件后，通知服務端進程，服務端進程再把結果返回給客戶端A、客戶端B。

在這個過程中，服務端進程做的事情屬于用戶級別的，而事件處理這部分工作屬于內核級別的。
也就是說這個事件驅動模型是需要操作系統內核來作為支撐的。

Nginx的事件驅動模型

Nginx的事件驅動模型，支持select、poll、epoll、rtsig、kqueue、/dev/poll、eventport等。
最常用的是前三種，其中kqueue模型用于支持BSD系列平臺的事件驅動模型。kqueue是poll模型的一個變種，本質上和epoll一樣。
/dev/poll是Unix平臺的事件驅動模型，其主要在Solaris7及以上版本、HP/UX11.22及以上版本、IRIX6.5.15及以上版本、
Tru64 Unix 5.1A及以上版本的平臺使用。
eventport是用于支持Solaris10及以上版本的事件驅動模型。

select模型

Linux和Windows都支持，使用select模型的步驟是：

1. 創建所關注事件的描述符集合，對于一個描述符，可以關注其上面的讀(Read)事件、寫(Write)事件以及異常發生(Exception)事件。
   在select模型中，要創建這3類事件描述符集合。

2. 調用底層提供的select()函數，等待事件發生。

3. 輪詢所有事件描述符集合中的每一個事件描述符，檢查是否有相應的事件發生，如果有就進行處理。

poll模型

poll模型是Linux平臺上的事件驅動模型，在Linux2.1.23中引入的，Windows平臺不支持該模型。

poll模型和select模型工作方式基本相同，區別在于，select模型創建了3個描述符集合，而poll模型只創建一個描述符集合。

epoll模型

epoll模型屬于poll模型的變種，在Linux2.5.44中引入。epoll比poll更加高效，原因在于它不需要輪詢整個描述符集合，
而是Linux內核會關注事件集合，當有變動時，內核會發來通知。

Nginx架構

Nginx服務器使用 master/worker 多進程模式。
主進程(Master process)啟動后，會接收和處理外部信號；
主進程啟動后通過fork() 函數產生一個或多個子進程(work process)，每個子進程會進行進程初始化、
模塊調用以及對事件的接收和處理等工作。

主進程

主要功能是和外界通信和對內部其他進程進行管理，具體來說有以下幾點：

• 讀取Nginx配置文件并驗證其有效性和正確性

• 建立、綁定和關閉socket

• 按照配置生成、管理工作進程

• 接收外界指令，比如重啟、關閉、重載服務等指令

• 日志文件管理

子進程（worker process)

是由主進程生成，生成數量可以在配置文件中定義。該進程主要工作有：

• 接收客戶端請求

• 將請求依次送入各個功能模塊進行過濾處理

• IO調用，獲取響應數據

• 與后端服務器通信，接收后端服務器處理結果

• 數據緩存，訪問緩存索引，查詢和調用緩存數據

• 發送請求結果，響應客戶端請求

• 接收主進程指令，如重啟、重載、退出等