filter模組相對容易理解，省略不記了。
nginx模組一般被分成三大類：handler、filter和upstream，upstream模組，將使nginx跨越單機的限制，完成網路資料的接收、處理和**。
資料**功能，為nginx提供了跨越單機的橫向處理能力，使nginx擺脫只能為終端節點提供單一功能的限制，而使它具備了網路應用級別的拆分、封裝和整合的戰略功能。在雲模型大行其道的今天，資料**是nginx有能力構建乙個網路應用的關鍵元件。當然，鑑於開發成本的問題，乙個網路應用的關鍵元件一開始往往會採用高階程式語言開發。但是當系統到達一定規模，並且需要更重視效能的時候，為了達到所要求的效能目標，高階語言開發出的元件必須進行結構化修改。此時，對於修改代價而言，nginx的upstream模組呈現出極大的吸引力，因為它天生就快。作為附帶，nginx的配置系統提供的層次化和松耦合使得系統的擴充套件性也達到比較高的程度。
從本質上說，upstream屬於handler，只是他不產生自己的內容，而是通過請求後端伺服器得到內容，所以才稱為upstream（上游）。請求並取得響應內容的整個過程已經被封裝到nginx內部，所以upstream模組只需要開發若干**函式，完成構造請求和解析響應等具體的工作。
這些**函式如下表所示：
create_request
生成傳送到後端伺服器的請求緩衝（緩衝鏈），在初始化upstream 時使用。
reinit_request
在某台後端伺服器出錯的情況，nginx會嘗試另一台後端伺服器。 nginx選定新的伺服器以後，會先呼叫此函式，以重新初始化 upstream模組的工作狀態，然後再次進行upstream連線。
process_header
處理後端伺服器返回的資訊頭部。所謂頭部是與upstream server 通訊的協議規定的，比如http協議的header部分，或者memcached 協議的響應狀態部分。
abort_request
在客戶端放棄請求時被呼叫。不需要在函式中實現關閉後端服務 器連線的功能，系統會自動完成關閉連線的步驟，所以一般此函 數不會進行任何具體工作。
finalize_request
正常完成與後端伺服器的請求後呼叫該函式，與abort_request 相同，一般也不會進行任何具體工作。
input_filter
處理後端伺服器返回的響應正文。nginx預設的input_filter會 將收到的內容封裝成為緩衝區鏈ngx_chain。該鏈由upstream的 out_bufs指標域定位，所以開發人員可以在模組以外通過該指標 得到後端伺服器返回的正文資料。memcached模組實現了自己的 input_filter，在後面會具體分析這個模組。
input_filter_init
初始化input filter的上下文。nginx預設的input_filter_init 直接返回。
memcache是一款高效能的分布式cache系統，得到了非常廣泛的應用。memcache定義了一套私有通訊協議，使得不能通過http請求來訪問memcache。但協議本身簡單高效，而且memcache使用廣泛，所以大部分現代開發語言和平台都提供了memcache支援，方便開發者使用memcache。
nginx提供了ngx_http_memcached模組，提供從memcache讀取資料的功能，而不提供向memcache寫資料的功能。作為web伺服器，這種設計是可以接受的。
memcache是一款高效能的分布式cache系統，得到了非常廣泛的應用。memcache定義了一套私有通訊協議，使得不能通過http請求來訪問memcache。但協議本身簡單高效，而且memcache使用廣泛，所以大部分現代開發語言和平台都提供了memcache支援，方便開發者使用memcache。
nginx提供了ngx_http_memcached模組，提供從memcache讀取資料的功能，而不提供向memcache寫資料的功能。作為web伺服器，這種設計是可以接受的。
upstream模組使用的就是handler模組的接入方式。同時，upstream模組的指令系統的設計也是遵循handler模組的基本規則：配置該模組才會執行該模組。
upstream模組的處理函式進行的操作都包含乙個固定的流程。在memcached的例子中，可以觀察ngx_http_memcached_handler的**，可以發現，這個固定的操作流程是：
1. 建立upstream資料結構。
2. 設定模組的tag和schema。schema現在只會用於日誌，tag會用於buf_chain管理。
3. 設定upstream的後端伺服器列表資料結構。
4. 設定upstream**函式。
5. 建立並設定upstream環境資料結構。
6. 完成upstream初始化並進行收尾工作。
任何upstream模組，簡單如memcached，複雜如proxy、fastcgi都是如此。不同的upstream模組在這6步中的最大差別會出現在第2、3、4、5上。其中第2、4兩步很容易理解，不同的模組設定的標誌和使用的**函式肯定不同。第5步也不難理解，只有第3步是最為晦澀的，不同的模組在取得後端伺服器列表時，策略的差異非常大，有如memcached這樣簡單明瞭的，也有如proxy那樣邏輯複雜的。這個問題先記下來，等把memcached剖析清楚了，再單獨討論。
第6步是乙個常態。將count加1，然後返回ngx_done。nginx遇到這種情況，雖然會認為當前請求的處理已經結束，但是不會釋放請求使用的記憶體資源，也不會關閉與客戶端的連線。之所以需要這樣，是因為nginx建立了upstream請求和客戶端請求之間一對一的關係，在後續使用ngx_event_pipe將upstream響應傳送回客戶端時，還要使用到這些儲存著客戶端資訊的資料結構。
**函式
1. ngx_http_memcached_create_request：很簡單的按照設定的內容生成乙個key，接著生成乙個「get $key」的請求，放在r->upstream->request_bufs裡面。
2. ngx_http_memcached_reinit_request：無需初始化。
3. ngx_http_memcached_abort_request：無需額外操作。
4. ngx_http_memcached_finalize_request：無需額外操作。
5. ngx_http_memcached_process_header：模組的業務重點函式。memcache協議的頭部資訊被定義為第一行文字，可以找到這段**證明：
for (p = u->buffer.pos; p < u->buffer.last; p++)
如果在已讀入緩衝的資料中沒有發現lf(『n』)字元，函式返回ngx_again，表示頭部未完全讀入，需要繼續讀取資料。nginx在收到新的資料以後會再次呼叫該函式。
nginx處理後端伺服器的響應頭時只會使用一塊快取，所有資料都在這塊快取中，所以解析頭部資訊時不需要考慮頭部資訊跨越多塊快取的情況。而如果頭部過大，不能儲存在這塊快取中，nginx會返回錯誤資訊給客戶端，並記錄error log，提示快取不夠大。
6. ngx_http_memcached_filter_init：修正從後端伺服器收到的內容長度。因為在處理header時沒有加上這部分長度。
7. ngx_http_memcached_filter：memcached模組是少有的帶有處理正文的**函式的模組。因為memcached模組需要過濾正文末尾crlf 「end」 crlf，所以實現了自己的filter**函式。處理正文的實際意義是將從後端伺服器收到的正文有效內容封裝成ngx_chain_t，並加在u->out_bufs末尾。nginx並不進行資料拷貝，而是建立ngx_buf_t資料結構指向這些資料記憶體區，然後由ngx_chain_t組織這些buf。這種實現避免了記憶體大量搬遷，也是nginx高效的奧秘之一。
Nginx安裝學習筆記（CentOS7）
可以把這個位址配置為yum源，利用yum安裝。安裝依賴包 yum install y pcre devel zlib devel openssl devel 建立使用者，沒有建立nginx 使用者情況下，worker預設使用nobody使用者，master程序為root。useradd nginx ...
Nginx 學習筆記
nginx配置proxy pass 的 路徑問題 在nginx中配置proxy pass時，如果是按照 匹配路徑時,要注意proxy pass後的url最後的 當加上了 相當於是絕對根路徑，則nginx不會把location中匹配的路徑部分 走 如果沒有 則會把匹配的路徑部分也給 走。locatio...
Nginx學習筆記
常用命令 啟動 start nginx 或者 nginx.exe 停止 nginx.exe s stop 或者 nginx.exe s quit stop是快速停止nginx，quit是完整有序的停止nginx 重啟 nginx.exe s reload 配置資訊修改使用此命令 配置 1 匹配以ro...