workid是否支持回收

[loren9527]

SnowflakeService模式中，workid是否支持回收？分布式环境下，每次重新部署可能就换了一个ip，如果没有回收的话1024个机器标识很快就会消耗完，为什么zk不用临时节点去存储呢，这样能动态感知服务上下线，对workid进行管理回收

[Yaccc]

暂不支持，欢迎提PR

[thelight1]

重新部署可能换一个ip？为啥部署就要换ip？
目前美团内部大部分服务已实现容器化部署，leaf服务运行在固定十几台机器上，机器ip也都是固定的，除非新增机器或下掉机器才会出现新消耗workerId的情况。leaf服务开始运行到现在几年时间了，workerId消耗的个数还不到100个。

[qixiaobo]

重新部署可能换一个ip？为啥部署就要换ip？
目前美团内部大部分服务已实现容器化部署，leaf服务运行在固定十几台机器上，机器ip也都是固定的，除非新增机器或下掉机器才会出现新消耗workerId的情况。leaf服务开始运行到现在几年时间了，workerId消耗的个数还不到100个。

他的意思docker的虚拟ip吧 重启都会更换的

[NotFound9]

@Yaccc 同学，你好！针对workId暂时不支持回收的问题，我提了一个PR，增加了一种workId复用的机制，辛苦你看一看，谢谢了！PR在这里#94

[Yaccc]

如果循环利用workid的目的 仅仅是因为workid不够用，我觉得直接增加workid的位数就行了！目前看起来没有什么强有力的理由要让workid复用起来 @NotFound9

[NotFound9]

@Yaccc 你好，我仔细思考后，我认为以目前美团使用ID生成服务的方式来看，之前的那种方式是比较贴合美团业务的，因为美团的使用ID生成器的方式主要是通过基础架构组在特定范围内的机器部署Leaf实例，然后业务方通过HTTP，RPC来调用，如果是像百度的Uid-generator那样，业务方将Leaf以组件化的方式来集成到项目中，然后部署到各自业务的机器上，这样首先需要增加对workId的位数，而且由于是面向整个公司的IP和Port，可能导致zookeeper存储的workId列表过长，这样每次从zookeeper获取workId列表的传输数据量会比较大，判断列表中是否有当前IP+端口对应的workId的时间复杂度会比较高，所以当前的方式没法应对像百度的Uid-generator那样以组件化方式接入Leaf的业务场景。

[NotFound9]

@loren9527 你好，这个项目 https://github.com/NotFound9/Leaf 中增加了对workId回收的功能支持，大家感兴趣可以看一看

[Tgxiaowei]

这边拜读了workId回收功能，雪花算法应该是一个本地生成ID的组件，由各个应用集成。
因此每个应用都会去轮训zk目标节点下的所有子节点，这样可能不是一个很好的方法吧？