回复：[openresty] 关于shared dict存储结构的一些看法

chenweidelphi

晕，那怎么使用有代码样例么？

------------------ 原始邮件 ------------------

发件人: Fei Ai <ai...@openresty.org>

发送时间: 2015年12月31日 17:28

收件人: openresty@googlegroups.com <openresty@googlegroups.com>

主题: Re: [openresty] 关于shared dict存储结构的一些看法

嗯哼？

这个pr里面应该包含了源码了吧

https://github.com/openresty/lua-nginx-module/pull/559

可以自己尝试替换源码然后编译

当然我也没有编译过

^_^

2015年12月31日星期四，泡泡鱼 <chenwe...@qq.com> 写道：

那么这个模块有没有最简单的Sample去体验一下？

------------------ 原始邮件 ------------------
发件人: "Fei Ai";<ai...@openresty.org>;
发送时间: 2015年12月31日(星期四) 下午5:07
收件人: "openresty"<openresty@googlegroups.com>;
主题: Re: [openresty] 关于shared dict存储结构的一些看法

不是一个bug的补丁是将内存初始化的函数接口提供出来交给这个模块定义的函数去初始化

2015-12-31 17:05 GMT+08:00 泡泡鱼 <chenwe...@qq.com>:

------------------ 原始邮件 ------------------
发件人: "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

--
--

--
--