一文详解分布式 ID

前言

分布式系统中,我们经常需要对数据、消息等进行唯一标识,这个唯一标识就是分布式 ID,那么我们如何设计它呢?本文将详细讲述分布式 ID 及其生成方案。


一、为什么需要分布式 ID

目前大部分的系统都已是分布式系统,所以在这种场景的业务开发中,经常会需要唯一 ID 对数据进行标识,比如用户身份标识、消息标识等等。

并且在数据量达到一定规模后,大部分的系统也需要进行分库分表,这种场景下单库的自增 ID 已达不到我们的预期。所以我们需要分布式 ID 来对各种场景的数据进行唯一标识。

二、分布式 ID 的特性

主要特性:

  • 全局唯一:分布式 ID 最基本要求,必须全局唯一。
  • 高可用:高并发下要保证 ID 的生成效率,避免影响系统。
  • 易用性:使用简单,可快速接入。

除此之外根据不同场景还有:

  • 有序性:数据库场景下的主键 ID,有序性可便于数据写入和排序。
  • 安全性:无规则 ID,一般用于避免业务信息泄露场景,如订单量。

二、分布式 ID 常见生成方案

1. UUID

UUID(Universally Unique Identifier),即通用唯一识别码。UUID 的目的是让分布式系统中的所有元素都能有唯一的识别信息。

UUID 是由128位二进制数组成,通常表示为32个十六进制字符,形如:

550e8400-e29b-41d4-a716-446655440000

这个字符串由五个部分组成,以连字符-分隔开,具体如下:

部分 大小 说明
时间戳 32 bits UUID的前32位表示当前的时间戳。
时钟序列和随机数 16 bits 用于保证在同一时刻生成的UUID的唯一性。
变体标识 4 bits 标识 UUID 的变体,通常为固定值,表示是由 RFC 4122 定义。
版本号 4 bits 标识UUID的版本,常见版本有1、3、4和5
节点 48 bits 在版本 1 中,这部分包含生成 UUID 的计算机的唯一标识。

主要的 UUID 版本及其生成规则:

版本 场景 生成规则
版本 1 基于时间和节点 由当前的时间戳和节点信息生成。包括时间戳、时钟序列、节点标识。
版本 2 基于DCE安全标识符 类似版本 1,但在时间戳部分包含 POSIX UID/GID 信息。
版本 3 基于名字和散列值(MD5 版) 由命名空间和名字的MD5散列生成。
版本 4 完全随机生成 通过随机或伪随机生成128位数字。
版本 5 基于名字和散列值(SHA-1 版) 通过随机或伪随机生成128位数字。

Java中 UUID 对版本 4 进行了实现:

java 复制代码
public static void main (String[] args) {
    // 默认版本 4
    System.out.println(UUID.randomUUID());

    // 版本 3,由命名空间和名字的MD5散列生成,相同命名空间结果相同
    // 如下,"fuxing"返回的UUID一直为8b9b6bc3-90c8-37ef-bbef-0ed0c552718f
    System.out.println(UUID.nameUUIDFromBytes("fuxing".getBytes()));
}

优点: 本地生成,没有网络消耗,性能非常高。

缺点:

  • 占用空间大,32 个字符串,128 位。
  • 不安全:版本 1 可能会造成 mac 地址泄露。
  • 无序,非自增。
  • 机器时间不对,可能造成 UUID 重复。

2. 数据库自增 ID

实现简单,解释通过数据库表中的主键 ID 自增来生成唯一标识。如下,维护一个 MySQL 表来生成 ID。

