Nginx實戰 1.7-1.11 Nginx架構分析，虛擬機器配置
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核心會關注事件集合，當有變動時，核心會發來通知。