目錄

• upstream模塊簡介
• upstream模塊接口
• memcached模塊分析
• 小結

upstream模塊簡介

• nginx模塊一般被分成三大類：handler、filter和upstream。前面的章節中，讀者已經了解了handler、filter。利用這兩類模塊，可以使nginx輕松完成任何單機工作。
• 而upstream模塊，將使nginx跨越單機的限制，完成網絡數據的接收、處理和轉發。
• 數據轉發功能，為nginx提供了跨越單機的橫向處理能力，使nginx擺脫只能為終端節點提供單一功能的限制，使它具備了網絡應用級別的拆分、封裝和整合的功能。
• 數據轉發是nginx有能力構建一個網絡應用的關鍵組件。當然，鑒于開發成本的問題，一個網絡應用的關鍵組件一開始往往會采用高級編程語言開發。但是當系統到達一定規模，并且需要更重視性能的時候，為了達到所要求的性能目標，高級語言開發出的組件必須進行結構化修改。

此時，對于修改代價而言，nginx的upstream模塊體現出了它的優勢，因為它天生就快。作為附帶，nginx的配置系統提供的層次化和松耦合使得系統的擴展性也達到比較高的程度。

upstream模塊接口

從本質上說，upstream屬于handler，只是他不產生自己的內容，而是通過請求后端服務器得到內容，所以才稱為upstream（上游）。請求并取得響應內容的整個過程已經被封裝到nginx內部，所以upstream模塊只需要開發若干回調函數，完成構造請求和解析響應等具體的工作。

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 直接返回

memcached模塊分析

• memcache是一款高性能的分布式cache系統，得到了非常廣泛的應用。memcache定義了一套私有通信協議，使得不能通過HTTP請求來訪問memcache。但協議本身簡單高效，而且memcache使用廣泛，所以大部分現代開發語言和平臺都提供了memcache支持，方便開發者使用memcache。
• nginx提供了ngx_http_memcached模塊，提供從memcache讀取數據的功能，而不提供向memcache寫數據的功能。

upstream模塊使用的就是handler模塊的接入方式。

同時，upstream模塊的指令系統的設計也是遵循handler模塊的基本規則：配置該模塊才會執行該模塊。

那么，upstream模塊的特別之處究竟在哪里呢？那就是upstream模塊的處理函數，upstream模塊的處理函數進行的操作都包含一個固定的流程：（以memcached模塊舉例，在memcached的處理函數ngx_http_memcached_handler中）

創建upstream數據結構：

ngx_http_upstream_t    *u;
if (ngx_http_upstream_create(r) != NGX_OK) {
    return NGX_HTTP_INTERNAL_SERVER_ERROR;
}
u = r->upstream;

設置模塊的tag和schema。schema現在只會用于日志，tag會用于buf_chain管理：

ngx_str_set(&u->schema, "memcached://");
u->output.tag = (ngx_buf_tag_t) &ngx_http_memcached_module;

設置upstream的后端服務器列表數據結構：

mlcf = ngx_http_get_module_loc_conf(r, ngx_http_memcached_module);
u->conf = &mlcf->upstream;

設置upstream回調函數：

u->create_request = ngx_http_memcached_create_request;
u->reinit_request = ngx_http_memcached_reinit_request;
u->process_header = ngx_http_memcached_process_header;
u->abort_request = ngx_http_memcached_abort_request;
u->finalize_request = ngx_http_memcached_finalize_request;
   
u->input_filter_init = ngx_http_memcached_filter_init;
u->input_filter = ngx_http_memcached_filter;

創建并設置upstream環境數據結構：

ctx = ngx_palloc(r->pool, sizeof(ngx_http_memcached_ctx_t));
if (ctx == NULL) {
? ? return NGX_HTTP_INTERNAL_SERVER_ERROR;
}
ctx->request = r;

ngx_http_set_ctx(r, ctx, ngx_http_memcached_module);

u->input_filter_ctx = ctx;

完成upstream初始化并進行收尾工作：

r->main->count++;
ngx_http_upstream_init(r);
return NGX_DONE;

任何upstream模塊，簡單如memcached，復雜如proxy、fastcgi都是如此。
不同的upstream模塊在這6步中的最大差別會出現在第2、3、4、5上。

