当前位置：首页 > article >正文

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

article 2026/3/18 3:42:39

在这里插入图片描述
对于分布式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;}

具体原理其实就是当前时间戳-制定时间 << 32 | 自增的id 这样输出的就是连续的id了

雪花算法

雪花算法整体结构就是 64位 0-41位位毫秒值，5位是数据中心id，5位机器id，最后12位是毫秒级别内的自增id
在这里插入图片描述

分析源码可以大概了解其核心流程
在这里插入图片描述

雪花算法时钟回拨

在实际的生产环境中，分布式环境下，其实时钟是很难保证统一的，所以就可能实现时间不一样的情况，导致时钟回拨问题，我们来分析两类问题

情况1:UTC时间是8点01，实例机器是8点整
情况2:UTC时间是8点01 实例机器是8点03

对于情况1来说，其实就调整一下时间就好，1分钟内的id生成不用就可以。但是对于第二种情况，相当于需要从3分回退到01分，那么其中的2分钟的时间已经生成了对应的id，如果在次生成，就会出现id重复的问题？

如何解决呢
其实比较简单，大方向就是如果时间短，那么就等得阻塞对应的时间就可以，如果超过1S以上，服务直接下线，通过其他实例获取id就可以。
在这里插入图片描述

其他

业界有主流的其他方案，具体可以详细看
百度、美团对应的解决方案，这里自己查看对应文档就可以。

总结

从上面的分析可以知道目前业界主流的方案，我们来抽丝剥茧下，对于设计一个分布式id来说，需要哪些核心点
1.需要顺序这样可以简单清晰
2.依赖的服务需要高可用、高性能
3.全局唯一
4.有具体的业务含义，比如针对订单号：11xxx 开始，还款订单21xxx，借款订单31xxx。就比较清晰。