分布式 ID 与时钟：雪花算法、号段模式与时钟回拨

本文讲清单机自增ID到了分布式环境为什么会失效，主流生成方案的取舍，以及"时间"这个看似免费的依赖如何反过来坑你。

为什么不能继续用数据库自增？

单机：AUTO_INCREMENT / sequence 一把梭，有序、唯一、省心。
分布式后四个死穴：
  1. 多库多主各自自增 → 全局撞号（步长方案运维痛苦且扩容难）
  2. 分库分表后路由依赖 ID → ID 必须全局唯一且能携带分片信息
  3. 性能：INSERT 抢数据库锁，写入 QPS 上不去
  4. 暴露商业信息：连续订单号让人猜出你一天多少单（枚举漏洞）

合格分布式 ID 的需求：
  全局唯一 | 趋势递增（对 B+ 树索引友好）| 高吞吐低延迟
  可嵌入业务含义（分片位/租户位）| 不依赖单点

方案全景

美团 Leaf 的思路（号段 + 雪花双模式）

Leaf-segment（号段）：
  DB 表 alloc(max_id, step)，每台机器一次取一段（如 1 万号），
  用完再取下一段 → DB QPS = 发号量/step
  双 buffer 预取：当前段用到 10% 时异步加载下一段，
  避免"取号瞬间抖动"（旧方案换号段时全量阻塞的痛点）

Leaf-snowflake：
  不靠机器 IP/物理部署，而是用 ZooKeeper 顺序节点给每个实例
  分配唯一 workerID，宕机自动释放 → 解决"机器位怎么分配"的运维难题
  时钟回拨时直接拒绝发号或切换备用号段引擎

雪花算法拆透

64 bit 布局（Twitter 原版）：

 0 | 41 bit 时间戳(毫秒，相对纪元) | 10 bit 机器ID | 12 bit 序列号
   ↑符号位恒0                       ↑可用~69年     ↑5120 台   ↑同毫秒4096个

同一毫秒内：序列号 0..4095 递增，用完 → 自旋等待下一毫秒
跨毫秒：    序列号清零
机器 ID：  部署时静态分配（K8s 用 StatefulSet 序号/注册中心领取）

性质：
  - 趋势递增：整体按时间走，同一机器毫秒内连续
  - 容量上限：4096/ms/机器 ≈ 单实例 400 万/秒 的理论天花板
  - 可反解：拿到 ID 能还原出时间戳与机器位（排障利器）

变体设计自由度：业务可以把 10 bit 机器位拆成"机房 3 + 机器 7"，
或塞入分库路由位（低 N 位直接当分片键 → 按 ID 路由无需查表），
字节跳动、百度 UidGenerator 等都有各自裁剪。

时钟：分布式 ID 的阿喀琉斯之踵

回拨为什么会出事

雪花依赖"当前时间戳 ≥ 上次发号时间戳"。
NTP 校时导致本机时钟倒退 500ms：
  同一毫秒 + 同机器位可能重排出一模一样的 ID → 撞号
  极端：倒回很久 → 生成"历史时间"的 ID，与早已发号的区间重叠

处置策略（按回拨幅度分级）：
  < 5ms   自旋等待追平
  < 1s    抛异常停发，告警介入
  大幅    切换备用 workerID / 降级到号段引擎
  预防    跑 NTP 平滑步进（slew）而非 hard step；禁 dual-boot 改 UTC

逻辑时钟：不信任物理时间

分布式系统里"谁先发生"往往比"几点几分"更重要：

Lamport 时钟      ：每个事件带计数器，收到消息取 max(本地,远端)+1
                  → 保证因果一致，但无法判断并发（相等不代表同时）
向量时钟          ：每节点一个分量，可区分"因果先后 vs 并发"
                  → 代价是 O(n) 空间，多用于调试与冲突检测
TrueTime（Spanner）：物理时钟 + 原子钟/GPS 的"不确定区间"，
                  提交时 commit-wait 等区间过去 → 外部一致性
HLC（混合逻辑时钟）：物理时间为主、逻辑计数器补角，
                  Cassandra/MongoDB 用它给并发写排序

对 ID 系统的启示：若只要求"趋势递增 + 唯一"，
以物理时间打头 + 序列兜底，并把"时间只增"当契约强制校验，
比追求绝对时钟精度更现实。

实战选型清单

订单/交易号：  雪花（带分片位）或 Leaf-segment
              要趋势递增利于索引；要能按 ID 反查分库
短链/卡券码：  号段 + 进制混淆（防枚举），别裸自增
IoT/海量埋点：本地雪花（避免中心服务瓶颈），机器位靠注册中心发放
已有 MySQL 且量小：号段表最简单，step=1000 就够 90% 场景
对外 API 游标：UUIDv7/ULID（时间前缀解决 v4 乱序索引问题，128bit 但有序）

避坑：
  1. 把雪花 ID 当"绝对有序"用——跨机器毫秒交错会微乱序，
     需要严格有序请走数据库事务序列
  2. workerID 靠 IP 推导——K8s 里 IP 漂移即撞号
  3. 时间纪元写死 2015 年后系统迁移时才发现溢出
  4. ID 里的租户/金额信息直接明文可猜 → 编码或加偏移

总结

理解分布式 ID 的关键在于：它是"用局部信息生成全局秩序"的典型问题——号段把裁决权交给中心存储，雪花把秩序押在物理时钟上；真正可靠的方案不是选一个完美的，而是给时钟回拨、机器位漂移、号段切换抖动都准备好兜底路径。