【分布式ID】分布式id生成策略及案例

一、分布式id概述

1、分布式id业务场景？

  • 在业务开发中，会存在大量的场景都需要唯一 ID 来进行标识。比如，用户需要唯一身份标识；商品需要唯一标识；消息需要唯一标识；事件需要唯一标识等等。
  • 在分布式系统中，同一个服务存在多个实例，部署在不同的服务器，需要使用相应策略保证唯一标识的唯一性。

2、分布式id具备那些特性？

  • 全局唯一：必须保证生成的 ID 是全局性唯一的，这是分布式 ID 的基本要求；
  • 有序性：生成的 ID 需要按照某种规则有序，便于数据库的写入和排序操作；
  • 可用性：需要保证高并发下的可用性。除了对 ID 号码自身的要求，业务还对 ID 生成系统的可用性要求极高；
  • 自主性：分布式环境下不依赖中心认证即可自行生成 ID；
  • 安全性：不暴露系统和业务的信息。在一些业务场景下，会需要 ID 无规则或者不规则。

二、id生成策略

1-UUID

1-1、UUID是什么？
  • UUID是基于当前时间、计数器（counter）和硬件标识（通常为无线网卡的MAC地址）等数据计算生成的唯一标识字符串。
1-2、UUID的结构是怎样的？

UUID 是由一组32位数的16进制数字所构成，以连字号分隔的五组来显示，形式为 8-4-4-4-12，总共有 36个字符（即三十二个英数字母和四个连字号）。例如：1f189b0e-47f0-4a69-a291-a9472fb06c96

1-3、怎么生成UUID？
  • 使用 UUID.randomUUID() 生成,代码如下：
/**
 * Copyright (c) 2023-2023 xiangliheart(湘澧寸心) All rights reserved.
 */
 
package com.xiangliheart.distributedids.strategy;
 
import java.util.UUID;
 
/**
 * Strategy_UUID UUID生成策略
 *
 * @auther: xiangliheart(湘澧寸心)
 * @since: 2023/2/26
 */
public class Strategy_UUID {
    
    /**
     * 随机生成10个UUID并print
     *
     * @auther: xiangliheart(湘澧寸心)
     * @since: 2023/2/26
     */
    public static void main(String[] args){
        for(int i=0;i<10;i++){
           System.out.println("UUID"+i+":"+UUID.randomUUID().toString());
        }
    }
}
  • 运行结果：
UUID0:1f189b0e-47f0-4a69-a291-a9472fb06c96
UUID1:682a4d57-f05d-4c5e-806b-39046238759e
UUID2:373e3c3e-0d21-43aa-b3b3-c1c529e6b0c6
UUID3:be693505-eaa7-4ca2-98f2-1dcf33a6b40c
UUID4:95e63858-b3ec-4c9b-8326-701d8bfb62f8
UUID5:1c0429db-76b1-448b-b3aa-5f3d77677989
UUID6:30ad2394-9868-4855-97cf-00ab578d8e8c
UUID7:3ce0d3ef-3f7d-487d-b183-02ff8d1617d0
UUID8:d2f17288-7213-423f-bcef-6f6fe298f50c
UUID9:cde06012-3bb3-40ea-b44a-40aed9c774c4
 
Process finished with exit code 0
1-4、UUID的优/缺点？

优点：

  • 代码简单、使用方便；
  • 性能好、全球唯一

缺点：

  • 随机生成、没有排序、无法保证趋势递增
  • 使用字符串存储，查询效率低
  • 占用空间大、传输效率低
1-5、UUID是否可以作为分布式id，为什么？

UUID不可以作为分布式id，原因如下：

  • 首先分布式id一般都会作为主键，但是安装mysql官方推荐主键要尽量越短越好，UUID每一个都很长，所以不是很推荐。
  • 既然分布式id是主键，然后主键是包含索引的，然后mysql的索引是通过b+树来实现的，每一次新的UUID数据的插入，为了查询的优化，都会对索引底层的b+树进行修改，因为UUID数据是无序的，所以每一次UUID数据的插入都会对主键生成的b+树进行很大的修改，这一点很不好。
  • 信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。

