多谢春哥的回复！:)
在 2013年2月20日星期三UTC+8下午1时53分25秒，agentzh写道：
Hello!
2013/2/19 melon198502:
> 我最近一直在测试考察ngx_lua的使用，感觉很好，很强大，准备将其应用到即将开发的应用中。为了ngx_lua更好，斗胆提点个人的愚见:)
谢谢你提供意见和建议 :)
> 1.关于ngx.shared.DICT
>
> 我准备开发的应用，准备使用它，我有种需求需要遍历DICT中的数据，现在是只能先调用ngx.shared.DICT.get_keys取值所有的key，然后再遍历依次获取key的值，感觉这样有些繁琐，您是否
> 能添加一个可以获取DICT中所有 数据的接口呢？这样是不是对于和我有同样需求的用户会更方便一些呢？
这算是一个 FAQ 了 :)
共享内存字典是一种很简单的 key-value 存储结构，它的 API 是按照 memcached
的接口来设计的，获取所有数据对于很大的字典来说会长时间导致整个服务不可用（包括 CPU
开销和内存开销）。所以我有意没有提供这样的接口（我相信这也是为什么 memcached 的标准协议中也没有提供这样的接口）。
其实我当时在添加 get_keys 方法时就已经不太情愿了，呵呵。
呵呵 ，了然了！
> 2.关于lua-resty-redis和lua-resty-mysql
>
> 我在测试这个库的时候发现可以通过其都可以使用连接池，但没有获得连接池状态的接口，以便根据应用的实际情况来调整连接池的大小，现在只能是凭经验和感觉，当然或许可以通过
> get_reused_times 接口自己编写代码来实现，这样的话感觉会增加应用的复杂度而且不如通过库提供一个接口来的效率高
这里我一直有打算通过向 Nginx Systemtap Toolkit 添加专门的外部工具来对 Nginx
进程中的各个连接池进行实时监测，这样不会增加连接池本身的复杂度 :)
届时我们可以通过这个工具获得真实环境中的实时统计结果，并据此对连接池的相关参数进行调整。
期待这个工具的早日到来:)
> 3.关于ngx.req.socket
>
> 我在通过ngx.req.socket设置了超时调用receive接收数据超时后，套接字被置为了closed状态，我如果再次调用receive的话就会出错，超时之后能否不将其置为closed状态呢，因为超时发生客户
>
> 端不一定断开了连接，这对于需要保持长连接进行交互的应用不太方便。比如receive超时的时候我没获取到我想要的数据，我可能需要发送数据让客户端重发数据，发送完成后我需要再次
> receive，目前无法实现这样需求。
>
如果你只是想确保连接可用的话，可以直接启用你的 TCP 协议栈实现的 TCP keepalive 机制（一般内置在操作系统内核中）。
让 ngx.req.socket() 在读超时的时候不让 socket 进入 closed 状态，倒是可以考虑在 ngx_lua 中进行修改。欢迎贡献补丁 :)
呵呵 不单纯是想确保连接可用，是想在连接可用的情况下可有些交互，有交互可能就会有超时后再次调用recevie的情况，如果一次调用套接字处于closed状态的话下次再调用就不ok了
我真心想贡献补丁，可惜现在水平还有些欠缺，nginx，ngx_lua的代码还都没看过，lua也是才开始学，贡献补丁的话可能还需要些时日，不过我会持续关注openresty，期待自己将来某一天能为openresty贡献补丁:)
