分布式唯一ID生成方案对比分析 笔记

什么时候需要分布式唯一ID？

如果你的系统还没有使用到分片策略（分库分表），那么这篇文章可以等到你用上分库分表之后再做一个参考阅读。

 

本文对比了几种分布式ID生成方案，目前暂时有三家厂商的方案被列入，它们分别是：百度的 UidGenerator，美团的 Leaf，滴滴（小橘）的 TinyId。

分布式ID生成，根据目前分析的方案总结下来，有两种模式：

（1）类 snowflake 模式：ID 64 bit，解决 worker Id 的唯一性分发即可大幅提升此模式的性能。但通常要面对时间回拨问题，这个问题有点无解，通常都只能用“绕过”的方式去处理。百度的 UidGenerator 中有一个实现号称单机 600w qps，性能爆表。

（2）segment 模式：依赖数据库行记录，ID 也不是随时间连续的，各个服务之间无法保证 ID 与 时间连续的绝对关系。滴滴的 tinyid 在 client 模式下号称可达到 1000w qps，很强悍。不过这种模式应该很容易被猜出销量？

 

目前笔记如下：

 

最后有一个困扰已久的疑问：为什么ID需要是递增的呢？

做过的业务比较少，完全没法理解 ID 要递增是什么概念，而且分布式下 ID 根本没法全局递增，除非牺牲 QPS。有研究的同学可以踊跃评论啊！！！

以上