其中第2、4兩步很容易理解，不同的模塊設置的標志和使用的回調函數肯定不同。第5步也不難理解。

只有第3步是有點費解的，不同的模塊在取得后端服務器列表時，策略的差異非常大，有如memcached這樣簡單明了的，也有如proxy那樣邏輯復雜的。

第6步不同模塊之間通常是一致的。將count加1，然后返回NGX_DONE。
nginx遇到這種情況，雖然會認為當前請求的處理已經結束，但是不會釋放請求使用的內存資源，也不會關閉與客戶端的連接。
之所以需要這樣，是因為nginx建立了upstream請求和客戶端請求之間一對一的關系，在后續使用ngx_event_pipe將upstream響應發送回客戶端時，還要使用到這些保存著客戶端信息的數據結構。
將upstream請求和客戶端請求進行一對一綁定，這個設計有優勢也有缺陷。優勢就是簡化模塊開發，可以將精力集中在模塊邏輯上，而缺陷同樣明顯，一對一的設計很多時候都不能滿足復雜邏輯的需要。

回調函數：(依然是以memcached模塊的處理函數為例)

• ngx_http_memcached_create_request：很簡單的按照設置的內容生成一個key，接著生成一個“get $key”的請求，放在r->upstream->request_bufs里面。
• ngx_http_memcached_reinit_request：無需初始化。
• ngx_http_memcached_abort_request：無需額外操作。
• ngx_http_memcached_finalize_request：無需額外操作。
• ngx_http_memcached_process_header：模塊的業務重點函數。memcache協議的頭部信息被定義為第一行文本，代碼如下：

#define LF     (u_char) "\n"
for (p = u->buffer.pos; p < u->buffer.last; p++) {
    if (*p == LF) {
goto found;
    }
}

如果在已讀入緩沖的數據中沒有發現LF(‘\n’)字符，函數返回NGX_AGAIN，表示頭部未完全讀入，需要繼續讀取數據。nginx在收到新的數據以后會再次調用該函數。

nginx處理后端服務器的響應頭時只會使用一塊緩存，所有數據都在這塊緩存中，所以解析頭部信息時不需要考慮頭部信息跨越多塊緩存的情況。而如果頭部過大，不能保存在這塊緩存中，nginx會返回錯誤信息給客戶端，并記錄error log，提示緩存不夠大。

ngx_http_memcached_process_header的重要職責是將后端服務器返回的狀態翻譯成返回給客戶端的狀態。例如：

u->headers_in.content_length_n = ngx_atoof(start, p - start);
···
u->headers_in.status_n = 200;
u->state->status = 200;
···
u->headers_in.status_n = 404;
u->state->status = 404;

u->state用于計算upstream相關的變量。比如u->state->status將被用于計算變量“upstream_status”的值。u->headers_in將被作為返回給客戶端的響應返回狀態碼。而u->headers_in.content_length_n則是設置返回給客戶端的響應的長度。

在這個函數中一定要在處理完頭部信息以后需要將讀指針pos后移，否則這段數據也將被復制到返回給客戶端的響應的正文中，進而導致正文內容不正確。

ngx_http_memcached_process_header函數完成響應頭的正確處理，應該返回NGX_OK。如果返回NGX_AGAIN，表示未讀取完整數據，需要從后端服務器繼續讀取數據。返回NGX_DECLINED無意義，其他任何返回值都被認為是出錯狀態，nginx將結束upstream請求并返回錯誤信息。

ngx_http_memcached_filter_init：修正從后端服務器收到的內容長度。因為在處理header時沒有加上這部分長度。

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高效的原因之一。

小結

• 以上就是upstream模塊的基本組成。upstream模塊是從handler模塊發展而來，指令系統和模塊生效方式與handler模塊無異。
• 不同之處在于，upstream模塊在handler函數中設置眾多回調函數。實際工作都是由這些回調函數完成的。
• 每個回調函數都是在upstream的某個固定階段執行，各司其職，大部分回調函數一般不會真正用到。
• upstream最重要的回調函數是ngx_http_upstream_t->create_request、ngx_http_upstream_t->process_header和ngx_http_upstream_t->input_filter，他們共同實現了與后端服務器的協議的解析部分。

到此這篇關于Nginx中upstream模塊的具體用法的文章就介紹到這了,更多相關Nginx upstream模塊內容請搜索以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持！