1.7-1.9 Nginx架構分析
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腳本語言
Nginx的web請求機制
並行處理：多進程、多線程、異步
支持高併發方案：
開多個進程，每個進程處理相應的信息
開多個線程，線程是進程的一個子單元，線程比進程能節省更多的資源。
https://coding.net/u/aminglinux/p/nginx/git/blob/master/4z/IO.md
同步機制
同步、異步發生在當客戶端發起請求後，服務端處理客戶端的請求時。
同步機制，是指客戶端發送請求後，需要等待服務端（內核）返回信息後，再繼續發送下一個請求。
在同步機制中，所有的請求在服務器端得到同步，即發送方和接收方對請求的處理步調是一致的。
異步機制
異步機制，是指客戶端發出一個請求後，不等待服務端（內核）返回信息，就繼續發送下一個請求。
在異步機制中，所有來自發送方的請求形成一個隊列，接收方處理完後再通知發送方。
舉例：一家酒店前臺，在旺季的高峯時間段會接很多預定酒席的電話。
如果是同步機制情況下，前臺每接一個電話後先不掛掉電話，而是去查詢有無剩餘酒席，查到結果後，告訴客戶。
如果是異步機制情況下，前臺每接一個預定電話直接回復客戶，一會回覆，此時前臺把查詢這件事情交給了另外的同事，
該前臺掛掉電話後，繼續處理其他客戶的事情，當另外的同事查詢到結果後再通知給前臺，前臺再通知客戶。
阻塞
阻塞與非阻塞發生在IO調度中，比如內核到磁盤IO。
阻塞方式下，進程/線程在獲取最終結果之前，被系統掛起了，也就是所謂的阻塞了，在阻塞過程中該進程什麼都幹不了，
直到最終結果反饋給它時，它才恢復運行狀態。
非阻塞
非阻塞方式和阻塞相反，進程/線程在獲取最終結果之前，並沒有進入被掛起的狀態，而是該進程可以繼續執行新的任務。
當有最終結果反饋給該進程時，它再把結果交給客戶端。
舉例：依然是酒店前臺接待預定酒席電話的案例。
此時角色不再是前臺，而是她的查詢有無剩餘酒席的同事。如果是阻塞方式，該同事在查詢有無剩餘酒席的過程中，需要傻傻地
等待酒店管理系統給他返回結果，在此期間不能做其他事情。
如果是非阻塞，該同事在等待酒店管理系統給他返回結果這段時間，可以做其他事情，比如可以通知前臺剩餘酒席的情況。
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內核會關注事件集合，當有變動時，內核會發來通知。