我最近在做一个简单的灰度系统，把用户的请求重定向到不同的页面1)灰度规则和当前灰度ver以json格式存储在ngx.shared.DICT中，init_by_lua中声明一个全局变量G_CONFIG,储存当前灰度ver和decode后的json规则
lua_shared_dict rules 1m;
init_by_lua "
--设置共享内存中数据
--声明G_CONFIG全局变量,从共享内存中读取赋值
";
2)更新灰度规则的时候通过http请求来更新共享内存中的灰度规则版本号之
server{
location /update_nginx_shm{
#更新请求，更新共享内存中的灰度ver和json格式规则
}
location /{
#正常请求，读取G_CONFIG中的规则，转发请求到后端的upstream模块
}
这种做法存在一个问题，更新共享内存中的灰度规则和版本号之后，没办法更新全局变量G_CONFIG,只能再request到来时，比较G_CONFIG.ver和共享内存中的ver是否一致，不一致的时候从共享内存重新load规则，感觉有点麻烦
我看了Data Sharing within an Nginx Worker这部分文档，想在init_by_lua下加载一个全局的config模块，原来的G_CONFIG变量存储在config模块内，这样子似乎可以绕开校验这一步，在更新共享内存中规则时更新一次config模块的数据，每当有新请求到来时，保证G_CONFIG中的规则都是最新的
大概脚本会变成这样:
1)lua_shared_dict rules 1m;
init_by_lua "
--设置共享内存中数据
--加载cofing模块
G_CONFIG=require("config.lua“）
";
config.lua:
module(...)
ver=xxx;
rules={xxx};
2)server{
location /update_nginx_shm{
#更新共享内存中的灰度ver和json格式规则
#同时更新G_CONFIG.ver,G_CONGFIG.rules
}
}
不知道这样做有没有什么问题，想请教下大家。我目前只想到有多个更新共享内存的请求到来时，可能会导致更新混乱，这个可以在前端管理页面限制只有单人登录操作来避免，不知道还有没有其他的问题。
