回調函數?

前面剖析了memcached模塊的骨架，現在開始逐個解決每個回調函數。

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++) {

if ( * p == LF) {

goto found;

}

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

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

process_header的重要職責是將后端服務器返回的狀態翻譯成返回給客戶端的狀態。例如，在ngx_http_memcached_process_header中，有這樣幾段代碼：

r->headers_out.content_length_n = ngx_atoof(len, p - len - 1);

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將被作為返回給客戶端的響應返回狀態碼。而第一行則是設置返回給客戶端的響應的長度。

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

u->buffer.pos = p + 1;

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

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支持php解析,upstream模块的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。