2、自增id

2-1、什么是自增id?
  • 使用数据库id字段的自增能力，实现id的的自动增长，保证单库单表id的唯一性和有序性。
2-2、如何使用自增id？
  • 数据库id字段设置auto_increment
    image
  • 保存的user_id字段就会自动递增
    image
2-3、自增id生成策略的优/缺点？
  • 优点：使用简单，满足基本业务需求，天然有序
  • 缺点：强依赖DB，高并发场景下对DB产生较大负载，影响系统性能，不适用于分库分表、容易出现单点故障、数据一致性等问题。ID 号的生成速率取决于所使用数据库的读写性能。

针对自增id的上述缺陷，可对自增id做相应优化，即下文即将阐述的数据库多主模式和号段模式。

2-4、自增id的适用场景？
  • 在单个数据库的场景中我们是可以这样做的，但如果是在分库分表的环境下。直接利用单个数据库的自增肯定会出现问题。因为id要唯一，但是分表分库后，自增id策略只能保证一个表中的id的唯一，而不能保证整体的id唯一。

3、数据库多主模式

3-1、什么是数据库多主模式?
  • 单点数据库方式存在明显的性能问题，可以对数据库进行高可用优化，担心一个主节点挂掉没法使用，可以选择做双主模式集群，也就是两个或多个MySQL实例都能单独生成自增的id。
3-2、数据库多主模式实现原理是怎么样的？
  • 多个数据库实例独立生成id。
  • 每个数据库实例设置不同的id初始值、相同的步长，从而达到生唯一id的目的。

4、号段模式

4-1、什么是号段模式？
  • 每次从数据库取一批id号段，使用完之后，再从数据库取，减少数据库的访问压力。
4-2、号段模式的实现原理是怎么样的？

  • 在数据库创建一张表，记录当前最大的可用id及号段步长。
    image

  • 从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如 (1,1000] 代表1000个ID，具体的业务服务将本号段，生成1~1000的自增ID并加载到内存。

  • 等这批号段ID用完，再次向数据库申请新号段，对max_id字段做一次update操作，update max_id= max_id + step，update成功则说明新号段获取成功，新的号段范围是(max_id ,max_id +step]。

4-3、号段模式有什么优、缺点？
  • 优点：号段模式生成方式不强依赖于数据库，不会频繁的访问数据库，对数据库的压力小很多。
  • 缺点：服务器重启，单点故障会造成ID不连续。

5、使用redis生成

  基于全局唯一ID的特性，我们可以通过Redis的INCR命令来生成全局唯一ID。

imagepng

同样使用Redis也有对应的缺点：

  1. ID 生成的持久化问题，如果Redis宕机了怎么进行恢复
  2. 当个节点宕机问题

当然针对故障问题我们可以通过Redis集群来处理，比如我们有三个Redis的Master节点。可以初始化每台Redis的值分别是1,2,3，然后分别把分布式ID的KEY用Hash Tags固定每一个master节点，步长就是master节点的个数。各个Redis生成的ID为：

A:1,4,7

B:2,5,8

C:3,6,9

优点：

  1. 不依赖于数据库，灵活方便，且性能优于数据库
  2. 数字ID有序，对分页处理和排序都很友好
  3. 防止了Redis的单机故障

缺点：

  1. 如果没有Redis数据库，需要安装配置，增加复杂度
  2. 集群节点确定是3个后，后面调整不是很友好

Redis分布式ID的简单案例

/**
 *  Redis 分布式ID生成器
 */
@Component
public class RedisDistributedId {
 
    @Autowired
    private StringRedisTemplate redisTemplate;
 
    private static final long BEGIN_TIMESTAMP = 1659312000l;
 
