環境: init_worker_by_lua, set_by_lua, rewrite_by_lua, access_by_lua, content_by_lua, header_filter_by_lua, body_filter_by_lua, log_by_lua, ngx.timer., balance. 這個 Lua 表可以用來儲存基於請求的 Lua 環境數據，其生存週期與目前請求相同 (類似 Nginx 變數)。
參考下面例子，
location /test {
rewrite_by_lua_block {
ngx.ctx.foo = 76
# }
# access_by_lua_block {
ngx.ctx.foo = ngx.ctx.foo 3
# }
# content_by_lua_block {
# ngx.say(ngx.ctx.foo)
}
# }
存取 GET /test 輸出
# 79
也就是說，ngx.ctx.foo 條目跨越一個請求的 rewrite (重寫)，access (訪問)，和 content (內容) 各處理階段保持一致。
每個請求，包括子請求，都有一份自己的 ngx.ctx 表。例如：
location /sub {
content_by_lua_block {
# ngx.say("sub pre: ", ngx.ctx.blah)
# ngx.ctx.blah = 32
# ngx.say("sub post: ", ngx.ctx.blah)
}
# }
location /main {
# content_by_lua_block {
# ngx.ctx.blah = 73
# ngx.say("main pre: ", ngx.ctx.blah)
# local res = ngx.location.capture("/sub")
# ngx.print(res.body)
# ngx.say("main post: ", ngx.ctx.blah)
}
# }
存取 GET /main 輸出
# main pre: 73
sub pre: nil
sub post: 32
main post: 73
這裡，在子請求中修改 ngx.ctx.blah 條目並不影響父請求中的同名條目，因為它們各自維護不同版本的 ngx.ctx.blah。
內部重定向將摧毀原始請求中的 ngx.ctx 資料 (如果有)，新請求將會有一個空白的 ngx.ctx 表。例如，
location /new {
content_by_lua_block {
# ngx.say(ngx.ctx.foo)
}
# }
location /orig {
# content_by_lua_block {
# ngx.ctx.foo = "hello"
# ngx.exec("/new")
# }
# }
存取 GET /orig 將輸出
# nil
而不是原始的 "hello" 值。
任意資料值，包括 Lua 閉包與巢狀表，都可以插入這個「魔法」表，也允許註冊自訂元方法。
也可以將 ngx.ctx 覆寫為一個新 Lua 表，例如，
ngx.ctx = { foo = 32, bar = 54 }
當用在 init_worker_by_lua* 環境中，這個表與目前 Lua 句柄生命週期相同。
ngx.ctx 表查詢需要相對昂貴的元方法調用，這比透過使用者自己的函數參數直接傳遞基於請求的資料要慢得多。所以不要為了節約用戶函數參數而濫用此 API，因為它可能對效能有明顯影響。
而且由於元方法“魔法”，不要在 lua 模組層級試圖使用 "local" 等級的 ngx.ctx ，例如 worker-level data sharing。下面範例是糟糕的：
-- mymodule.lua
local _M = {}
# -- 下面一行的 ngx.ctx 是屬於單一請求的，但 ctx 變數是在 Lua 模組層級
-- 且屬於單一 worker 的。
local ctx = ngx.ctx
function _M.main()
ctx.foo = "bar"
# end
return _M
應使用下面方式替代：
-- mymodule.lua
local _M = {}
# function _M.main(ctx)
ctx.foo = "bar"
# end
return _M
就是說，呼叫者對 ctx 表呼叫應透過函數傳參方式完成。
以上是nginx怎麼使用ctx實現資料共享的詳細內容。更多資訊請關注PHP中文網其他相關文章！
