一、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 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 <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 = 32
        local b = 56
        ngx.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) + 1
        if tonumber(ngx.var.b) == 13 then
            return 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" then
            return 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 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不會在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") then
            ngx.arg[2] = true  --new eof
            return
        end
        --just throw away any remaining chunk data
        ngx.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 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("upstream_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
        '
    }
}

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