    /**
     * 生成分布式ID
     * 符号位    时间戳[31位]  自增序号【32位】
     * @param item
     * @return
     */
    public long nextId(String item){
        // 1.生成时间戳
        LocalDateTime now = LocalDateTime.now();
        // 格林威治时间差
        long nowSecond = now.toEpochSecond(ZoneOffset.UTC);
        // 我们需要获取的 时间戳 信息
        long timestamp = nowSecond - BEGIN_TIMESTAMP;
        // 2.生成序号 --》 从Redis中获取
        // 当前当前的日期
        String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
        // 获取对应的自增的序号
        Long increment = redisTemplate.opsForValue().increment("id:" + item + ":" + date);
        return timestamp << 32 | increment;
    }
 
}

6.雪花算法

  Snowflake，雪花算法是有Twitter开源的分布式ID生成算法，以划分命名空间的方式将64bit位分割成了多个部分，每个部分都有具体的不同含义，在Java中64Bit位的整数是Long类型，所以在Java中Snowflake算法生成的ID就是long来存储的。具体如下：

imagepng

第一部分：占用1bit,第一位为符号位，不适用

第二部分：41位的时间戳，41bit位可以表示241个数，每个数代表的是毫秒，那么雪花算法的时间年限是(241)/(1000×60×60×24×365)=69年

第三部分:10bit表示是机器数，即 2^ 10 = 1024台机器，通常不会部署这么多机器

第四部分:12bit位是自增序列，可以表示2^12=4096个数，一秒内可以生成4096个ID

案例代码：

package com.xiangliheart.utils;
 
/**
 * Twitter_Snowflake
 * SnowFlake的结构如下(每部分用-分开):
 * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
 * 1位标识，由于long基本类型在Java中是带符号的，最高位是符号位，正数是0，负数是1，所以id一般是正数，最高位是0
 * 41位时间截(毫秒级)，注意，41位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截)
 * 得到的值），这里的的开始时间截，一般是我们的id生成器开始使用的时间，由我们程序来指定的（如下下面程序IdWorker类的startTime属性）。41位的时间截，可以使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69
 * 10位的数据机器位，可以部署在1024个节点，包括5位datacenterId和5位workerId
 * 12位序列，毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号
 * 加起来刚好64位，为一个Long型。
 * SnowFlake的优点是，整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分)，并且效率较高，经测试，SnowFlake每秒能够产生26万ID左右。
 */
public class SnowflakeIdWorker {
 
    // ==============================Fields===========================================
    /**
     * 开始时间截 (2020-11-03，一旦确定不可更改，否则时间被回调，或者改变，可能会造成id重复或冲突)
     */
    private final long twepoch = 1604374294980L;
 
    /**
     * 机器id所占的位数
     */
    private final long workerIdBits = 5L;
 
    /**
     * 数据标识id所占的位数
     */
    private final long datacenterIdBits = 5L;
 
    /**
     * 支持的最大机器id，结果是31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数)
     */
    private final long maxWorkerId = -1L ^ (-1L << workerIdBits);
 
    /**
     * 支持的最大数据标识id，结果是31
     */
    private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
 
    /**
     * 序列在id中占的位数
     */
    private final long sequenceBits = 12L;
 
    /**
     * 机器ID向左移12位
     */
    private final long workerIdShift = sequenceBits;
 
    /**
     * 数据标识id向左移17位(12+5)
     */
    private final long datacenterIdShift = sequenceBits + workerIdBits;
 
    /**
     * 时间截向左移22位(5+5+12)
     */
    private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
 
    /**
     * 生成序列的掩码，这里为4095 (0b111111111111=0xfff=4095)
     */
    private final long sequenceMask = -1L ^ (-1L << sequenceBits);
 
    /**
     * 工作机器ID(0~31)
     */
    private long workerId;
 
    /**
     * 数据中心ID(0~31)
     */
    private long datacenterId;
 
    /**
     * 毫秒内序列(0~4095)
     */
    private long sequence = 0L;
 
