目錄

• upstream模塊簡(jiǎn)介
• upstream模塊接口
• memcached模塊分析
• 小結(jié)

upstream模塊簡(jiǎn)介

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

此時(shí)，對(duì)于修改代價(jià)而言，nginx的upstream模塊體現(xiàn)出了它的優(yōu)勢(shì)，因?yàn)樗焐涂臁Ｗ鳛楦綆В琻ginx的配置系統(tǒng)提供的層次化和松耦合使得系統(tǒng)的擴(kuò)展性也達(dá)到比較高的程度。

upstream模塊接口

從本質(zhì)上說(shuō)，upstream屬于handler，只是他不產(chǎn)生自己的內(nèi)容，而是通過(guò)請(qǐng)求后端服務(wù)器得到內(nèi)容，所以才稱(chēng)為upstream（上游）。請(qǐng)求并取得響應(yīng)內(nèi)容的整個(gè)過(guò)程已經(jīng)被封裝到nginx內(nèi)部，所以u(píng)pstream模塊只需要開(kāi)發(fā)若干回調(diào)函數(shù)，完成構(gòu)造請(qǐng)求和解析響應(yīng)等具體的工作。

upstream模塊回調(diào)函數(shù)列舉如下：

函數(shù)名稱(chēng)描述create_request生成發(fā)送到后端服務(wù)器的請(qǐng)求緩沖（緩沖鏈），在初始化upstream 時(shí)使用reinit_request在某臺(tái)后端服務(wù)器出錯(cuò)的情況，nginx會(huì)嘗試另一臺(tái)后端服務(wù)器。 nginx選定新的服務(wù)器以后，會(huì)先調(diào)用此函數(shù)，以重新初始化 upstream模塊的工作狀態(tài)，然后再次進(jìn)行upstream連接process_header處理后端服務(wù)器返回的信息頭部。所謂頭部是與upstream server 通信的協(xié)議規(guī)定的，比如HTTP協(xié)議的header部分，或者memcached 協(xié)議的響應(yīng)狀態(tài)部分abort_request在客戶(hù)端放棄請(qǐng)求時(shí)被調(diào)用。不需要在函數(shù)中實(shí)現(xiàn)關(guān)閉后端服務(wù) 器連接的功能，系統(tǒng)會(huì)自動(dòng)完成關(guān)閉連接的步驟，所以一般此函 數(shù)不會(huì)進(jìn)行任何具體工作finalize_request正常完成與后端服務(wù)器的請(qǐng)求后調(diào)用該函數(shù)，與abort_request 相同，一般也不會(huì)進(jìn)行任何具體工作input_filter處理后端服務(wù)器返回的響應(yīng)正文。nginx默認(rèn)的input_filter會(huì) 將收到的內(nèi)容封裝成為緩沖區(qū)鏈ngx_chain。該鏈由upstream的 out_bufs指針域定位，所以開(kāi)發(fā)人員可以在模塊以外通過(guò)該指針得到后端服務(wù)器返回的正文數(shù)據(jù)。memcached模塊實(shí)現(xiàn)了自己的 input_filter，在后面會(huì)具體分析這個(gè)模塊。input_filter_init初始化input filter的上下文。nginx默認(rèn)的input_filter_init 直接返回

memcached模塊分析

• memcache是一款高性能的分布式cache系統(tǒng)，得到了非常廣泛的應(yīng)用。memcache定義了一套私有通信協(xié)議，使得不能通過(guò)HTTP請(qǐng)求來(lái)訪(fǎng)問(wèn)memcache。但協(xié)議本身簡(jiǎn)單高效，而且memcache使用廣泛，所以大部分現(xiàn)代開(kāi)發(fā)語(yǔ)言和平臺(tái)都提供了memcache支持，方便開(kāi)發(fā)者使用memcache。
• nginx提供了ngx_http_memcached模塊，提供從memcache讀取數(shù)據(jù)的功能，而不提供向memcache寫(xiě)數(shù)據(jù)的功能。

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

同時(shí)，upstream模塊的指令系統(tǒng)的設(shè)計(jì)也是遵循h(huán)andler模塊的基本規(guī)則：配置該模塊才會(huì)執(zhí)行該模塊。

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

創(chuàng)建upstream數(shù)據(jù)結(jié)構(gòu)：

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

設(shè)置模塊的tag和schema。schema現(xiàn)在只會(huì)用于日志，tag會(huì)用于buf_chain管理：

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

設(shè)置upstream的后端服務(wù)器列表數(shù)據(jù)結(jié)構(gòu)：

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

設(shè)置upstream回調(diào)函數(shù)：

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;

創(chuàng)建并設(shè)置upstream環(huán)境數(shù)據(jù)結(jié)構(gòu)：

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初始化并進(jìn)行收尾工作：

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

