分布式ID（唯一性）的生成方法汇总

最新推荐文章于 2025-01-19 00:15:46 发布

2401_89308216

最新推荐文章于 2025-01-19 00:15:46 发布

阅读量929

点赞数 6

文章标签：分布式

本文链接：https://blog.youkuaiyun.com/2401_89308216/article/details/144354969

版权

图1

2. 数据库自增ID

基于数据库的auto_increment自增ID完全可以充当分布式ID，具体原理：创建一个单独的实例用来生成ID，用一张数据表存储目前的最大ID（图2）。

当我们需要一个ID的时候，向表中插入一条记录返回主键ID，但访问量激增时数据库本身就是系统的瓶颈，用它来实现分布式服务风险比较大，不推荐！

优点是数据库生成的ID绝对有序，高可用实现方式简单；
缺点是需要独立部署数据库实例，成本高，数据库压力大，性能有限（可通过DB集群设置不同步长改善，即部署N台数据库实例，每台设置成不同的初始值，自增步长为机器的台数，如图3所示，可实现多个ID实例自增），但这种方法可能会导致数据的安全性问题。

图2

图3

3. 号段模式

一次按需批量生成多个ID，每次生成都需要访问数据库，将数据库修改为最大的ID值，并在内存中记录当前值及最大值一般可以借助redis实现，如图4所示。

优点是避免了每次生成ID都要访问数据库并带来压力，提高性能；
缺点是属于本地生成策略，存在单点故障，服务重启造成ID不连续。

图4

4. Redis生成

Redis服务器来也可以生成全局ID，这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID 如图5。利用Redis的原子操作 INCR和INCRBY来实现。

优点是不依赖于数据库，灵活方便，性能高。数字ID天然排序，对分页或者需要排序的结果很有帮助。使用Redis集群也可以防止单点故障的问题；
缺点是依赖第三方组件Redis，增加系统复杂度。需要编码和配置的工作量比较大。

图5

5. snowflake算法

snowflake 是 twitter 开源的分布式ID生成算法，其核心思想为，一个long型的ID：41 bit 作为毫秒数、10 bit 作为机器编号（10位的长度最多支持部署1024个节点）、12 bit 作为毫秒内序列号（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号），如图6。

优点是简单高效，生成速度快。时间戳在高位，自增序列在低位，整个ID是趋势递增的，按照时间有序递增。灵活度高，可以根据业务需求，调整bit位的划分，满足不同的需求。不需要其他依赖，使用方便。
缺点是强依赖机器的时钟，如果服务器时钟回拨，会导致重复ID生成。在分布式环境上，每个服务器的时钟不可能完全同步，有时会出现不是全局递增的情况，不同机器配置不同worker id麻烦。

图6

6. 百度UidGenerator

UidGenerator是Java实现的, 基于Snowflake算法的唯一ID生成器。UidGenerator以组件（图7）形式工作在应用项目中, 支持自定义workerId位数和初始化策略, 从而适用于docker等虚拟化环境下实例自动重启、漂移等场景。

优点是全局唯一，高可用、高性能解决了始终回拨的问题；
缺点是内置WorkerID分配器, 依赖数据库，启动阶段通过DB进行分配; 如自定义实现, 则DB非必选依赖。

图7

7. 美团Leaf

美团的Leaf分布式ID生成组件（图8）是在Snowflake算法的基础上做了两套优化的方案：Leaf-segment数据库方案（相比之前的方案每次都要读取数据库，该方案改用代理服务器批量获取，且做了双缓存的优化）与Leaf-snowflake方案（主要针对时钟回拨问题做了特殊处理。若发生时钟回拨则拒绝发号，并进行告警）。