一、nginx執行步驟

nginx在處理每一個用戶請求時，都是按照若干個不同的階段依次處理的，與配置文件上的順序沒有關系，詳細內容可以閱讀《深入理解nginx:模塊開發與架構解析》這本書，這里只做簡單介紹;

1、post-read

? ? 讀取請求內容階段，nginx讀取并解析完請求頭之后就立即開始運行;

? ? 例如模塊ngx_realip就在post-read階段注冊了處理程序，它的功能是迫使Nginx認為當前請求的來源地址是指定的某一個請求頭的值。

2、server-rewrite

? ? server塊中請求地址重寫階段;

? ? 當ngx_rewrite模塊的rewrite、set配置指令直接書寫在server配置塊中時，基本上都是運行在server-rewrite階段

3、find-config

? ? 配置查找階段，用來完成當前請求與location配重塊之間的配對工作;

? ? 這個階段并不支持Nginx模塊注冊處理程序，而是由Nginx核心來完成當前請求與location配置塊之間的配對工作。

4.rewrite

? ? location塊中請求地址重寫階段，當ngx_rewrite模塊的rewrite指令用于location中，就是在這個階段運行的;

? ? 另外，ngx_set_misc(設置md5、encode_base64等)模塊的指令，還有ngx_lua模塊的set_by_lua指令和rewrite_by_lua指令也在此階段。

5、post-rewrite

? ? 請求階段重寫提交階段，由Nginx核心完成rewrite階段所要求的的"內部跳轉"操作，如果rewrite階段有此要求的話。

6、preaccess

? ? 訪問權限檢查準備階段，標準模塊ngx_limit_req和ngx_limit_zone就運行在此階段，前者可以控制請求的訪問頻度，而后者可以限制訪問的并發度。

7、access

? ? 訪問權限檢查階段，標準模塊ngx_access、第三方模塊ngx_auth_request以及第三方模塊ngx_lua的access_by_lua指令就運行在這個階段。配置指令多是執行訪問控制性質的任務，比如檢查用戶的訪問權限，檢查用戶的來源IP地址是否合法。

8、post-access

? ? 訪問權限檢查提交階段;

? ? 主要用于配合access階段實現標準ngx_http_core模塊提供的配置指令satisfy的功能。

? ? satisfy all(與關系)

? ? satisfy any(或關系)

9、try-files

? ? 配置型try_files處理階段;

? ? 專門用于實現標準配置指令try_files的功能 如果前N-1個參數所對應的文件系統對象都不存在，try-files階段就會立即發起“內部跳轉”到最后一個參數(即第N個參數)所指定的URI.

10、content

? ? 內容產生階段，是所有請求處理階段中最為重要的階段，因為這個階段的指令通常是用來生成HTTP響應內容的;

? ? Nginx的content階段是所有請求處理階段中最為重要的一個，因為運行在這個階段的配置指令一般都肩負著生成"內容"并輸出HTTP相應的使命。

11、log

? ? 日志模塊處理階段;

? ? 記錄日志。

二、Nginx下Lua處理階段

init_by_lua http set_by_lua server, server if, location, location if rewrite_by_lua http, server, location, location if access_by_lua http, server, location, location if content_by_lua location, location if header_filter_by_lua http, server, location, location if body_filter_by_lua http, server, location, location if log_by_lua http, server, location, location if

三、ngx_lua運行指令

ngx_lua屬于nginx的一部分，它的執行指令都包含在nginx的11個步驟之中了，不過ngx_lua并不是所有階段都會運行的;

? ? 1.init_by_lua、init_by_lua_file

語法:init_by_lua <lua-script-str>

語境:http

階段:loading-config

當nginx master進程在加載nginx配置文件時運行指定的lua腳本，通常用來注冊lua的全局變量或在服務器啟動時預加載lua模塊。例如lua_shared_dict共享內存的申請，只有當nginx重啟后，共享內存數據才清空，這常用于統計。

init_by_lua 'cjson = require "cjson"';server {location = /api {content_by_lua 'ngx.say(cjson.encode({dog = 5, cat = 6}))'} }

或者初始化lua_shared_dict共享數據:

lua_shared_dict dogs 1m; init_by_lua 'local dogs = ngx.shared.dogs;dogs:set("Tom", 50) ' server {location = /api {content_by_lua 'local dogs = ngx.shared.dogs;ngx.say(dogs:get("Tom"))'} }

但是，lua_shared_dict的內容不會在nginx reload時被清除。所以如果你不想在你的init_by_lua中重新初始化共享數據，那么你需要在你的共享內存中設置一個標志位并在init_by_lua中進行檢查。

因為這個階段的lua代碼是在nginx forks出任何worker進程之前運行，數據和代碼的加載將享受由操作系統提供的copy-on-write的特性，從而節約了大量的內存。不要在這個階段初始化的你的私有lua全局變量，因為使用lua全局變量會造成性能損失，并且可能導致全局命名空間被污染。

這個階段只支持一些小的LUA Nginx API設置: ngx.log和print、ngx.shared.DICT;

2.init_worker_by_lua、init_worker_by_lua_file

語法:init_worker_by_lua <lua-script-str>

語境:http

階段:starting-worker

在每個nginx worker進程啟動時調用指定的lua代碼。如果master進程不允許，則只會在init_by_lua之后調用。

這個hook通常用來創建每個工作進程的計時器(通過lua的ngx.timer API),進行后端健康檢查或者其他日常工作:

init_worker_by_lua:local delay = 3 -- in secondslocal new_timer = ngx.timer.atlocal log = ngx.loglocal ERR = ngx.ERRlocal checkcheck = function(premature)if not premature then-- do the health check other routine worklocal ok, err = new_timer(delay, check)if not ok thenlog(ERR, "failed to create timer: ", err)returnendendendlocal ok, err = new_timer(delay, check)if not ok thenlog(ERR, "failed to create timer: ", err)end

3、set_by_lua、set_by_lua_file

語法:set_by_lua $res <lua-script-str> [$arg1 $arg2 ...]

語境: server、server if、location、 location if

階段: rewrite

設置一個變量，常用于計算一個邏輯，然后返回結果 該階段不能運行Output API 、Control API、Subrequest API、Cosocket API.

傳入參數到指定的lua腳本代碼中執行，并得到返回值到res中。<lua-script-str>中的代碼可以使從ngx.arg表中取得輸入參數(順序索引從1開始).

這個指令是為了執行短期、快速執行的代碼因為運行過程中nginx的事件處理循環是處于阻塞狀態的。耗費時間的代碼應該被避免。

禁止在這個階段使用下面的API:1、output api(ngx.say和ngx.send_headers); 2、control api(ngx.exit); 3、subrequest api(ngx.location.capture和ngx.location.capture_multi);4、cosocket api(ngx.socket.tcp和ngx.req.socket);5、sleep api(ngx.sleep)

此外注意，這個指令只能一次寫出一個nginx變量，但是使用ngx.var接口可以解決這個問題:

location /foo {set $diff '';set_by_lua $num 'local a = 32local b = 56ngx.var.diff = a - b; -- 寫入$diff中return a + b; --返回到$sum中'echo "sum = $sum, diff = $diff"; }

這個指令可以自由的使用HttpRewriteModule、HttpSetMiscModule和HttpArrayVarModule所有的方法。所有的這些指令都將按他們出現在配置文件中的順序進行執行。

4、rewrite_by_lua、rewrite_by_lua_file

語法:rewrite_by_lua <lua-script-str>

語境:http、server、location、location if

階段:rewrite tail

作為rewrite階段的處理，為每個請求執行指定的lua代碼。注意這個處理是在標準HttpRewriteModule之后進行的:

location /foo {set $a 12;set $b "";rewrite_by_lua 'ngx.var.b = tonumber(ngx.var.a) + 1';echo "res = $b"; }

如果這樣的話將不會按預期進行工作:

location /foo {set $a 12;set $b '';rewrite_by_lua 'ngx.var.b = tonumber(ngx.var.a) + 1';if ($b = '13') {rewrite ^ /bar redirect;break;}echo "res = $b" }

因為if會在rewrite_by_lua之前運行，所以判斷將不成立。正確的寫法應該是這樣:

