今天在一个模块中，函数外面写了一个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 开启时，会造成请求间相互影响和数据竞争，产生不可预知的异常状况。

更多参考

lua-variable-scope
变量的共享范围
Data Sharing within an Nginx Worker
data-sharing-in-openresty

lua数据共享方式

module-level variable

ngx.ctx

ngx.var

lua_shared_dict

你可能感兴趣的:(lua数据共享方式)