    /**
     * 上次生成ID的时间截
     */
    private long lastTimestamp = -1L;
 
    //==============================Constructors=====================================
 
    /**
     * 构造函数
     *
     */
    public SnowflakeIdWorker() {
        this.workerId = 0L;
        this.datacenterId = 0L;
    }
 
    /**
     * 构造函数
     *
     * @param workerId     工作ID (0~31)
     * @param datacenterId 数据中心ID (0~31)
     */
    public SnowflakeIdWorker(long workerId, long datacenterId) {
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
        }
        if (datacenterId > maxDatacenterId || datacenterId < 0) {
            throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
        }
        this.workerId = workerId;
        this.datacenterId = datacenterId;
    }
 
    // ==============================Methods==========================================
 
    /**
     * 获得下一个ID (该方法是线程安全的)
     *
     * @return SnowflakeId
     */
    public synchronized long nextId() {
        long timestamp = timeGen();
 
        //如果当前时间小于上一次ID生成的时间戳，说明系统时钟回退过这个时候应当抛出异常
        if (timestamp < lastTimestamp) {
            throw new RuntimeException(
                    String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
        }
 
        //如果是同一时间生成的，则进行毫秒内序列
        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & sequenceMask;
            //毫秒内序列溢出
            if (sequence == 0) {
                //阻塞到下一个毫秒,获得新的时间戳
                timestamp = tilNextMillis(lastTimestamp);
            }
        }
        //时间戳改变，毫秒内序列重置
        else {
            sequence = 0L;
        }
 
        //上次生成ID的时间截
        lastTimestamp = timestamp;
 
        //移位并通过或运算拼到一起组成64位的ID
        return ((timestamp - twepoch) << timestampLeftShift) //
                | (datacenterId << datacenterIdShift) //
                | (workerId << workerIdShift) //
                | sequence;
    }
 
    /**
     * 阻塞到下一个毫秒，直到获得新的时间戳
     *
     * @param lastTimestamp 上次生成ID的时间截
     * @return 当前时间戳
     */
    protected long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }
 
    /**
     * 返回以毫秒为单位的当前时间
     *
     * @return 当前时间(毫秒)
     */
    protected long timeGen() {
        return System.currentTimeMillis();
    }
 
    /**
     * 随机id生成，使用雪花算法
     *
     * @return
     */
    public static String getSnowId() {
        SnowflakeIdWorker sf = new SnowflakeIdWorker();
        String id = String.valueOf(sf.nextId());
        return id;
    }
 
    //=========================================Test=========================================
 
    /**
     * 测试
     */
    public static void main(String[] args) {
        SnowflakeIdWorker idWorker = new SnowflakeIdWorker(0, 0);
        for (int i = 0; i < 1000; i++) {
            long id = idWorker.nextId();
            System.out.println(id);
        }
    }
}

实际生产环境中我们应该怎么来应用雪花算法来实现分布式ID。

imagepng

时针回拨问题【20：28 --》20：26】 【20：28 --》 20：30】

imagepng

三、分布式id生成案例

1、百度(Uidgenerator) 源码 文档

2、美团(Leaf) 源码 文档

3、滴滴(TinyID) 源码 文档

posted @   xiangliheart  阅读(166)  评论(0)  编辑  收藏  举报
相关博文：
· 【java八股问】Redis
· 【java八股问】Redis面试题
· [Java/数据库] 分布式ID
· 一文详解分布式 ID
· 生成分布式ID的四种常见方案对比
阅读排行：
· 阿里最新开源QwQ-32B，效果媲美deepseek-r1满血版，部署成本又又又降低了！
· 单线程的Redis速度为什么快？
· SQL Server 2025 AI相关能力初探
· AI编程工具终极对决：字节Trae VS Cursor，谁才是开发者新宠？
· 展开说说关于C#中ORM框架的用法！
点击右上角即可分享
微信分享提示