任何upstream模塊，簡(jiǎn)單如memcached，復(fù)雜如proxy、fastcgi都是如此。
不同的upstream模塊在這6步中的最大差別會(huì)出現(xiàn)在第2、3、4、5上。

其中第2、4兩步很容易理解，不同的模塊設(shè)置的標(biāo)志和使用的回調(diào)函數(shù)肯定不同。第5步也不難理解。

只有第3步是有點(diǎn)費(fèi)解的，不同的模塊在取得后端服務(wù)器列表時(shí)，策略的差異非常大，有如memcached這樣簡(jiǎn)單明了的，也有如proxy那樣邏輯復(fù)雜的。

第6步不同模塊之間通常是一致的。將count加1，然后返回NGX_DONE。
nginx遇到這種情況，雖然會(huì)認(rèn)為當(dāng)前請(qǐng)求的處理已經(jīng)結(jié)束，但是不會(huì)釋放請(qǐng)求使用的內(nèi)存資源，也不會(huì)關(guān)閉與客戶(hù)端的連接。
之所以需要這樣，是因?yàn)閚ginx建立了upstream請(qǐng)求和客戶(hù)端請(qǐng)求之間一對(duì)一的關(guān)系，在后續(xù)使用ngx_event_pipe將upstream響應(yīng)發(fā)送回客戶(hù)端時(shí)，還要使用到這些保存著客戶(hù)端信息的數(shù)據(jù)結(jié)構(gòu)。
將upstream請(qǐng)求和客戶(hù)端請(qǐng)求進(jìn)行一對(duì)一綁定，這個(gè)設(shè)計(jì)有優(yōu)勢(shì)也有缺陷。優(yōu)勢(shì)就是簡(jiǎn)化模塊開(kāi)發(fā)，可以將精力集中在模塊邏輯上，而缺陷同樣明顯，一對(duì)一的設(shè)計(jì)很多時(shí)候都不能滿(mǎn)足復(fù)雜邏輯的需要。

回調(diào)函數(shù)：(依然是以memcached模塊的處理函數(shù)為例)

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

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

如果在已讀入緩沖的數(shù)據(jù)中沒(méi)有發(fā)現(xiàn)LF(‘\n’)字符，函數(shù)返回NGX_AGAIN，表示頭部未完全讀入，需要繼續(xù)讀取數(shù)據(jù)。nginx在收到新的數(shù)據(jù)以后會(huì)再次調(diào)用該函數(shù)。

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

ngx_http_memcached_process_header的重要職責(zé)是將后端服務(wù)器返回的狀態(tài)翻譯成返回給客戶(hù)端的狀態(tài)。例如：

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用于計(jì)算upstream相關(guān)的變量。比如u->state->status將被用于計(jì)算變量“upstream_status”的值。u->headers_in將被作為返回給客戶(hù)端的響應(yīng)返回狀態(tài)碼。而u->headers_in.content_length_n則是設(shè)置返回給客戶(hù)端的響應(yīng)的長(zhǎng)度。

在這個(gè)函數(shù)中一定要在處理完頭部信息以后需要將讀指針pos后移，否則這段數(shù)據(jù)也將被復(fù)制到返回給客戶(hù)端的響應(yīng)的正文中，進(jìn)而導(dǎo)致正文內(nèi)容不正確。

ngx_http_memcached_process_header函數(shù)完成響應(yīng)頭的正確處理，應(yīng)該返回NGX_OK。如果返回NGX_AGAIN，表示未讀取完整數(shù)據(jù)，需要從后端服務(wù)器繼續(xù)讀取數(shù)據(jù)。返回NGX_DECLINED無(wú)意義，其他任何返回值都被認(rèn)為是出錯(cuò)狀態(tài)，nginx將結(jié)束upstream請(qǐng)求并返回錯(cuò)誤信息。

ngx_http_memcached_filter_init：修正從后端服務(wù)器收到的內(nèi)容長(zhǎng)度。因?yàn)樵谔幚韍eader時(shí)沒(méi)有加上這部分長(zhǎng)度。

ngx_http_memcached_filter：
memcached模塊是少有的帶有處理正文的回調(diào)函數(shù)的模塊。
因?yàn)閙emcached模塊需要過(guò)濾正文末尾CRLF “END” CRLF，所以實(shí)現(xiàn)了自己的filter回調(diào)函數(shù)。

處理正文的實(shí)際意義是將從后端服務(wù)器收到的正文有效內(nèi)容封裝成ngx_chain_t，并加在u->out_bufs末尾。

nginx并不進(jìn)行數(shù)據(jù)拷貝，而是建立ngx_buf_t數(shù)據(jù)結(jié)構(gòu)指向這些數(shù)據(jù)內(nèi)存區(qū)，然后由ngx_chain_t組織這些buf。這種實(shí)現(xiàn)避免了內(nèi)存大量搬遷，也是nginx高效的原因之一。

小結(jié)

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

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