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

74 天前
 htxy1985
如题,感谢
期望是
1.64 位 id ,有效位只有 53 位可用
2.在设置种子后能保证绝对唯一性。
3.单位时间内不会出现过分的性能瓶颈。
2095 次点击
所在节点    Go 编程语言
11 条回复
BBCCBB
74 天前
如果不要求严格的递增, 只要唯一, 可以用基于 db segment 的方案, 现成的如美团的 leaf 里的 db segment 模式.

要求严格递增, 分布式就只能用类 snowflake 算法,
要严格递增就只能像微信 seqsvr 那样, 单台机器服务某一些业务段了..
BBCCBB
74 天前
说错了. 类 snowflake 做不到时间序的严格递增.. 除非单机
oneisall8955
74 天前
gitrebase
74 天前
绝对唯一性么,就 db 号段吧,有很多优化手段,性能不会差的
Hhehepei
74 天前
问题在于如果要满足楼主的以下几点要求
1.有效位只有 53 位
2.使用 32 位做时间戳
3.机器序号大于 10000(机器序号至少要占 14 位)
那可用的位就只有 53 - 32 - 14 = 7 也就是说单台机器每秒可用的序号就只有 2^7=128
所以楼主的要求就不可能达成啊
ps:很好奇怎样的场景会有超过 10000 台机器,并且每台机器每秒需要几百上千的序号
htxy1985
74 天前
@Hhehepei 你说的很有道理,我现在的思路准备在时间戳上下文章,将时间戳调整成毫秒级的,并缩短使用年限。
lesismal
74 天前
go 里别用 int64 ,用 uint64 好像就是 64 位了,即使存到 mysql 里 bitint unsigned 也是相同范围是兼容的,差不多够 OP 用了
aliipay
73 天前
@htxy1985 改成毫秒对性能只会更差。 你应该设计一个中心化的发号服务,这样机器配置数量就很少了,发号速率就可以做到很高。
另外,时间不一定要 32 位,毕竟 31 位就能用到 2093 年了,还不够吗?
aliipay
73 天前
瞬间峰值问题可以靠提前缓存来实现削峰,还能提高整体可靠性
htxy1985
73 天前
@aliipay 为什么毫秒级性能更差呢?
THESDZ
40 天前
弄一个专门生成 id 的基于时间批量生成,等着别的服务来拿。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/1127623

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX