雪花算法ID重复了？惨痛教训：请勿轻易造轮子！

最近我们线上系统发生了一起严重事故：订单号/流水号出现了重复，影响了核心业务流程。最终定位到根源：一个自研的二方包雪花算法ID生成器出现了问题。

下面我们来回顾一下雪花算法的标准结构，分析问题出在哪，并总结一些通用的设计建议。

一、标准雪花算法（Snowflake）

标准的Snowflake ID由一个64位long型整数构成：

txt

代码解读

复制代码

+----------------------------------------------------------------------------------------------------+ | 1 Bit | 41 Bits 时间戳 | 5 Bits 数据中心ID | 5 Bits 机器ID | 12 Bits 序列号 | +----------------------------------------------------------------------------------------------------+

• 1位符号位：始终为0，确保生成正数。
• 41位时间戳：记录与固定起始时间的毫秒差，可支持约69年。
• 10位机器ID：用于标识不同节点。
• 12位序列号：在同一毫秒内生成多个ID时使用，最多支持每毫秒生成4096个ID。

优点：

• 高性能生成唯一ID，按时间有序，适用于分布式环境。

二、我们的“定制版”雪花算法：问题在哪？

我们使用的二方包雪花算法结构如下（根据排查推测）：

txt

代码解读

复制代码

+----------------------------------------------------------------------------------------------------+ | 31 Bits 时间戳Delta | 13 Bits 数据中心ID | 4 Bits 工作ID | 8 Bits 业务ID | 8 Bits 序列号 | +----------------------------------------------------------------------------------------------------+

看起来字段丰富，但存在严重问题：

1. 时间戳仅保留31位，最多支持24.85天！

• 左移33位后只用31位时间戳，
• 超过 2312^{31}231 毫秒后开始循环，
• 我们自定义的起始时间是2018年，2025年时早已绕了无数圈。

2. BusinessId 用的是 IP 最后一段

• 使用的IPy用点分隔的最后一位，即192.168.0.1的1，极容易重复。

3. WorkId 和 DataCenterId 未配置，全为0

• 相当于所有实例共享同一节点标识，唯一性形同虚设。

最终结果：时间轮回 + IP冲突 + 序列重复，ID彻底撞车。

三、教训总结

核心组件不建议自研

• 雪花算法涉及时钟回拨、位运算、分布式协调等关键细节，成熟组件更稳妥。

不盲信二方包

• 无论谁写的代码，都要看清实现逻辑，理解其唯一性保障机制。

合理设置机器ID

• 靠IP后缀太脆弱，建议集中规划，统一分配Worker ID和DataCenter ID。

提前覆盖边界场景

• 模拟长时间运行、序列号溢出、时间回拨等极端情况，确保系统稳健。

四、推荐做法

使用成熟的开源实现，如 Hutool、Baomidou 等：

java

代码解读

复制代码

// Hutool 示例 Snowflake snowflake = IdUtil.getSnowflake(1, 1); long id = snowflake.nextId(); // Baomidou 示例（支持从 IP/MAC 自动推导，也可手动指定） DefaultIdentifierGenerator generator = new DefaultIdentifierGenerator(1, 1); // workerId=1, dataCenterId=1 long id = generator.nextId("user");

对于中大型系统，DataCenterId 一般用来标识不同的机房或者 AZ (Availability Zone)。

WorkerId 的配置策略可以根据系统规模逐步演进：

• 简单方式：通过配置文件手动指定。这种方式配置简便，适用于开发环境或单机部署。

• 标准方式：将 IP 与端口号（或进程号）拼接后进行哈希，再对 WorkerId 总数取模。具备一定自动化能力，不依赖外部系统，适用于中小规模部署。

• 中级方案：依赖注册中心（如 Eureka、Nacos），在服务注册时分配编号，结合服务ID保障唯一性。

• 高级方案：使用 Redis、Zookeeper 等集中协调 WorkerId 分配与释放，支持动态扩容、避免冲突。

随着系统规模扩大，推荐逐步引入更复杂但更稳妥的机制，避免一开始就过度设计。

五、其它建议：不要将业务标志拼入ID中

有时我们为了确保唯一性，会试图将业务信息（如类型前缀、模块编号）拼接进ID。但这种做法会带来一系列问题：

• 会导致 ID 非全数字，失去原本按时间递增的排序特性，影响数据库索引效率；
• ID长度变得不规则或偏长，可能增加存储成本，也会影响日志展示、用户体验；
• 若业务字段含义变动，还可能造成数据兼容性问题。

更稳妥的做法是将业务字段单独存储，ID仅用于唯一标识和排序。

六、结语

别为造轮子而造轮子，尤其在基础组件上，不可抱侥幸心理。

如果你也有雪花算法的踩坑经验，欢迎交流分享！