環境: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., balancer_by_lukiwuyisa
這個 lua 表可以用來儲存基於請求的 lua 環境資料，其生存週期與當前請求相同 (類似 nginx 變數)。
參考下面例子，
location /test
access_by_lua_block
content_by_lua_block
}訪問 get /test 輸出
79也就是說，ngx.ctx.foo 條目跨越乙個請求的 rewrite (重寫)，access (訪問)，和 content (內容) 各處理階段保持一致。
每個請求，包括子請求，都有乙份自己的 ngx.ctx 表。例如：
location /sub
}kiwuyis
location /main
}訪問 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
} location /orig
}訪問 get /orig 將輸出
nil而不是原始的 "hello" 值。
任意資料值，包括 lua 閉包與巢狀表，都可以被插入這個「魔法」表，也允許註冊自定義元方法。
也可以將 ngx.ctx 覆蓋為乙個新 lua 表，例如，
ngx.ctx =
當用在 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"
endreturn _m
應使用下面方式替代：
-- mymodule.lua
local _m = {}
function _m.main(ctx)
ctx.foo = "bar"
endreturn _m
就是說，呼叫者對 ctx 表呼叫應通過函式傳參方式完成。
總結本文標題: nginx利用ctx實現資料共享、修改上下文功能
本文位址:
nginx 使用ctx實現資料共享，修改上下文
環境 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.balancer by ...
利用nginx實現指定路由
nginx作為負載均衡，如果後面有2臺伺服器，那麼會均衡的打到後面的兩台伺服器上，如果要實現具體的使用者打到指定的伺服器上，就需要用到nginx配置的路由。配置檔案如下 兩種方式，第一種是通過實際情況的http引數來路由，就是如下的 nginx有 args全域性變數，是否包含字串hostid 1來路...
利用nginx實現負載均衡
我這裡是使用docker安裝的。安裝流程可參照 dockerfile 這裡安裝了兩個tomcat，埠分別是42000和42001。第二個tomcat的首頁隨便加了些 區分 這裡的網域名稱要和下面proxy pass的一樣 重新整理頁面發現頁面會發生變化，證明負載配置成功。因為我配的權重第二個是第乙個...