Hello! 2015-12-28 17:56 GMT-08:00 jakiejia: > 我在应用中使用到了safe_add,incr,get，在safe_add中设置了过期时间是3,按照文档默认应该是3s，我在测试的时候会过期，到了生产环境一开始也会过期， > 过期的意思是通过get_keys查不到，但是过了一段时间发现有的key还存在， > get_keys 函数的实现总是会特殊检查元素的过期时间，剔除掉任何已过期的元素，见这里的代码 https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_shdict.c#L788 > 难道reload会影响key的过期时间吗？ 不会。nginx HUP reload 不会影响共享内存字典里的任何已有的数据，包括过期时间。 Regards, -agentzh
春哥，你好： 我在应用中使用到了safe_add,incr,get，在safe_add中设置了过期时间是3,按照文档默认应该是3s，我在测试的时候会过期，到了生产环境一开始也会过期，过期的意思是通过get_keys查不到，但是过了一段时间发现有的key还存在，难道reload会影响key的过期时间吗？
Hello! 2015-12-28 22:02 GMT-08:00 jakiejia: > share_dict使用应该不用加锁的吧？ > 每个方法的内部都有在必要的地方加锁，所以你不用在单个方法调用上面自己加锁。（不过你仍需要自己小心多个方法调用的线性序列可能引起的 data race 的问题。） Regards, -agentzh
春哥，你说的多个方法调用的线性序列可能引起data race问题，能举个简单的例子吗？多谢
在 2015年12月29日星期二 UTC+8下午2:10:41，agentzh写道：Hello! 2015-12-28 22:02 GMT-08:00 jakiejia: > share_dict使用应该不用加锁的吧？ > 每个方法的内部都有在必要的地方加锁，所以你不用在单个方法调用上面自己加锁。（不过你仍需要自己小心多个方法调用的线性序列可能引起的 data race 的问题。） Regards, -agentzh --
Hello! 2015-12-29 20:17 GMT-08:00 DeJiang Zhu: > > local val = dict:get("foo") > val = val + 1 > dict:set("foo", val) > > 比如这个，因为可能多个 nginx worker 同时操作这个 key > 对，所以对于这个例子，应使用 incr() 这个方法调用，就不存在 data race 的风险了，因为是单一操作，而非读写序列。 Regards, -agentzh
Hello! 2015-12-30 18:33 GMT-08:00 <jak...@163.com>: > 春哥好， > 我昨天发现share_dict中的过期时间没有生效，查看了一下服务器的时间，发现服务器时间被人改过，应该和这个有关吧 > 啊，那就是这个问题了。因为 lua_shared_dict 里面存放过期时间使用的是绝对的时间戳。因此系统时间变更会导致已存在的元素的过期时间发生相应的偏移。 Regards, -agentzh
Hello! 2015-12-30 18:33 GMT-08:00 <jaki...@163.com>: > 春哥好， > 我昨天发现share_dict中的过期时间没有生效，查看了一下服务器的时间，发现服务器时间被人改过，应该和这个有关吧 > 啊，那就是这个问题了。因为 lua_shared_dict 里面存放过期时间使用的是绝对的时间戳。因此系统时间变更会导致已存在的元素的过期时间发生相应的偏移。 Regards, -agentzh
Hello! 2016-08-04 1:39 GMT-07:00 soaercom: > ngx.timer 是不是也会受到系统时间被该的影响？ > 是的，nginx 核心里的 timer 过期时间使用的是绝对时间戳。建议在改系统时间时使用 ntp 这样可以逐步校正时间的工具，以避免系统时钟直接往后跳或者太快向前蹦。 Regards, -agentzh