sql 复制代码
CREATE TABLE `unique_id` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `value` char(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

当需要生成分布式 ID 时,向表中插入数据并返回主键 ID,这里 value 无含义,只是为了占位,方便插入数据。

优点: 实现简单,基本满足业务需求,且天然有序。

缺点:

  • 数据库自身的单点故障和数据一致性问题。
  • 不安全,比如可根据自增来判断订单量。
  • 高并发场景可能会受限于数据库瓶颈。

那么有没有办法解决数据库自增 ID 的缺点呢?

通过水平拆分的方案,将表设置到不同的数据库中,设置不同的起始值和步长,这样可以有效的生成集群中的唯一 ID,也大大降低 ID 生成数据库操作的负载,示例如下。

unique_id_1配置:

sql 复制代码
set @@auto_increment_offset = 1;     -- 起始值
set @@auto_increment_increment = 2;  -- 步长

unique_id_2配置:

sql 复制代码
set @@auto_increment_offset = 2;     -- 起始值
set @@auto_increment_increment = 2;  -- 步长

这个还是需要根据自己的业务需求来,水平扩展的集群数量要符合自己的数据量,因为当设置的集群数量不足以满足高并发时,再次进行扩容集群会很麻烦。多台机器的起始值和步长都需要重新配置。

3. 数据库号段模式

号段模式是当下分布式 ID 生成器的主流实现方式之一,比如美团 Leaf-segment、滴滴 Tinyid、微信序列号等都使用的该方案,下面的大厂中间件中会展开说明。

号段模式也是基于数据库的自增 ID,数据库自增 ID 是一次性获取一个分布式 ID,号段模式可以理解成从数据库批量获取 ID,然后将 ID 缓存在本地,以此来提高业务获取 ID 的效率。

例如,每次从数据库获取 ID 时,获取一个号段,如(1,1000],这个范围表示 1000 个 ID,业务应用在请求获取 ID 时,只需要在本地从 1 开始自增并返回,而不用每次去请求数据库,一直到本地自增到 1000 时,才去数据库重新获取新的号段,后续流程循环往复。

表结构可进行如下设计:

sql 复制代码
CREATE TABLE `id_generator` (
  `id` int(10) NOT NULL,
  `max_id` bigint(20) NOT NULL COMMENT '当前最大id',
  `step` int(10) NOT NULL COMMENT '号段的步长',
  `version` int(20) NOT NULL COMMENT '版本号',
  `biz_type` int(20) NOT NULL COMMENT '业务场景',
   PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

其中max_idstep用于获取批量的 ID,version是一个乐观锁,保证并发时数据的正确性。

比如,我们新增一条表数据如下。

id max_id step version biz_type
1 100 1000 0 001

然后我们可以使用该号段批量生成的 ID,当max_id = 1000,则执行 update 操作生成新的号段。新的号段的 SQL。

sql 复制代码
UPDATE 
id_generator 
SET 
max_id = #{max_id+ step}, 
version = version + 1 
WHERE 
version = #{version} AND biz_type = 001;

优点: ID 有序递增、存储消耗空间小。

缺点:

  • 数据库自身的单点故障和数据一致性问题。
  • 不安全,比如可根据自增来判断订单量。
  • 高并发场景可能会受限于数据库瓶颈。

缺点同样可以通过集群的方式进行优化,也可以如Tinyid 采用双缓存进行优化,下面的大厂中间件中会展开说明。

4. 基于Redis

当使用数据库来生成 ID 性能不够的时候,可以尝试使用 Redis 来生成 ID。原理则是利用 Redis 的原子操作 INCR 和 INCRBY 来实现。

命令示例:

命令 说明 示例
INCR 让一个整形的key自增1 redis> SET mykey "10" "OK" redis> INCR mykey (integer) 11
INCRBY 让一个整形的key自增并指定步长 redis> SET mykey "10" "OK" redis> INCRBY mykey 5 (integer) 15

优点: 不依赖于数据库,使用灵活,支持高并发。

缺点:

  • 系统须引入 Redis 数据库。
  • 不安全,比如可根据自增来判断订单量。
  • Redis 出现单点故障问题,可能会丢数据导致 ID 重复。

5. 雪花算法

雪花算法(Snowflake)是 twitter 公司内部分布式项目采用的 ID 生成算法。结果是一个 long 型的 ID。Snowflake 算法将 64bit 划分为多段,分开来标识机器、时间等信息,具体组成结构如下图所示:

结构说明:

结构 大小 说明
符号位 1 bit 0 表示正数,1 表示负数。
时间戳 41 bits 存储的是当前时间戳 - 开始时间戳,最长 69 年。
机器位 10 bits 前 5位 datacenterId,后 5 位 workerId ,最多表示 1024 台。
序列号 12 bits 毫秒内的流水号,意味着每个节点在每毫秒可以产生 4096 个 ID。

优点:

稳定性高,不依赖于数据库等第三方系统。

使用灵活方便,可以根据业务需求的特性来调整算法中的 bit 位。

单机上 ID 单调自增,毫秒数在高位,自增序列在低位,整体上按照时间自增排序。

缺点:

  • 强依赖机器时钟,如果机器上时钟回拨,可能导致发号重复或者服务处于不可用状态。
  • ID 可能不是全局递增,虽然 ID 在单机上是递增的。
  • Redis 出现单点故障问题,可能会丢数据导致 ID 重复。

算法实现(Java):

java 复制代码
package util;
 
import java.util.Date;
 
/**
 * @ClassName: SnowFlakeUtil
 * @Author: jiaoxian
 * @Date: 2022/4/24 16:34
 * @Description:
 */
public class SnowFlakeUtil {
 
    private static SnowFlakeUtil snowFlakeUtil;
    static {
        snowFlakeUtil = new SnowFlakeUtil();
    }
 
    // 初始时间戳(纪年),可用雪花算法服务上线时间戳的值
    // 1650789964886:2022-04-24 16:45:59
    private static final long INIT_EPOCH = 1650789964886L;
 
    // 时间位取&
    private static final long TIME_BIT = 0b1111111111111111111111111111111111111111110000000000000000000000L;
 
    // 记录最后使用的毫秒时间戳,主要用于判断是否同一毫秒,以及用于服务器时钟回拨判断
    private long lastTimeMillis = -1L;
 
    // dataCenterId占用的位数
    private static final long DATA_CENTER_ID_BITS = 5L;
 
    // dataCenterId占用5个比特位,最大值31
    // 0000000000000000000000000000000000000000000000000000000000011111
    private static final long MAX_DATA_CENTER_ID = ~(-1L << DATA_CENTER_ID_BITS);
 
    // dataCenterId
    private long dataCenterId;
 
    // workId占用的位数
    private static final long WORKER_ID_BITS = 5L;
 
    // workId占用5个比特位,最大值31
    // 0000000000000000000000000000000000000000000000000000000000011111
    private static final long MAX_WORKER_ID = ~(-1L << WORKER_ID_BITS);
 
    // workId
    private long workerId;
 
    // 最后12位,代表每毫秒内可产生最大序列号,即 2^12 - 1 = 4095
    private static final long SEQUENCE_BITS = 12L;
 
    // 掩码(最低12位为1,高位都为0),主要用于与自增后的序列号进行位与,如果值为0,则代表自增后的序列号超过了4095
    // 0000000000000000000000000000000000000000000000000000111111111111
    private static final long SEQUENCE_MASK = ~(-1L << SEQUENCE_BITS);
 
    // 同一毫秒内的最新序号,最大值可为 2^12 - 1 = 4095
    private long sequence;
 
    // workId位需要左移的位数 12
    private static final long WORK_ID_SHIFT = SEQUENCE_BITS;
 
    // dataCenterId位需要左移的位数 12+5
    private static final long DATA_CENTER_ID_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS;
 
    // 时间戳需要左移的位数 12+5+5
    private static final long TIMESTAMP_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS + DATA_CENTER_ID_BITS;
 
    /**
     * 无参构造
     */
    public SnowFlakeUtil() {
        this(1, 1);
    }
 
    /**
     * 有参构造
     * @param dataCenterId
     * @param workerId
     */
    public SnowFlakeUtil(long dataCenterId, long workerId) {
        // 检查dataCenterId的合法值
        if (dataCenterId < 0 || dataCenterId > MAX_DATA_CENTER_ID) {
            throw new IllegalArgumentException(
                    String.format("dataCenterId 值必须大于 0 并且小于 %d", MAX_DATA_CENTER_ID));
        }
        // 检查workId的合法值
        if (workerId < 0 || workerId > MAX_WORKER_ID) {
            throw new IllegalArgumentException(String.format("workId 值必须大于 0 并且小于 %d", MAX_WORKER_ID));
        }
        this.workerId = workerId;
        this.dataCenterId = dataCenterId;
    }
 
    /**
     * 获取唯一ID
     * @return
     */
    public static Long getSnowFlakeId() {
        return snowFlakeUtil.nextId();
    }
 
    /**
     * 通过雪花算法生成下一个id,注意这里使用synchronized同步
     * @return 唯一id
     */
    public synchronized long nextId() {
        long currentTimeMillis = System.currentTimeMillis();
        System.out.println(currentTimeMillis);
        // 当前时间小于上一次生成id使用的时间,可能出现服务器时钟回拨问题
        if (currentTimeMillis < lastTimeMillis) {
            throw new RuntimeException(
                    String.format("可能出现服务器时钟回拨问题,请检查服务器时间。当前服务器时间戳:%d,上一次使用时间戳:%d", currentTimeMillis,
                            lastTimeMillis));
        }
        if (currentTimeMillis == lastTimeMillis) {
            // 还是在同一毫秒内,则将序列号递增1,序列号最大值为4095
            // 序列号的最大值是4095,使用掩码(最低12位为1,高位都为0)进行位与运行后如果值为0,则自增后的序列号超过了4095
            // 那么就使用新的时间戳
            sequence = (sequence + 1) & SEQUENCE_MASK;
            if (sequence == 0) {
                currentTimeMillis = getNextMillis(lastTimeMillis);
            }
        } else { // 不在同一毫秒内,则序列号重新从0开始,序列号最大值为4095
            sequence = 0;
        }
        // 记录最后一次使用的毫秒时间戳
        lastTimeMillis = currentTimeMillis;
        // 核心算法,将不同部分的数值移动到指定的位置,然后进行或运行
        // <<:左移运算符, 1 << 2 即将二进制的 1 扩大 2^2 倍
        // |:位或运算符, 是把某两个数中, 只要其中一个的某一位为1, 则结果的该位就为1
        // 优先级:<< > |
        return
                // 时间戳部分
                ((currentTimeMillis - INIT_EPOCH) << TIMESTAMP_SHIFT)
                // 数据中心部分
                | (dataCenterId << DATA_CENTER_ID_SHIFT)
                // 机器表示部分
                | (workerId << WORK_ID_SHIFT)
                // 序列号部分
                | sequence;
    }
 
    /**
     * 获取指定时间戳的接下来的时间戳,也可以说是下一毫秒
     * @param lastTimeMillis 指定毫秒时间戳
     * @return 时间戳
     */
    private long getNextMillis(long lastTimeMillis) {
        long currentTimeMillis = System.currentTimeMillis();
        while (currentTimeMillis <= lastTimeMillis) {
            currentTimeMillis = System.currentTimeMillis();
        }
        return currentTimeMillis;
    }
 
    /**
     * 获取随机字符串,length=13
     * @return
     */
    public static String getRandomStr() {
        return Long.toString(getSnowFlakeId(), Character.MAX_RADIX);
    }
 
    /**
     * 从ID中获取时间
     * @param id 由此类生成的ID
     * @return
     */
    public static Date getTimeBySnowFlakeId(long id) {
        return new Date(((TIME_BIT & id) >> 22) + INIT_EPOCH);
    }
 
    public static void main(String[] args) {
        SnowFlakeUtil snowFlakeUtil = new SnowFlakeUtil();
        long id = snowFlakeUtil.nextId();
        System.out.println(id);
        Date date = SnowFlakeUtil.getTimeBySnowFlakeId(id);
        System.out.println(date);
        long time = date.getTime();
        System.out.println(time);
        System.out.println(getRandomStr());
 
    }
 
}

四、大厂中间件

1. 美团 Leaf

Leaf 的官方文档,简介和特性可访问了解,这里我将对 Leaf 的两种方案,Leaf segment 和 Leaf-snowflake 进行。

1.1. Leaf segment

基于数据库号段模式的 ID 生成方案,上面我们介绍到普通的号段模式有一些缺点:

  • 数据库自身的单点故障和数据一致性问题。
  • 不安全,比如可根据自增来判断订单量。
  • 高并发场景可能会受限于数据库瓶颈。

那么 Leaf 是如何做的呢?Leaf 采用了预分发的方式生成ID,也就是在 DB 之上挂 n 个 Leaf Server,每个Server启动时,都会去 DB 拿固定长度的 ID List。

这样就做到了完全基于分布式的架构,同时因为ID是由内存分发,所以也可以做到很高效,处理流程图如下:

其中:

  • Leaf Server 1:从 DB 加载号段[1,1000]。
  • Leaf Server 2:从 DB 加载号段[1001,2000]。
  • Leaf Server 3:从 DB 加载号段[2001,3000]。

用户通过轮询的方式调用 Leaf Server 的各个服务,所以某一个 Client 获取到的ID序列可能是:1,1001,2001,2,1002,2002。当某个 Leaf Server 号段用完之后,下一次请求就会从 DB 中加载新的号段,这样保证了每次加载的号段是递增的。

为了解决在更新DB号段的时出现的耗时和阻塞服务的问题,Leaf 采用了异步更新的策略,同时通过双缓存的方式,保证无论何时DB出现问题,都能有一个 Buffer 的号段可以正常对外提供服务,只要 DB 在一个 Buffer 的下发的周期内恢复,就不会影响整个 Leaf 的可用性。

除此之外,Leaf 还通过动态调整步长,解决由于步长固定导致的缓存中的 ID 被过快消耗问题,以及步长设置过大导致的号段 ID 跨度过大问题,具体公式可去官方文档中了解。

对于数据一致性问题,Leaf 目前是通过中间件 Zebra 加 MHA 做的主从切换。

1.2. Leaf Snowflake

Leaf-snowflake 方案沿用 Snowflake 方案的 bit 位设计。

对于 workerID 的分配:当服务集群较小时,通过配置即可;服务集群较大时,基于 zookeeper 持久顺序节点的特性引入 zookeeper 组件配置 workerID。架构如下图所示:

2. 百度 UidGenerator

开源地址

UidGenerator 方案是基于 Snowflake 算法的 ID 生成器,其对雪花算法的 bit 位的分配做了微调。

结构说明(参数可在 Spring Bean 配置中进行配置):

结构 大小 说明
符号位 1 bit 最高位始终是 0。
增量秒 28 bits 表示自客户纪元(2016-05-20)以来的增量秒。最大时间为 8.7 年。
工作节点 22 bits 表示工作节点 ID,最大值为 4.2 百万个。
序列号 13 bits 表示一秒钟内的序列,默认情况下每秒最多 8192 个。

UidGenerator 方案包含两种实现方式,DefaultUidGenerator 和 CachedUidGenerator ,性能要求高的情况下推荐 CachedUidGenerator。

3. 滴滴 Tinyid

Tinyid 官方文档

Tinyid 方案是在 Leaf-segment 的算法基础上升级而来,不仅支持了数据库多主节点模式,还提供了 tinyid-client 客户端的接入方式,使用起来更加方便。

Tinyid 也是采用了异步加双缓存策略,首先可用号段加载到内存中,并在内存中生成 ID,可用号段在首次获取 ID 时加载,号段用到一定程度的时候,就去异步加载下一个号段,保证内存中始终有可用号段,则可避免性能波动。

实现原理如下所示:

五、结语

本文对分布式 ID 以及其场景的生成方案做了介绍,还针对一下大厂的中间件进行简单分析,中间件的接入代码本文并没有做详细介绍,但是官方文档的链接都帖子了每个子标题下,其中都有详细介绍。

文中还针对每个生成方案的优缺点作出了说明,具体的使用可针对优缺点加上业务需求来进行选型。


参考:

[1] 腾讯技术工程. 分布式唯一 ID 生成方案浅谈.

[2] 孟斯特. UUID 介绍.

[3] 文丑颜不良啊. 雪花算法(SnowFlake).

相关推荐
jikuaidi6yuan9 分钟前
鸿蒙系统(HarmonyOS)分布式任务调度
分布式·华为·harmonyos
天冬忘忧29 分钟前
Kafka 生产者全面解析:从基础原理到高级实践
大数据·分布式·kafka
天冬忘忧1 小时前
Kafka 数据倾斜:原因、影响与解决方案
分布式·kafka
隔着天花板看星星1 小时前
Kafka-Consumer理论知识
大数据·分布式·中间件·kafka
隔着天花板看星星1 小时前
Kafka-副本分配策略
大数据·分布式·中间件·kafka
金刚猿2 小时前
简单理解下基于 Redisson 库的分布式锁机制
分布式·分布式锁·redisson
我一直在流浪2 小时前
Kafka - 消费者程序仅消费一半分区消息的问题
分布式·kafka
张彦峰ZYF4 小时前
投资策略规划最优决策分析
分布式·算法·金融
processflow流程图6 小时前
分布式kettle调度平台v6.4.0新功能介绍
分布式
全栈开发圈6 小时前
干货分享|分布式数据科学工具 Xorbits 的使用
分布式