【分布式】聊聊分布式id实现方案和生产经验

news2025/3/10 19:48:07

在这里插入图片描述
对于分布式Id来说，在面试过程中也是高频面试题，所以主要针对分布式id实现方案进行详细分析下。

应用场景

对于无论是单机还是分布式系统来说，对于很多场景需要全局唯一ID，

数据库id唯一性
日志traceId 可以方便找到日志链，一般使用uuid 更多一点
幂等场景下，mq、api接口层面保证幂等下
业务系统订单id

UUID

最简单的就是使用UUID，UUID的规则是一组32位16进制数字构成，形式就是8-4-4-4-8，主要就是利用当前时间和时钟序列和全局唯一的IEEE机器识别。

UUID uuid = UUID.randomUUID();

307e16d0-26d4-4fff-ab06-a9397b8369fb

优点：实现简单，全局唯一，缺点是不具有连续性，并且占用空间比较大，对于mysql主键来说不具备友好。

数据库自增ID

就目前公司内部，其实还是使用的数据库自增id进行处理，对于数据库来说的话，就是多个实例操作表自增id，对于业务来说使用自定义时间戳来实现。

还有一种方式就是创建一个单独的表，通过数据库本身的自增id来保证。

CREATE TABLE `test_order_id`  (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `title` char(1) NOT NULL,
  PRIMARY KEY (`id`),
    UNIQUE KEY `title` (`title`)
) ENGINE = InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET =utf8;

BEGIN;

REPLACE INTO test_order_id (title) values ('p') ;
SELECT LAST_INSERT_ID();

COMMIT;

这种方式的优点就是实现比较简单，但是缺点就是不具备高可用性，如果mysql是单节点部署的话，那么整体就不可用。

高可用数据库实例

部署多个数据库实例，通过设置不同的自增，比如mysql实例1，自增是2，从1开始，mysql实例2 从2开始，那么就是实例1 ： 1、3、5、7，实例2: 2、4、6、8。

对于并发量不高的场景来说，可以解决，但是对于高并发场景来说，数据库实例就是成为瓶颈。如果1秒1000个订单，那么就需要频繁访问1000次数据库，显然这个网络以及IO就成为短板。

号段模型

号段模式，其实就是通过在一个表中唯一一条记录，然后通过业务区分，每次获取一个区间的号，这样比如获取1-1000的号段，那么就只需要交互一次数据库，并且通过添加version来避免出现并发修改数据的问题。
在这里插入图片描述

Redis

除了借助于mysql，还可以通过redis的自增 incr命令来实现自增ID，并且可以部署一主多从的架构，来保证高可用性。

    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;
    }