-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sync timer 唯一性问题 #1
Comments
这里不加不会影响到功能,但是从代码严谨的角度来说是要加。欢迎提交 PR。 |
@tokers 另外,感觉用lock来做唯一性的timer没有那么优雅,可以用worker id来做。 (另外os.time的精度不够,连续起两个sync会导致同样的LOCK_TIME_KEY也是一个问题) 如果可行的话,我提个PR |
@fankeke 你的方案,如果持有 sync timer 的 worker 进程 crash 了,怎么保证新起来的 worker 可以重新创建出 sync timer 来? |
新的worker再走一遍init_worker阶段 ,也能够创建。 function _M.new(...) function _M.start(self) 基本思想和上面一样 |
那这个 worker_id 应该要放到共享内存里。 |
从你的伪代码来看,持有 sync timer 的 worker 如果挂了,新起来一个 worker,也是随机一个 |
额,好像是的 。。。 思路有点问题。 |
@fankeke 不过 os.time 的问题,可能是会有精度不够的问题,可以在这个基础上结合一个随机数,哈哈 |
嗯,我提个PR可以 |
@tokers 当前的做法还是有些问题: 这个时候就会发生问题, 是不是这样? |
@fankeke 是的。 |
@tokers 目前的resty-sync如何避免我上面的场景的? |
@fankeke 你可以仔细看下 如果某个 worker 进入到这个函数,先第一次抢锁,抢到锁的,首先会判断这个 如果这个 这样子,在有 worker 崩溃的时候,如果不是 timer owner 崩溃,则由于 |
@tokers crash后的worker创建的 LOCK_TIMER_KEY 在变化,并不是不变的,这个你考虑了吗? 这是我起了4个worker,创建一个sync时的shdict的数据,我kill了三次worker后的数据: 此时3个worker都持有了这个sync的timer。 |
@fankeke 恩,这个 |
https://github.com/upyun/lua-resty-sync/blob/master/lib/resty/sync.lua#L324
if var and var ~= id then
release_lock(lock)
return true
end
没有看具体逻辑,但感觉这里应该要释放lock(抢到后)
The text was updated successfully, but these errors were encountered: