------------------ 原始邮件 ------------------
发件人: "agentzh";<age...@gmail.com>;
发送时间: 2015年12月31日(星期四) 下午2:24
收件人: "openresty"<openresty@googlegroups.com>;
主题: Re: [openresty] 关于shared dict存储结构的一些看法
Hello!
2015-12-30 18:38 GMT-08:00 Fei Ai:
> 关于共享内存的存储结构的设计我觉得可以改进下，目的是为了支持更加丰富的数据类型比如list或者hash，对于现在的存储结构我理解中可能有以下的一些不妥的地方：
>
> 1. 现在的shared 在set_helper函数里面对lua接口输入的参数类型做了一个switch判断，如果要继续实现list 以及hash
> 可能需要在这个外面在嵌套一层对key value中value类型的判断
> （value是一个简单的字符串or数字或者是一个list或者是一个hash）然后在这个判断之下在做一次lua传入值类型的判断，（这个可能有更好的实现方式只是我想不到）
目前已经有类型的判断了，因为我们已经支持 string, number, boolean 这三种 Lua
的基本数据类型。我对于在这里增加更多的类型倒并不担心，因为我们可以使用 switch/case 语句来作这种类型判断，而现代的 C
优化编译器通常会将这样的 switch/case 语句编译为 jump table，属于 O(1) 操作。
>
> 2. 由于加锁是对整块内存区加锁 所以在业务里面我们通常都会把大块的共享内存给切分开，既然这样，我觉得把类型切分开来也没什么不妥的 ^_^
>
我个人比较偏向于 Redis 的方式，因为无论如何我们还是需要支持动态的多队列和多哈希表。而多队列也需要按队列名进行查找，多哈希表也需要按表名称来定位，因此还是变回到
key-value 的模式。
当然，用户尽可能地按数据的类型进行 shm zone 的划分，还是很有意义的，可以减少内存碎片和降低锁开销。
> 3.最后我担心的是类型的丰富反而会导致一些简单的存储 比如普通的key：string 这样的存储的成本变高，以及代码层面的复杂性也会增加
>
对于这一点，我倒并不是很担心，呵呵。请见我上面的解释。
> 最后我的想法是 在lua main conf 里面用ngx_array_t 来管理不同类型的共享内存， 比如为list hash 和dict分别建立数组
> 然后 ngx.share.list[“”] 或者 ngx_shared.dict[“”] 这样的方式来使用
>
引入特殊的静态 lua_shared_list 也许性能会更好一些，但如果本来队列的数目就不多，复用 lua_shared_dict
来动态查找 list 的开销也可以忽略不计。我还是很喜欢动态创建和删除队列的能力，这对于很多业务来说是非常重要的。
值得一提的是，ngx_lua 有一个正在 review 的 PR 允许第三方 NGINX C 模块定义自己的共享内存存储对象，供 Lua
代码调用，而不用修改 ngx_lua 核心本身。届时我们也方便自己提供更细化的共享内存引擎：
https://github.com/openresty/lua-nginx-module/pull/559
请问这个补PR如何下载集成使用起来去试。另外这个PR目前已知的BUG是什么？
>
一些简单的想法 如果不对请春哥指点下
>
我只稍微表达一下我的个人观点哈，不一定正确。欢迎大家一起讨论，呵呵。
Regards,
-agentzh
--
--
邮件来自列表“openresty”,专用于技术讨论!
订阅: 请发空白邮件到 openresty+subscribe@googlegroups.com
发言: 请发邮件到 openresty@googlegroups.com
退订: 请发邮件至 openresty+unsubscribe@googlegroups.com
归档: http://groups.google.com/group/openresty
官网: http://openresty.org/
仓库: https://github.com/agentzh/ngx_openresty
教程: http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html
