雪花算法ID重复了惨痛教训请勿轻易造轮子先交代一下背景。我去年接手的一个内部项目分布式ID用的是一套“自己实现的雪花算法”代码不复杂压测也过了上线初期一切正常。结果某天晚上数据库开始疯狂报主键冲突系统直接刷屏告警。排查到凌晨两点最终把问题定位到雪花算法生成的ID重复上。那段时间我翻遍了网上关于雪花算法的资料又读了一遍美团的Leaf、百度的UidGenerator等开源实现的源码才彻底弄明白问题到底出在哪。这个经历给我最大的启发是雪花算法看着简单但真正要落地到生产环境坑比想象中多得多尤其是在时钟、节点配置、并发边界这些“隐藏条件”上只要有一个没处理好ID重复就是必然。如果你也在用自己实现的雪花算法或者正准备为分布式ID“造一个轻量轮子”这篇内容值得你花十分钟看完。我会把事故发生、排查思路、原理拆解、可行方案以及最终沉淀下来的工程经验全部讲清楚。1. 事故还原从一次深夜主键冲突说起1.1 压测顺利、上线翻车我们的系统是一个面向内部业务的订单中台原来的主键是数据库自增ID。随着业务量上涨多个服务实例同时写库的场景越来越多自增ID在跨库合并、分表拆分时非常不方便于是团队决定引入分布式ID。当时没有直接采用开源组件理由也说得过去团队里一位同事认为雪花算法实现非常简单网上几十行代码到处都是没必要为了一个“生成ID的小功能”引入额外中间件依赖。他基于网上最常见的Java版雪花算法稍微改了一下做成一个工具类用static方法直接调用。压测阶段确实没有暴露问题。因为压测环境是单机部署同一毫秒内并发量也没有超过序列号的上限ID看起来完全正常。系统上线后前两周也风平浪静直到那天晚上流量稍微上来一点数据库就连续抛出Duplicate entry 1357234098019016704 for key PRIMARY我第一反应是“数据写重了”可能是接口幂等没做好或者消息队列重复消费。后来发现纯粹是主键ID撞了才把方向转到ID生成器上。1.2 排查过程复盘排查的第一件事是找到重复的ID到底长什么样。我从数据库慢日志和错误日志里捞出了一批重复的主键发现重复ID并不连续而且不是简单的一条记录重复出现两次而是“两条不同记录的ID相同同时插入时被唯一索引拦截”。接着我写了脚本把雪花ID按位拆开解析出时间戳、机器ID和序列号。结果一看就发现问题了重复ID的时间戳部分竟然不是递增的而是出现了“回退”。也就是说ID生成器在某段时间内拿到的时间比它之前生成ID时拿到的时间还要早。再加上另一个致命问题我们生产环境有多个服务实例但所有实例的workerId机器ID都配置成了同一个值用的是同一个静态配置文件。这就意味着在不同实例各自生成ID时一旦时间戳回退到同一个毫秒并且序列号又从0开始那么生成的ID就会一模一样。1.3 最终定位时钟回拨加workerId共用复盘下来问题非常清晰时钟回拨生产环境服务器在半夜执行了NTP时间同步系统时间往前跳了几百毫秒。虽然时间不长但足够让新生成的ID的时间戳和之前的某个ID重叠。workerId冲突所有实例的workerId是硬编码的同一个值导致不同机器生成的ID无法通过机器位区分。序列号重置时间戳回退后同一毫秒内序号从0重新计数进一步放大了重复概率。这三条合在一起任何一条单独出现都只是隐患三条同时出现就直接炸了。雪花算法ID重复本质上不是算法本身的问题而是实现和部署时没有满足算法的适用前提。2. 雪花算法为什么被默认“不会重复”2.1 64位设计拆解要理解为什么会出现重复先得弄清楚雪花算法ID的结构。一个标准的64位long型ID从左往右分成四段1位符号位固定为0不用。41位时间戳记录相对于某个自定义纪元epoch的毫秒偏移量。10位机器ID用来区分不同节点最多支持1024个节点。12位序列号用于同一毫秒内区分不同ID单节点单毫秒最多4096个。用Java代码来表示最常见的长这样public class SnowflakeIdWorker { // 自定义纪元比如2023-01-01 00:00:00 private final long epoch 1672531200000L; private final long workerIdBits 10L; private final long sequenceBits 12L; private final long workerIdShift sequenceBits; // 12 private final long timestampShift sequenceBits workerIdBits; // 22 private final long sequenceMask ~(-1L sequenceBits); // 4095 private long workerId; private long sequence 0L; private long lastTimestamp -1L; public synchronized long nextId() { long timestamp System.currentTimeMillis(); if (timestamp lastTimestamp) { // 时钟回拨处理很多自研代码这里只是抛异常或等待 throw new RuntimeException(Clock moved backwards); } if (timestamp lastTimestamp) { sequence (sequence 1) sequenceMask; if (sequence 0) { timestamp tilNextMillis(lastTimestamp); } } else { sequence 0L; } lastTimestamp timestamp; return ((timestamp - epoch) timestampShift) | (workerId workerIdShift) | sequence; } private long tilNextMillis(long lastTimestamp) { long timestamp System.currentTimeMillis(); while (timestamp lastTimestamp) { timestamp System.currentTimeMillis(); } return timestamp; } }很多人觉得这段代码已经够完整了但恰恰是那个throw new RuntimeException(Clock moved backwards)在生产环境里就是一颗定时炸弹。2.2 数学期望下的重复概率在没有任何异常的情况下雪花算法能保证多少年不重复我们来算一下。41位时间戳单位是毫秒总共能表示的时间范围是2^41 毫秒 ≈ 2.2 * 10^12 毫秒 ≈ 69.7 年如果你把纪元设置在2023年那么大概能用到2092年一般业务系统活不了这么久。单节点单毫秒能生成4096个ID也就是每秒约409.6万个ID对绝大多数系统来说绰绰有余。假设你部署了1024个节点每个节点每毫秒最多生成4096个ID那么系统理论上的极速是每秒约42亿个ID。所以从数学期望上看只要所有节点的时间同步、workerId不冲突、同一毫秒内的序列号不溢出雪花算法生成的ID确实不会重复。这也是为什么它被称为“全球唯一ID生成方案”之一。2.3 “不重复”的三个前提条件但请注意数学期望成立有三个隐含的前提条件第一时间必须单调递增。任何形式的回拨哪怕只有几毫秒都会让新ID的时间戳和旧ID重叠。第二同一毫秒内序列号必须连续且不重叠。如果在时间戳相同的情况下序列号从0重新开始就会复用一个已经生成的ID。第三每个节点必须有唯一的workerId。如果两个节点用同一个workerId恰好又在同一毫秒内生成ID序列号也相同那就完全冲突了。这三个条件看起来都容易满足但生产环境的复杂程度远超想象NTP同步会导致时间跳变容器化部署可能导致workerId配置遗漏热点流量可能让单毫秒序列号爆掉……每一个“万一”都真实存在。3. 自己实现时真正会踩的坑3.1 时钟回拨是最阴的坑先说我在这次事故里踩的最大的坑时钟回拨。生产环境里的服务器都会通过NTP网络时间协议定期校准系统时间。如果你的服务器时间快了校准后时间会往回拨如果服务器时间慢了会往前跳。往前跳问题不大往回拨才是灾难。举个例子假设你的服务器真实时间比系统时间慢了500毫秒NTP校准后系统时间从12:00:00.250跳到了11:59:59.750。这时候你调用System.currentTimeMillis()拿到的时间戳比之前生成ID时还要小。如果你没有对回拨做处理就会生成一个“过去的时间戳”的ID。如果恰好在同一毫秒内生成序列号又从0开始那么生成的ID就会和之前某个ID完全一样。常见的处理思路有这么几种回拨时间小于阈值比如5秒以内就等待系统时间追上来而不是直接抛异常。回拨时间较大拒绝生成ID抛出异常并告警。用Redis或数据库记录最近生成的ID作为兜底判断。生成ID时时间戳不直接用系统时间而是用“上一毫秒1”和“当前系统时间”中较大的那个保证单调递增。但说实话这些方案都是在打补丁。真正稳妥的做法是直接使用已经处理过这些边界情况的开源实现而不是自己重写。3.2 workerId分配与配置问题第二个坑是workerId。标准的10位workerId可以支持1024个节点但你得保证每个节点拿到的workerId是唯一的。很多自研实现都是把workerId写在配置文件里部署时每台机器手动改一个值。只要有一台机器忘改或者配置管理平台下发错了就可能出现两个节点共用同一个workerId。更隐蔽的情况是容器化部署。比如同一个镜像在Kubernetes集群里起了4个副本如果workerId是写死在环境变量里的没有通过StatefulSet的有序索引或注册中心动态分配那4个Pod的workerId就是一样的。这种情况下只要两个Pod在同一毫秒生成ID序列号也都相同ID就必然重复。正确的做法是用注册中心如ZooKeeper、Etcd自动分配workerId或者从数据库的配置表中获取一个自增的节点编号。美团Leaf的实现里就接入了ZooKeeper在节点启动时自动注册并获得一个唯一ID。3.3 位运算和序列号边界的细节还有一类问题出在编码实现上不仔细看很容易漏掉。一是移位运算的位数。标准算法中符号位1位、时间戳41位、机器ID 10位、序列号12位所以时间戳左移22位机器ID左移12位序列号不用移。如果移位数写错了比如把机器ID左移了13位那生成出来的ID结构就是乱的虽然表面上不重复但很难从ID反推出时间和机器信息。二是序列号掩码。sequenceMask ~(-1L sequenceBits)也就是4095。当sequence增长到4096时和4095做与运算会变成0表示该毫秒内的序列号已经用完需要等待下一秒再生成。如果代码里没有处理这个边界甚至把序列号直接而不做掩码那么序列号会超出12位溢出到机器ID或时间戳的位置导致ID结构错乱。三是并发控制。雪花算法的nextId()必须是线程安全的否则多个线程同时拿走同一个时间戳和序列号就会生成完全相同的ID。常见的实现是用synchronized、AtomicLong或ReentrantLock。我见过有人把核心方法写成了无锁版本压测时并发一上就直接生成了重复ID。3.4 部署环境与long精度问题还有一个容易被忽略的问题是前端精度。雪花ID是一个long类型的64位整数在Java里没问题但如果后端直接把ID以数值类型返回给前端JavaScript就会出问题。JavaScript的Number类型最多只能安全表示2^53-1以内的整数而雪花ID动辄就是19位大数超出这个范围后精度会丢失。表现就是前后端联调时前端拿到的ID和后端生成的ID后几位不一样看起来就像“多了几个ID”。这时候如果你再用前端回传的ID去查数据库就会查不到数据。排查半天还以为是ID重复其实只是精度丢了。解决方案很简单后端返回JSON时把雪花ID转成字符串。或者干脆在数据库层面用bigint存前端用字符串接收。这个坑如果你没见过非常容易被误判成“算法生成错误”。4. ID重复的排查与反解方法4.1 先别甩锅给雪花算法我在排查这次故障时最大的教训是遇到主键冲突先别急着怪ID生成器。数据库的主键重复还有几个常见的非雪花原因第一业务层没有做幂等消息队列重复消费或接口重试导致同一条数据插入了两次。第二数据迁移时没有清理主键新旧数据的主键范围发生了重叠。第三使用了数据库自增ID但自增步长配置成了“按实例编号偏移”多实例写库时出现了死锁或重复。所以排查时要学会“隔离变量”。我的做法是先把重复的ID捞出来用脚本把ID拆开看时间戳、机器ID和序列号是否正常。如果重复ID的机器位相同、时间戳相同、序列号不同那基本就是序列号的问题如果时间戳相同、机器位也相同、序列号也相同那就是完完全全的撞车问题大概率出在时钟回拨或workerId配置上。4.2 从ID反解时间戳和机器位假设你拿到了一个雪花ID比如1357234098019016704怎么把它拆开看呢很简单按位运算还原即可。public void parseSnowflakeId(long id) { long sequence id 4095L; long workerId (id 12) 1023L; long timestamp (id 22) 1672531200000L; // 加上自定义纪元 System.out.println(timestamp: timestamp); System.out.println(workerId: workerId); System.out.println(sequence: sequence); }如果是Python环境也可以这样def parse_snowflake(snow_id: int, epoch: int 1672531200000): sequence snow_id 4095 worker_id (snow_id 12) 1023 timestamp (snow_id 22) epoch print(ftimestamp: {timestamp}) print(fworkerId: {worker_id}) print(fsequence: {sequence})我当时就是用这个脚本把数据库里所有重复ID拆开然后统计了它们的分布。结果发现所有重复ID的workerId都相同时间戳都落在NTP同步前后的那几百毫秒内。这就是铁证。4.3 验证与修复定位到根因后修复方案并不复杂先把所有实例的workerId改成全局唯一我用了一个临时方案从数据库中读取一个自增编号作为workerId。然后把时钟回拨处理改成“等待系统时间追上来再生成”而不是直接抛异常或忽略。最后在ID生成器外层加了一层Redis缓存兜底每次生成ID时把最近N条ID存进Redis生成前先查一下是否重复。这套修复上线后问题没有再出现过但整个过程让我意识到一个更严重的问题自研雪花算法的成本远不止写那几十行代码还包括对时钟、容错、并发、部署等各种边界的处理。而这些边界恰恰是开源实现已经替你踩过坑的地方。5. 工程上不要再“造轮子”的做法5.1 成熟方案的选型对比经过这次事故后我的态度很明确能用开源的绝不自己写。如果只是需要一个分布式ID生成器市面上已经有很多非常成熟的方案完全没必要重复造轮子。下面是我个人在选型时参考过的一些对比方案类型特点适用场景美团Leaf号段模式 雪花算法支持雪花模式自带ZooKeeper注册解决时钟回拨大规模集群、需要动态分配workerId百度UidGenerator雪花算法的变体可按业务自定义位段分配缓解时钟回拨对ID结构有定制需求滴滴Tinyid数据库号段模式纯号段方案无时间戳无回拨问题对ID结构不敏感、低延迟MongoDB的ObjectId12字节方案无序但唯一适合不依赖时间排序的场景文档型数据存储UUID / ULID简单字符串/26字节几乎无部署成本但空间大、不可排序低频写、弱查询如果你在做一个高并发、大数据量、需要时间有序性的系统美团Leaf是我个人最推荐直接参考的。它的源码里对时钟回拨、节点注册、ID生成状态的考核都设计得很完整拿来即用而且经过大规模生产验证。5.2 一定要自研时的底线如果因为特殊原因比如公司技术栈限制、不能引入额外中间件、征研需求非要自己实现请你至少守住以下几条底线第一workerId不能硬编码。启动时必须从环境变量、配置中心或注册中心获取且全局唯一。第二必须处理时钟回拨。不要在检测到回拨时直接抛异常更不要静默忽略。最好的做法是异步等待系统时间追上来同时把回拨情况记录到日志和监控里。第三生成方法必须线程安全。用synchronized或者AtomicLong保证同一时刻只有一个线程能够获取序号。第四序列号必须用掩码限制在12位以内。一旦同一毫秒内的4096个序号用完要主动等待下一毫秒。第五对外暴露时所有接口都要把ID转成字符串返回避免前端Number精度丢失。第六增加可观测性。ID生成器要能暴露出当前时间戳、workerId、序列号使用率等指标方便在异常出现时快速定位。5.3 写在事故复盘里的检查清单最后分享一个我们团队在事故复盘后沉淀的检查清单。无论你用自研方案还是开源方案上线前都对照着过一遍[ ] workerId是否全局唯一多实例部署时是否做过校验[ ] 时钟回拨的处理逻辑是“等待/补偿”还是“直接抛异常”[ ] 同一毫秒内序列号耗尽后是否会出现循环或溢出[ ] 高并发压测是否覆盖了多实例、多线程、长时间持续运行的场景[ ] 前端接收ID时是否用了字符串类型[ ] 是否有监控指标及时发现ID重复[ ] 是否明确知道方案在你预期使用年限内的容量上限这些问题每一条背后都对应着一次真实的故障案例不是纸上谈兵。雪花算法本身没有错错的是把一个需要严谨工程化考量的“算法”当成一段“写一遍就能用”的代码。我用这次凌晨的加班换来了一个经验分布式ID生成器它远看是个工具类近看是一个分布式系统里最基础的基石之一值得你用最高规格去对待它。我个人在实际操作中还有个习惯事故复盘之后我会把这类容易踩坑的清单留在团队Wiki首页每次新项目做技术选型时都拿出来对照一遍。做一个“会总结、肯沉淀”的工程师比写出多少行代码都重要。这算是这次惨痛教训里我收获最大的一点。