创建check timer的方式为何要用lock来保证唯一性？

[fankeke]

hello，请教下：
1 为何创建check timer要用lock的方式而不是用ngx.worker.id的方式来创建唯一timer？是有什么特殊的考虑吗？

2 在lock方式中（目前的方式），base.CHECKUP_TIMER_KEY在设置到mutex shdict中时为何要设置超时时间？（默认60s) ，

谢谢

[tokers]

1. 当然是用 ngx.worker.id 也是可以保证 timer 的唯一性的。
2. 在目前的方式下，如果不对 CHECKUP_TIMER_KEY 这个键设置超时，那么当持有 timer 的进程 crash 之后，重新启动的 worker 无法创建出新的 timer，当然，如果共享内存字典面临内存不足的情况，键也是有可能被强制移除的，这就另当别论了。

[huangnauh]

master 分支已经不再以 lock 的方式创建 timer. https://github.com/upyun/lua-resty-checkups/blob/master/lib/resty/checkups/api.lua#L184

1. ngx_lua 在 0.9.20 之前没有 ngx.worker.id, 再之前也没有 init_worker_by*, 所以需要加锁来保证唯一
2. 为了防止死锁

[fankeke]

@tokers @huangnauh 谢谢回复
1 对于第一个，我理解是当时没有ngx.worker.id这个API，所以用了lock的这种方案来实现创建唯一check timer的是吧。
但是，在master分支，代码里面已经用到了ngx.worker.id（在config字典里存放节点信息），这个是怎么回事？

2 对于死锁的问题，我考虑过，但持有timer的worker挂掉后会导致死锁。不过CHECKUP_TIMER_KEY这个值是和os.time相关的，所以挂掉后，CHECKUP_TIMER_KEY值会不同，不会有死锁的问题。
local CHECKUP_TIMER_KEY = "checkups:timer:" .. os.time()

谢谢

[huangnauh]

1. 呃, 这个是后来加入的功能, 是可选的
2. os.time 不是针对上述情况的, 那时候 CHECKUP_TIMER_KEY 不会改变

[fankeke]

@huangnauh
谢谢回复

2 ， 之前用lock方式的CHECKUP_TIMER_KEY是不变的是吧，好吧。。。
那么目前的CHECKUP_TIMER_KEY是做什么工作的？