是否可以考虑另一种workerid的分配方案 about uid-generator HOT 9 CLOSED

@icanfly 这样每次重启取新的workerId应该是为了解决重启时服务器时间发生回拨的问题。

from uid-generator.

@zer0Black 你这个想法没错，但是可能存在workid不够用的情况。

只能调整worker位数了， 默认前面的delta seconds才8.5年，worker nodes如果22bit即使支持420万次 也是徒劳。况且产线的一个发号服务怎么会天天重启，一个月重启一次都嫌多。所以worker nodes必须要降位，worker nodes借3位给delta seconds。 delta seconds就能支持68年，这样worker nodes还能支持52万次。即使发号器集群有20台机器，平均一天重启一遍 也可能支持70年。 这才是一个均衡的思路。

from uid-generator.

单机部署多个实例或多个应用在一台主机上都依赖他生成id 就会出问题吧

from uid-generator.

@zljgit Idworker应该是一个服务集群，一台机器部署一个就没有这样的问题。如果在一台物理机环境下部署docker环境，docker也会有独立的IP和mac，所以我觉得这块问题不大。

from uid-generator.

111

from uid-generator.

是否可以在应用的启动脚本中添加 -Dwork.id 参数，这样也可以避免同一台机器多个应用部署使用问题，也不会有 work.id 增加的情况。

from uid-generator.

这个方案会导致时间回拨产生的ID重复，请考虑如下一种场景：
服务实例关闭，时间回拨，重启服务实例
这时候重启实例，如果workid不变，可能会造成ID重复的问题。
但如果每次重启workid都变，即便时间回拨了，也可通过workid来保证生成生成ID不重复

from uid-generator.

@zer0Black 你这个想法没错，但是可能存在workid不够用的情况。

from uid-generator.

workerId的复用方案建议考虑下。

from uid-generator.