今天在一个模块中，函数外面写了一个local变量，发现这个变量在不同的请求之间是共享的，正好总结和探讨下在nignx+lua实现数据共享的其他方式。
module-level variable
先看下以下的代码
1.nginx中的配置
access_by_lua_file 'router.lua';
2.router.lua
local test = require "test"
test.exec()
3.test.lua
local _M = {}
local num = 0
function _.exec()
num = num + 1
ngx.say(num)
end
return _M
连续请求多次，会发现num的值从1，2，3...开始逐步递增，并不是固定为1。
把一个需要共享的数据，放在lua模块中，通过require导入这个模块，同一个nginx worker处理的所有请求，就都共享了这个数据。这个是因为，requirelua模块只会被加载一次，所有的协程都共享了这个模块的所有（包含了代码和数据）。需要注意的是，因为一个请求一个协程的隔离设计，lua的gloal变量（不是module级别的变量）不会在不同请求中共享。
Found this:https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker
ngx.ctx
ngx.ctx用于在同一个请求的不同阶段进行数据共享,效率很高，并且可以存储任意的lua对象。
ngx.ctx采用的是懒加载的形式，在第一次试图访问的时候，会创建一个lua table,并将这个table和request object绑定在一起，在这个请求的后续阶段就都可以访问到同一个table。
location /{
rewrite_by_lua_block {
ngx.ctx.num = 1
}
access_by_lua_block {
ngx.ctx.num = ngx.ctx.num + 1
}
content_by_lua_block {
ngx.say(ngx.ctx.num)
}
}
执行请求，数据值为2,可以看到ngx.ctx在 rewrite ，access ，和 content 各处理阶段保持一致。
ngx.ctx和request objec绑定在一起的。使用ngx.timer.*创建的timer,其实是运行在另外的request context中,因此是无法使用创建该timer请求中的ngx.ctx。使用 ngx.thread.spawn创建的新协程是运行在同一个request context中的，因此是共享同一个ngx.ctx。
location /sub {
content_by_lua_block {
ngx.say("sub pre: ", ngx.ctx.num)
ngx.ctx.num = 100
ngx.say("sub post: ", ngx.ctx.num)
}
}
location /main {
content_by_lua_block {
ngx.ctx.num = 1
ngx.say("main:", ngx.ctx.num)
-- 子请求
local res = ngx.location.capture("/sub")
ngx.print(res.body)
ngx.say("main post: ", ngx.ctx.num)
}
}
输出结果如下
main pre: 1
sub pre: nil
sub post: 100
main post: 1
可以看出，每个请求，包括子请求，都有一份自己的 ngx.ctx 表。子请求修改ngx.ctx,并不会影响父请求的ngx.ctx。
location /new {
content_by_lua_block {
ngx.say(ngx.ctx.num)
}
}
location / {
content_by_lua_block {
ngx.ctx.num = 1
ngx.exec("/new")
}
}
访问\输出结果
nil
使用ngx.exec内部重定向将摧毁原始请求中的 ngx.ctx 数据 (如果有)，新请求将会有一个空白的 ngx.ctx 表。
ngx.ctx是基于请求的，因此不要写如下的代码
local _M = {}
-- 下面一行的 ngx.ctx 是属于单个请求的，但 `ctx` 变量是在 Lua 模块级别
-- 并且属于单个 worker 的。
local ctx = ngx.ctx
function handle_request()
-- save something inside ctx
end
return _M
可以这么写
local _M = {}
local ngx = ngx
function handle_request()
local ctx = ngx.ctx
-- save something inside ctx
end
return _M
ngx.var
显然我们也可以通过ngx.var.VARIABLE来共享数据，其生命周期贯穿于一个请求。但是由于ngx.var它具有计算 hash 值，查找 hash 表，分配内存等等操作，效率会被ngx.ctx更低一些。
如果在一个请求中，多次修改同一个变量，会涉及想你的内存分配，这些呢困直到请求结束才会被释放。另外，ngx.var内置变量不能是nil或者其他任意的byte string
lua_shared_dict
使用共享字典的方式，可以在不同的workers中共享数据。共享字典的效率非常高，需要提前分配一块内存，这个运行时无法被改变。共享字典不支持任意的lua 对象，只能支持原生的集中数据类型（number,string,boolen等）
1.nginx中设置共享字典大小
lua_shared_dict num 100m;
2.访问和设置
local countdict = ngx.shared.num
countdict:safe_set('test',countdict+1)
使用共享数据注意点：
nginx 是多 worker 进程的模型，所以除了共享内存字典是所有 worker 进程共享之外，其他的数据都是每 worker 一份的，无论是在 init_by_lua 里面创建的全局变量，还是 Lua 模块里的状态变量。
在某个请求里面更新某个 Lua 变量，只是更新了当前处理这个请求的 nginx worker 进程里的状态，并不会影响其他的 worker 进程
不应使用模块级的局部变量以及模块属性，存放任何请求级的数据。否则在 luacodecache 开启时，会造成请求间相互影响和数据竞争，产生不可预知的异常状况。
更多参考
