[go: up one dir, main page]

Skip to content
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

zk方式,zk故障,此时服务需要重启时,id生成不可用 #15

Open
huminpet opened this issue Mar 6, 2022 · 3 comments
Open

Comments

@huminpet
Copy link
huminpet commented Mar 6, 2022

能否考虑在本机文件系统上缓存一个workerID文件。当ZooKeeper出现问题,恰好机器出现问题需要重启时,能保证服务能够正常启动。这样做到了对三方组件的弱依赖。一定程度上提高了SLA

@simonalong
Copy link
Owner

想了下,可以搞,不过要做限制。

本地缓存workdId,下次启动继续使用,这个前提是该workId能够继续使用,即没有过期,而没有过期的前提是,当前启动时间距离上次使用时间是小于24小时,也就是说24小时以内服务启动起来重用缓存workId是没有问题的(起来后也要继续对该wordId发起心跳,顺便刷新过期时间)。如果是24小时后起来的,则很有可能该workId已经被其他节点给占有了,这种情况就会出现id重复问题。

因此如果要搞本地文件缓存,则需要将24小时也考虑进去,24小时以内可以复用,24小时以后再启动则要必须从zk重新获取

为了更准确建议本地文件缓存的该workId小于24小时,即23小时即可

@huminpet
Copy link
Author

嗯,那最近有计划搞一下么,最近公司考虑接入你这个,但对SLA要求高,等你优化后我们再接入

@simonalong
Copy link
Owner

可以搞下,不过最近有点忙,有项目要交付,要3月底了

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants