一、nginx執(zhí)行步驟
nginx在處理每一個(gè)用戶請求時(shí)，都是按照若干個(gè)不同的階段依次處理的，與配置文件上的順序沒有關(guān)系，詳細(xì)內(nèi)容可以閱讀《深入理解nginx:模塊開發(fā)與架構(gòu)解析》這本書，這里只做簡單介紹；
1、post-read
讀取請求內(nèi)容階段，nginx讀取并解析完請求頭之后就立即開始運(yùn)行；
2、server-rewrite
server請求地址重寫階段；
3、find-config
配置查找階段，用來完成當(dāng)前請求與location配重塊之間的配對工作；
4、rewrite
location請求地址重寫階段，當(dāng)ngx_rewrite指令用于location中，就是再這個(gè)階段運(yùn)行的；
5、post-rewrite
請求地址重寫提交階段，當(dāng)nginx完成rewrite階段所要求的內(nèi)部跳轉(zhuǎn)動(dòng)作，如果rewrite階段有這個(gè)要求的話；
6、preaccess
訪問權(quán)限檢查準(zhǔn)備階段，ngx_limit_req和ngx_limit_zone在這個(gè)階段運(yùn)行，ngx_limit_req可以控制請求的訪問頻率，ngx_limit_zone可以控制訪問的并發(fā)度；
7、access
權(quán)限檢查階段，ngx_access在這個(gè)階段運(yùn)行，配置指令多是執(zhí)行訪問控制相關(guān)的任務(wù)，如檢查用戶的訪問權(quán)限，檢查用戶的來源IP是否合法；
8、post-access
訪問權(quán)限檢查提交階段；
9、try-files
配置項(xiàng)try_files處理階段；
10、content
內(nèi)容產(chǎn)生階段，是所有請求處理階段中最為重要的階段，因?yàn)檫@個(gè)階段的指令通常是用來生成HTTP響應(yīng)內(nèi)容的；
11、log
日志模塊處理階段；
二、ngx_lua運(yùn)行指令
ngx_lua屬于nginx的一部分，它的執(zhí)行指令都包含在nginx的11個(gè)步驟之中了，不過ngx_lua并不是所有階段都會(huì)運(yùn)行的；
1、init_by_lua、init_by_lua_file
語法：init_by_lua
語境：http
階段：loading-config
當(dāng)nginx master進(jìn)程在加載nginx配置文件時(shí)運(yùn)行指定的lua腳本，通常用來注冊lua的全局變量或在服務(wù)器啟動(dòng)時(shí)預(yù)加載lua模塊：
init_by_lua 'cjson = require "cjson"';
server {
location = /api {
content_by_lua '
ngx.say(cjson.encode({dog = 5, cat = 6}))
'
}
}
或者初始化lua_shared_dict共享數(shù)據(jù)：
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的內(nèi)容不會(huì)在nginx reload時(shí)被清除。所以如果你不想在你的init_by_lua中重新初始化共享數(shù)據(jù)，那么你需要在你的共享內(nèi)存中設(shè)置一個(gè)標(biāo)志位并在init_by_lua中進(jìn)行檢查。
因?yàn)檫@個(gè)階段的lua代碼是在nginx forks出任何worker進(jìn)程之前運(yùn)行，數(shù)據(jù)和代碼的加載將享受由操作系統(tǒng)提供的copy-on-write的特性，從而節(jié)約了大量的內(nèi)存。
不要在這個(gè)階段初始化你的私有l(wèi)ua全局變量，因?yàn)槭褂胠ua全局變量會(huì)照成性能損失，并且可能導(dǎo)致全局命名空間被污染。
這個(gè)階段只支持一些小的LUA Nginx API設(shè)置：ngx.log和print、ngx.shared.DICT；
2、init_worker_by_lua、init_worker_by_lua_file
語法：init_worker_by_lua
語境：http
階段：starting-worker
在每個(gè)nginx worker進(jìn)程啟動(dòng)時(shí)調(diào)用指定的lua代碼。如果master 進(jìn)程不允許，則只會(huì)在init_by_lua之后調(diào)用。
這個(gè)hook通常用來創(chuàng)建每個(gè)工作進(jìn)程的計(jì)時(shí)器(通過lua的ngx.timer API)，進(jìn)行后端健康檢查或者其它日常工作：
init_worker_by_lua:
local delay = 3? -- in seconds
local new_timer = ngx.timer.at
local log = ngx.log
local ERR = ngx.ERR
local check
check = function(premature)
if not premature then
-- do the health check other routine work
local ok, err = new_timer(delay, check)
if not ok then
log(ERR, "failed to create timer: ", err)
return
end
end
end
local ok, err = new_timer(delay, check)
if not ok then
log(ERR, "failed to create timer: ", err)
end
3、set_by_lua、set_by_lua_file
語法：set_by_lua $res [$arg1 $arg2 …]
語境：server、server if、location、location if
階段：rewrite
傳入?yún)?shù)到指定的lua腳本代碼中執(zhí)行，并得到返回值到res中。中的代碼可以使從ngx.arg表中取得輸入?yún)?shù)(順序索引從1開始)。
這個(gè)指令是為了執(zhí)行短期、快速運(yùn)行的代碼因?yàn)檫\(yùn)行過程中nginx的事件處理循環(huán)是處于阻塞狀態(tài)的。耗費(fèi)時(shí)間的代碼應(yīng)該被避免。
禁止在這個(gè)階段使用下面的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）
此外注意，這個(gè)指令只能一次寫出一個(gè)nginx變量，但是使用ngx.var接口可以解決這個(gè)問題：
location /foo {
set $diff '';
set_by_lua $num '
local a = 32
local b = 56
ngx.var.diff = a - b; --寫入$diff中
return a + b;? --返回到$sum中
'
echo "sum = $sum, diff = $diff";
}
這個(gè)指令可以自由的使用HttpRewriteModule、HttpSetMiscModule和HttpArrayVarModule所有的方法。所有的這些指令都將按他們出現(xiàn)在配置文件中的順序進(jìn)行執(zhí)行。
4、rewrite_by_lua、rewrite_by_lua_file
語法：rewrite_by_lua
語境：http、server、location、location if
階段：rewrite tail
作為rewrite階段的處理，為每個(gè)請求執(zhí)行指定的lua代碼。注意這個(gè)處理是在標(biāo)準(zhǔn)HtpRewriteModule之后進(jìn)行的：
location /foo {
set $a 12;
set $b "";
rewrite_by_lua 'ngx.var.b = tonumber(ngx.var.a) + 1';
echo "res = $b";
}
如果這樣的話將不會(huì)按預(yù)期進(jìn)行工作：
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"
}
因?yàn)閕f會(huì)在rewrite_by_lua之前運(yùn)行，所以判斷將不成立。正確的寫法應(yīng)該是這樣：
location /foo {
set $a 12;
set $b '';
rewrite_by_lua '
ngx.var.b = tonumber(ngx.var.a) + 1
if tonumber(ngx.var.b) == 13 then
return ngx.redirect("/bar");
end
'
echo "res = $b";
}
注意ngx_eval模塊可以近似于使用rewite_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這樣實(shí)現(xiàn)：
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" then
return ngx.redirect("terms-of-use.html")
'
fastcgi_pass .......
}
和其它的rewrite階段的處理程序一樣，rewrite_by_lua在subrequests中一樣可以運(yùn)行。
請注意在rewrite_by_lua內(nèi)調(diào)用ngx.exit(ngx.OK)，nginx的請求處理流程將繼續(xù)進(jìn)行content階段的處理。從rewrite_by_lua終止當(dāng)前的請求，要調(diào)用ngx.exit返回status大于200并小于300的成功狀態(tài)或ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)的失敗狀態(tài)。
如果HttpRewriteModule的重寫指令被用來改寫URI和重定向，那么任何rewrite_by_lua和rewrite_by_lua_file的代碼將不會(huì)執(zhí)行，例如：
location /foo {
rewrite ^ /bar;
rewrite_by_lua 'ngx.exit(503)'
}
location /bar {
.......
}
在這個(gè)例子中ngx.exit(503)將永遠(yuǎn)不會(huì)被執(zhí)行，因?yàn)閞ewrite修改了location，請求已經(jīng)跳入其它location中了。
5、access_by_lua，access_by_lua_file
語法：access_by_lua
語境：http,server,location,location if
階段：access tail
為每個(gè)請求在訪問階段的調(diào)用lua腳本進(jìn)行處理。主要用于訪問控制，能收集到大部分的變量。
注意access_by_lua和rewrite_by_lua類似是在標(biāo)準(zhǔn)HttpAccessModule之后才會(huì)運(yùn)行，看一個(gè)例子：
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在黑名單之內(nèi)，那么這次連接會(huì)在進(jìn)入access_by_lua調(diào)用的mysql之前被丟棄掉。
ngx_auth_request模塊和access_by_lua的用法類似：
location / {
auth_request /auth;
}
可以用ngx_lua這么實(shí)現(xiàn)：
location / {
access_by_lua '
local res = ngx.location.capture("/auth")
if res.status == ngx.HTTP_OK then
return
end
if res.status == ngx.HTTP_FORBIDDEN then
ngx.exit(res.status)
end
ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)
'
}
和其它access階段的模塊一樣，access_by_lua不會(huì)在subrequest中運(yùn)行。
請注意在access_by_lua內(nèi)調(diào)用ngx.exit(ngx.OK)，nginx的請求處理流程將繼續(xù)進(jìn)行后面階段的處理。從rewrite_by_lua終止當(dāng)前的請求，要調(diào)用ngx.exit返回status大于200并小于300的成功狀態(tài)或ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)的失敗狀態(tài)。
6、content_by_lua，content_by_lua_file
語法：content_by_lua
語境：location，location if
階段：content
作為“content handler”為每個(gè)請求執(zhí)行l(wèi)ua代碼，為請求者輸出響應(yīng)內(nèi)容。
不要將它和其它的內(nèi)容處理指令在同一個(gè)location內(nèi)使用如proxy_pass。
7、header_filter_by_lua，header_filter_by_lua_file
語法：header_filter_by_lua
語境：http，server，location，location if
階段：output-header-filter
一般用來設(shè)置cookie和headers，在該階段不能使用如下幾個(gè)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）
有一個(gè)例子是 在你的lua header filter里添加一個(gè)響應(yīng)頭標(biāo)頭：
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
語境：http，server，location，location if
階段：output-body-filter
輸入的數(shù)據(jù)時(shí)通過ngx.arg[1](作為lua的string值)，通過ngx.arg[2]這個(gè)bool類型表示響應(yīng)數(shù)據(jù)流的結(jié)尾。
基于這個(gè)原因，‘eof’只是nginx的鏈接緩沖區(qū)的last_buf（對主requests）或last_in_chain（對subrequests）的標(biāo)記。
運(yùn)行以下命令可以立即終止運(yùn)行接下來的lua代碼：
return ngx.ERROR
這會(huì)將響應(yīng)體截?cái)鄬?dǎo)致無效的響應(yīng)。lua代碼可以通過修改ngx.arg[1]的內(nèi)容將數(shù)據(jù)傳輸?shù)较掠蔚膎ginx output body filter階段的其它模塊中去。例如，將response body中的小寫字母進(jìn)行反轉(zhuǎn)，我們可以這么寫：
location / {
proxy_pass http://mybackend;
body_filter_by_lua 'ngx.arg[1] = string.upper(ngx.arg[1])'
}
當(dāng)將ngx.arg[1]設(shè)置為nil或者一個(gè)空的lua string時(shí)，下游的模塊將不會(huì)收到數(shù)據(jù)了。
同樣可以通過修改ngx.arg[2]來設(shè)置新的”eof“標(biāo)記，例如：
location /t {
echo hello world;
echo hiya globe;
body_filter_by_lua '
local chunk = ngx.arg[1]
if string.match(chunk, "hello") then
ngx.arg[2] = true --new eof
return
end
--just throw away any remaining chunk data
ngx.arg[1] = nil
'
}
那么GET /t的請求只會(huì)回復(fù)：hello world
這是因?yàn)?，?dāng)body filter看到了一塊包含”hello“的字符塊后立即將”eof“標(biāo)記設(shè)置為了true，從而導(dǎo)致響應(yīng)被截?cái)嗔说匀皇怯行У幕貜?fù)。
當(dāng)lua代碼中改變了響應(yīng)體的長度時(shí)，應(yīng)該要清除content-length響應(yīng)頭部的值，例如：
location /foo {
header_filter_by_lua 'ngx.header.content_length = nil'
body_filter_by_lua 'ngx.arg[1] = string.len(ngx.arg[1]) .. "\\n"'
}
在該階段不能使用如下幾個(gè)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）
nginx output filters可能會(huì)在一次請求中被多次調(diào)用，因?yàn)轫憫?yīng)體可能是以chunks方式傳輸?shù)?。因此這個(gè)指令一般會(huì)在一次請求中被調(diào)用多次。
9、log_by_lua，log_by_lua_file
語法：log_by_lua
語境：http，server，location，location if
階段：log
在log階段調(diào)用指定的lua腳本，并不會(huì)替換access log，而是在那之后進(jìn)行調(diào)用。
在該階段不能使用如下幾個(gè)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）
一個(gè)收集upstream_response_time的平均數(shù)據(jù)的例子：
lua_shared_dict log_dict 5M
server{
location / {
proxy_pass http;//mybackend
log_by_lua '
local log_dict = ngx.shared.log_dict
local upstream_time = tonumber(ngx.var.upstream_response_time)
local sum = log_dict:get("upstream_time-sum") or 0
sum = sum + upstream_time
log_dict:set("upsteam_time-sum", sum)
local newval, err = log_dict:incr("upstream_time-nb", 1)
if not newval and err == "not found" then
log_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_dict
local sum = log_dict:get("upstream_time-sum")
local nb = log_dict:get("upstream_time-nb")
if nb and sum then
ngx.say("average upstream response time:? ", sum/nb, " (", nb, " reqs)")
else
ngx.say("no data yet")
end
'
}
}
