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