# 批量发号突然发重号：雪花ID时钟回拨、号段预取与步长耗尽补号的完整流程

上周二早上八点半，我刚到公司泡好茶，运营群里就炸了：批量发号任务跑了一晚上，早上对账时发现有 1200 多个号段重复发出去了，客户那边已经拿着重号在查。"你这发的号怎么跟昨天那批撞上了？"客户电话直接打过来。我盯着日志看了十分钟，才定位到是服务器重启后时钟回拨踩了雪花算法的坑。

这事前后排查了三天，把发号服务的时钟同步、号段预取和补号逻辑整个重写了一遍。记录下来，给同样在做批量发号的同学参考。

## 一、问题定位：重号不是随机，是时钟往回跳了

雪花 ID 的结构是 1 位符号位 + 41 位时间戳 + 10 位工作节点 + 12 位序列号。理论上同一毫秒内同一节点最多生成 4096 个不重复 ID，跨毫秒靠时间戳单调递增保证不重。

问题出在这台服务器昨晚做了一次 NTP 校时：原来系统时间比标准时间快了 38 秒，NTP 一次拉回来后，系统时钟往回跳了 38 秒。雪花算法用 `(now - twepoch) << 22` 算前缀，时钟一回拨，新生成的 ID 时间戳前缀就跟回拨前已经发出去的那段撞上了。

先在日志里验证：

```txt
grep "clock moved backwards" /var/log/biz/snower.log
# 2026-10-07 02:13:44 WARN  clock moved backwards, refusal 38120 ms
```

果然，凌晨两点十三分有一条时钟回拨告警，但发号服务当时没做拦截，直接继续发了，就重了。

## 二、修复一：时钟回拨检测与拒绝策略

第一版修复最直接：检测到回拨就拒绝发号。代码里是这么处理的：

```txt
// 伪代码：nextId() 开头
long currentMillis = timeGen();
if (currentMillis < lastTimestamp) {
    long offset = lastTimestamp - currentMillis;
    if (offset <= 5) {
        // 回拨在5ms以内，sleep等过去
        threadWait(offset << 1);
        currentMillis = timeGen();
    } else {
        throw new RuntimeException("clock moved backwards " + offset + "ms, refuse to gen id");
    }
}
if (currentMillis == lastTimestamp) {
    sequence = (sequence + 1) & 4095;
    if (sequence == 0) {
        currentMillis = tilNextMillis(lastTimestamp);
    }
} else {
    sequence = 0;
}
```

这里定的阈值是 5ms：小回拨（NTP 微调）睡一下等时钟追回来，大回拨直接抛异常让上游重试。凌晨那次回拨 38 秒，直接抛错，发号任务失败告警，人工介入补号，比悄悄发重号强。

## 三、修复二：号段模式预取，库里持久化不丢号

我们发的业务号不是纯雪花 ID，而是带业务前缀的号段：每个业务线一次从数据库预取一段（比如 1-10000），内存里自增发完了再取下一段。表结构长这样：

```txt
CREATE TABLE id_segment (
    biz_tag     VARCHAR(64) PRIMARY KEY,
    max_id      BIGINT NOT NULL,
    step        INT    NOT NULL,
    update_time DATETIME
);
-- 更新号段：UPDATE id_segment SET max_id = max_id + step WHERE biz_tag = ?
```

这里踩过一个坑：预取号段时内存占着 1-10000，数据库 max_id 已经推到 10001，结果服务宕机，内存里发了 6000 就没了，6001-10000 这段直接浪费。量小无所谓，量大一天浪费几十万号。

后来改成双 buffer：内存里始终备着两段，一段发完无缝切另一段，同时异步去数据库预取下一段。崩溃最坏只丢半段。

## 四、修复三：补号流程与对账

重号发出去的 1200 个，得有补号流程兜底：

1. 按 biz_tag 拉出重号区间，写一份补发清单；
2. 从 max_id 往后顺延一个步长（step=10000）开新段，旧段作废；
3. 补号前先跟客户系统核对：哪些重号已经被使用、哪些还能回收，别直接覆盖；
4. 补号任务走单独的慢队列，限速每秒 200 个，别跟正常发号抢线程。

## 五、踩坑清单（5 条实际踩过的）

1. NTP 校时别用"一次性大步长"，配成 slew 模式（ntpd -x），小步渐进校准，避免秒级回拨。
2. 雪花节点 ID 别写死，多实例时容易重复；用 ZK 顺序节点或 K8s StatefulSet 序号分配。
3. 号段表 UPDATE 要走行锁，别先 SELECT 再 UPDATE，高并发下两个实例会取到同一段。
4. 序列号掩码用 `& 4095`，别写 `% 4096`，位运算在热点路径上快一个量级。
5. 发号接口必须做幂等：上游重试时带 requestId，同 requestId 直接返回上次的号，别重复发。

| 策略 | 重号风险 | 性能 | 适用场景 |
|---|---|---|---|
| 纯雪花 ID | 时钟回拨时会重 | 极高，无网络开销 | 订单号、流水号 |
| 数据库号段 | 宕机丢半段 | 高，本地自增 | 业务号码、券码 |
| 号段+雪花混合 | 双保险 | 高 | 大规模批量发号 |

这次批量发号任务是在固乔快递批量查询助手的后台批量任务模块上做的，我主要负责把发号接口从单机雪花改成号段预取+时钟回拨拦截那套逻辑，改完后压测 50 万发号零重号，连续跑了三天对账也没再撞号。

## 复盘

- 时钟回拨是分布式 ID 最容易被忽略的坑，NTP 校时一定要配 slew 模式并在发号代码里做拦截。
- 号段模式比纯雪花更适合业务号码，但要做好双 buffer 预取和宕机丢号的估算。
- 重号发生后补号流程比预防更重要，先对账再补发，别直接覆盖客户已用的数据。

以上是个人实践记录，各平台具体功能以官方实时信息为准。

大家做批量发号时，遇到时钟回拨是直接拒绝发号，还是有更优雅的自动恢复方案？


上周二早上八点半，我刚到公司泡好茶，运营群里就炸了：批量发号任务跑了一晚上，早上对账时发现有 1200 多个号段重复发出去了，客户那边已经拿着重号在查。"你这发的号怎么跟昨天那批撞上了？"客户电话直接打过来。我盯着日志看了十分钟，才定位到是服务器重启后时钟回拨踩了雪花算法的坑。

批量发号突然发重号：雪花ID时钟回拨、号段预取与步长耗尽补号的完整流程

后端

架构设计

数据库

批量发号重号问题根因是服务器NTP校时引发雪花ID时钟回拨38秒，导致ID前缀冲突。解决方案包括：时钟回拨拦截、数据库号段双buffer预取、补号对账流程。推荐号段+雪花混合模式兼顾安全与性能，压测50万发号零重号，连续三天无重复。

代码解释

服务器

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

批量发号突然发重号：雪花ID时钟回拨、号段预取与步长耗尽补号的完整流程-腾讯云开发者社区-腾讯云

批量发号突然发重号：雪花ID时钟回拨、号段预取与步长耗尽补号的完整流程

批量发号突然发重号：雪花ID时钟回拨、号段预取与步长耗尽补号的完整流程

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