求一款稳定靠谱的分布式整型 ID 生成组件

[htxy1985]

如题，感谢
期望是
1.64 位 id ，有效位只有 53 位可用
2.在设置种子后能保证绝对唯一性。
3.单位时间内不会出现过分的性能瓶颈。

[BBCCBB]

如果不要求严格的递增, 只要唯一, 可以用基于 db segment 的方案, 现成的如美团的 leaf 里的 db segment 模式.

要求严格递增, 分布式就只能用类 snowflake 算法,
要严格递增就只能像微信 seqsvr 那样, 单台机器服务某一些业务段了..

[BBCCBB]

说错了. 类 snowflake 做不到时间序的严格递增.. 除非单机

[itechify]

https://github.com/sony/sonyflake

[gitrebase]

绝对唯一性么，就 db 号段吧，有很多优化手段，性能不会差的

[Hhehepei]

问题在于如果要满足楼主的以下几点要求
1.有效位只有 53 位
2.使用 32 位做时间戳
3.机器序号大于 10000(机器序号至少要占 14 位)
那可用的位就只有 53 - 32 - 14 = 7 也就是说单台机器每秒可用的序号就只有 2^7=128
所以楼主的要求就不可能达成啊
ps：很好奇怎样的场景会有超过 10000 台机器，并且每台机器每秒需要几百上千的序号

[htxy1985]

@Hhehepei 你说的很有道理，我现在的思路准备在时间戳上下文章，将时间戳调整成毫秒级的，并缩短使用年限。

[lesismal]

go 里别用 int64 ，用 uint64 好像就是 64 位了，即使存到 mysql 里 bitint unsigned 也是相同范围是兼容的，差不多够 OP 用了

[aliipay]

@htxy1985 改成毫秒对性能只会更差。 你应该设计一个中心化的发号服务，这样机器配置数量就很少了，发号速率就可以做到很高。
另外，时间不一定要 32 位，毕竟 31 位就能用到 2093 年了，还不够吗？

[aliipay]

瞬间峰值问题可以靠提前缓存来实现削峰，还能提高整体可靠性

[htxy1985]

@aliipay 为什么毫秒级性能更差呢？

[THESDZ]

弄一个专门生成 id 的基于时间批量生成，等着别的服务来拿。