location /foo {set $a 12;set $b '';rewrite_by_lua 'ngx.var.b = tonumber(ngx.var.a) + 1if tonumber(ngx.var.b) == 13 thenreturn ngx.redirect("/bar");end'echo "res = $b"; }

注意ngx_eval模塊可以近似于使用rewrite_by_lua,例如:

location / {eval $res {proxy_pass http://foo,com/check-spam;}if ($res = 'spam') {rewrite ^ /terms-of-use.html redirect;}fastcgi_pass ...... }

可以被ngx_lua這樣實現:

location = /check-spam {internal;proxy_pass http://foo.com/check-spam; } location / {rewrite_by_lua 'local res = ngx.location.capture("/check-spam")if res.body == "spam" thenreturn ngx.redirect("terms-of-use.html")'fastcgi_pass ...... }

和其他的rewrite階段的處理程序一樣，rewrite_by_lua在subrequests中一樣可以運行。

請注意在rewrite_by_lua內調用ngx.exit(ngx.OK),nginx的請求處理流程將繼續進行content階段的處理。從rewrite_by_lua終止當前的請求，要調用ngx.exit返回status大于200并小于300的成功狀態或

ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)的失敗狀態。

如果HttpRewriteModule的重寫指令被用來改寫URI和重定向，那么任何rewrite_by_lua和rewrite_by_lua_file的代碼將不會執行，例如:

location /foo {rewrite ^ /bar;rewrite_by_lua 'ngx.exit(503)' } location /bar {...... }

在這個例子中ngx.exit(503)將永遠不會被執行，因為rewrite修改了location,請求已經跳入其它location中了。

5、access_by_lua,access_by_lua_file

語法:access_by_lua <lua-script-str>

語境:http, server, location, location if

階段:access tail

為每一個請求在訪問階段的調用lua腳本進行處理。主要用于訪問控制，能收集到大部分的變量。這條指令運行于nginx access階段的末尾，因此總是在allow和deny這樣的指令之后運行，雖然它們同屬access階段。

注意access_by_lua和rewrite_by_lua類似是在標準HttpAccessModule之后才會運行，看一個例子:

location / {deny 192.168.1.1;allow 192.168.1.0/24;allow 10.1.1.0/16;deny all;access_by_lua 'local res = ngx.location.capture("/mysql", {...})....' }

如果client ip在黑名單之內，那么這次連接會在進入access_by_lua調用的mysql之前被丟棄掉。

ngx_auth_request模塊和access_by_lua的用法類似:

location / {auth_request /auth; }

可以用ngx_lua實現:

location / {access_by_lua 'local res = ngx.location.capture("/auth")if res.status == ngx.HTTP_OK thenreturnendif res.status == ngx.HTTP_FORBIDDEN thenngx.exit(res.status)endngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)' }

和其他access階段的模塊一樣，access_by_lua不會在subrequest中運行。請注意在access_by_lua內調用ngx.exit(ngx.OK),nginx的請求處理流程將繼續進行后面階段的處理。從rewrite_by_lua終止當前的請求，要調用ngx.exit返回status大于200并小于300的成功狀態或ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)的失敗狀態。

6、content_by_lua， content_by_lua_file

語法:content_by_lua <lua-script-str>

語境:location, location if

階段:content

作為"content handler"為每個請求執行lua代碼，為請求者輸出響應內容。此階段是所有請求處理階段中最為重要的一個，運行在這個階段的配置指令一般都肩負著生成內容(content)并輸出HTTP響應。

不要將它和其它的內容處理指令在同一個location內使用如proxy_pass。

7、header_filter_by_lua,header_filter_by_lua_file

語法:header_filter_by_lua <lua-script-str>

語境:http, server, location, location if

階段:output-header-filter

一般用來設置cookie和headers,在該階段不能使用如下幾個API:

? 1、output API(ngx.say和ngx.send_headers)

? 2、control API(ngx.exit和ngx.exec)

? 3、subrequest API(ngx.location.capture和ngx.location.capture_multi)

? 4、cosocket API(ngx.socket.tcp和ngx.req.socket)

有一個例子是在你的lua header filter里添加一個響應頭標頭:

location / {proxy_pass http://mybackend;header_filter_by_lua 'ngx.header.Foo = "blah"'; }

8、body_filter_by_lua,body_filter_by_lua_file

語法:body_filter_by_lua <lua-script-str>

語境:http, server, location, location if

階段: output-body-filter

一般會在一次請求中被調用多次，因為這是實現基于HTTP 1.1 chunked 編碼的所謂"流式輸出"的。該階段不能運行Output API、Control API、Subrequest API、Cosocket API

輸入的數據時通過ngx.arg[1](作為lua的string值),通過ngx.arg[2]這個bool類型表示響應數據流的結尾。

基于這個原因，`eof'只是nginx的鏈接緩沖區的last_buf(對主requests)或last_in_chain(對subrequests)的標記。

運行以下命令可以立即終止運行接下來的lua代碼:

return ngx.ERROR

這會將響應體截斷導致無效的響應。lua代碼可以通過修改ngx.arg[1]的內容將數據傳輸到下游的nginx output body filter階段的其他模塊中去。例如，將response body中的小寫字母進行反轉，我們可以這么寫:

location / {proxy_pass http://mybackend;body_filter_by_lua 'ngx.arg[1] = string.upper[ngx.arg[1])' }

當將ngx.arg[1]設置為nil或者一個空的lua string時，下游的模塊將不會收到數據了。

同樣可以通過修改ngx.arg[2]來設置新的"eof"標記，例如:

location /t {echo hello world;echo hiya globe;body_filter_by_lua 'local chunk = ngx.arg[1]if string.match(chunk, "hello") thenngx.arg[2] = true --new eofreturnend--just throw away any remaining chunk datangx.arg[1] = nil' }

那么GET /t的請求只會回復:hello world

這是因為,當body filter看到了一塊包含"hello"的字符塊后立即將"eof"標記設置為了true,從而導致響應被截斷了但仍然是有效的回復。

當lua代碼中改變了響應體的長度時，應該要清楚content-length響應頭部的值，例如:

location /foo {header_filter_by_lua 'ngx.header.content_length = nil'body_filter_by_lua 'ngx.arg[1] = string.len(ngx.arg[1]) .."\\n"' }

在該階段不能使用如下幾個API:

1、output API(ngx.say和ngx.send_headers) 2、control API(ngx.exit和ngx.exec) 3、subrequest API(ngx.location.capture和ngx.location.capture_multi) 4、cosocket API(ngx.socket.tcp和ngx.req.socket)

9、log_by_lua,log_by_lua_file

語法：log_by_lua <lua-script-str>

語境:http,server,location,location if

階段:log

在log階段調用指定的lua腳本，并不會替換access log,而是在那之后進行調用。該階段總是運行在請求結束的時候，用于請求的后續操作，如在共享內存總進行統計數據，如果要高精確的數據統計，應該使用body_filter_by_lua。

在該階段不能使用如下幾個API:

1、output API(ngx.say和ngx.send_headers) 2、control API(ngx.exit和ngx.exec) 3、subrequest API(ngx.location.capture和ngx.location.capture_multi) 4、cosocket API(ngx.socket.tcp和ngx.req.socket)

一個收集upstream_response_time的平均數據的例子:

lua_shared_dict log_dict 5Mserver {location / {proxy_pass http://mybackendlog_by_lua 'local log_dict = ngx.shared.log_dictlocal upstream_time =tonumber(ngx.var.upstream_response_time)local sum = log_dict:get("upstream_time-sum") or 0sum = sum + upstream_timelog_dict:set("upstream_time-sum", sum)local newval, err = log_dict:incr("upstream_time-nb",1)if not newval and err == "not found" thenlog_dict:add("upstream_time-nb", 0)log_dict:incr("upstream_time-nb", 1)end'}location = /status {content_by_lua 'local log_dict = ngx.shared.log_dictlocal sum = log_dict:get("upstream_time-sum")local nb = log_dict:get("upstream_time-nb")if nb and sum thenngx.say("average upstream response time: ",sum/nb, " (", nb, " reqs)")elsengx.say("no data yet") end'} }

轉自:http://www.mrhaoting.com/?p=157

總結

以上是生活随笔為你收集整理的Nginx-Lua模块的执行顺序的全部內容，希望文章能夠幫你解決所遇到的問題。

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