雪花算法遇到时钟回拨怎么办？

简化版

时钟回拨会让 Snowflake 时间戳变小，若同一 WorkerId 再使用相同毫秒和序列就可能重复。生成器必须保存 lastTimestamp，发现 now < lastTimestamp 时禁止按回拨时间直接发号。小回拨可等待，大回拨应停发、切换受隔离的备用 WorkerId/逻辑时间或告警人工处理，并配合租约防 WorkerId 被重复占用。

详细版

每次生成比较 wall clock 与 lastTimestamp：相等则序列递增，变大则序列清零；变小则进入回拨分支。5ms 这类小回拨可睡眠到 lastTimestamp 后继续，但等待受请求 deadline 限制。分钟级回拨不能长时间占线程，应 fail closed 或采用有边界的逻辑时钟方案。

持久化时间高水位并在重启时等待越过它，可防进程回到已使用的时间区间；若不是每次同步落盘，更稳妥的做法是先持久化一个未来安全水位，并在接近该水位前成功续订更远的水位，之后才能继续发号。WorkerId 安全依靠有效租约、到期停发与复用隔离，lease epoch 用于识别代次和审计，但它若不进入 ID 或资源侧校验，不能单独阻止旧实例继续发号。运维层使用 NTP slew、禁止粗暴手工改时，并监控 clock offset、rollback delta、sequence wait 和停发次数。

完整版教学

一、回拨为什么会导致重复

Snowflake 的唯一组合是 (timestamp, workerId, sequence)。实例在时间 T 已发出序列 0～100，时钟回到 T，再从序列 0 开始，就会重放同一组合。数据库唯一约束能拦住部分重复，却不能修复已发送到其他系统的 ID。

记忆钩子：Snowflake 依赖时间单调；墙钟一旦倒走，生成器必须自己拒绝“重走旧路”。

二、正常生成状态机

now > last  -> last=now, sequence=0
now == last -> sequence++
now < last  -> rollback handling, 禁止普通生成
sequence overflow -> wait until next millisecond

lastTimestamp 和 sequence 更新要线程安全。多线程分别维护本地状态会在正常时间也重复。

三、小回拨：等待越过高水位

若 last-now=3ms，可等待 3～5ms 后重新读取时钟。不能把 lastTimestamp 直接减小，也不能只等待固定 1ms。请求剩余 deadline 只有 2ms 时，应快速失败而不是超时后继续占线程。

rollback = lastTimestamp - now
if rollback <= maxWaitMs and deadlineRemaining > rollback:
    sleep(rollback); recheck()
else:
    fail_or_fallback()

四、大回拨的策略比较

策略	优点	风险
停止发号	唯一性清楚	可用性下降
逻辑时间维持 last	可继续	长期领先、重启需持久化
切备用 WorkerId	快速恢复	必须保证命名空间隔离
等待真实时间追上	简单	分钟级不可接受

核心系统通常宁可停发并告警，也不使用未证明安全的随机补偿。

五、重启和 WorkerId 复用的组合风险

进程在 last=100000 时崩溃，机器时钟回到 99900；若重启丢失 last，又使用同 WorkerId，会不知道自己正在旧时间。只定期落盘“最后一次已用时间”仍可能丢失最后一小段进度；可提前持久化未来安全水位，并在用尽前续订，启动时读取该水位后等待或进入受控逻辑时间。若 WorkerId 被另一实例占用，即使时间正常也会重复，因此租约停发与安全复用是另一条独立防线。

VM 快照恢复会同时回退系统时间、内存状态和本机持久文件，是必须演练的危险场景。时间安全水位若也保存在同一快照里就无法兜底，应放在不会随实例一起回滚的可靠存储中，或在恢复后更换未被占用的 WorkerId。

六、预防与观测

使用可靠时间源和 chrony/NTP 渐进校时（slew），避免生产手工 date 跳变；监控与时间源 offset、同步状态、回拨幅度、last-now、等待次数和停发。云主机 suspend/resume、宿主迁移也可能带来异常。

若采用逻辑时钟，要监控逻辑时间领先真实时间多少，并规定最大领先上限。超过上限停发，防止时间位提前耗尽和生成时间严重失真。

七、常见误区与追问

误区：NTP 只会把时间往前调。 配置或大偏差可能 step 回拨，虚拟化也会影响时钟。
误区：发现回拨把 sequence 随机化即可。 随机只能降低概率，不能保证唯一。
误区：换 WorkerId 一定安全。 必须由租约证明新 ID 未被其他活实例使用。
误区：数据库主键冲突可以兜住全部风险。 ID 可能已进入消息、缓存和外部系统。
追问：为什么不用单调时钟？ 单调时钟适合测时长，但重启后无法直接形成跨进程绝对时间字段。
追问：lastTimestamp 多久持久化？ 不宜只按固定周期保存已用值；可预先持久化未来安全水位，在用尽前续订，重启后等待越过旧水位，以减少 I/O 又不遗漏崩溃前进度。
追问：逻辑时间会有什么副作用？ ID 解析时间领先真实时间，可能提前耗尽时间空间。

八、加强记忆

回拨处理围绕“记住最高时间、每次比较、小幅等待、大幅停发/受控替代、重启仍不失忆”。WorkerId 租约和时钟单调是两个独立唯一性条件，缺一不可。运维预防、运行时 fail closed 和异常演练共同守住不重号底线。

简化版

详细版