时钟回拨 30 秒：一次 NTP 漂移把 Redis 分布式锁打穿、定时任务重复跑 3 遍的复盘

作者程清和-927

SRENTP时钟漂移Redis分布式锁定时任务

先抛一个我想听大家拍砖的问题：你们线上出过「没有慢查询、没有 GC、没有网络抖动，却莫名重复扣款 / 重复发券」的事故吗？ 如果是，八成不是代码的锅，而是机器时钟被 NTP 往回拨了一截，把依赖「时间」的分布式锁和定时任务全打穿了。下面是一次真实复盘。

一、现象与背景

上周二 03:14，对账系统告警：同一笔 order_no 被扣款了 3 次，涉及 217 笔订单、约 11 万元，值班同学第一反应是「幂等键失效了」，翻代码没找到改动。

规模与影响：

受影响订单 217 笔，重复扣款 2 次/笔，资损约 11 万元，回滚耗时 2h40m；
同时段另一台机器上的「每日结算定时任务」在 03:00 窗口内重复执行了 3 遍，把当天流水多算了一遍；
诡异点：应用日志、JVM、MySQL、Redis 的延迟和错误率在事故时段全部正常，没有任何 P99 毛刺——这几乎排除了常见的性能类根因。

最后定位到：其中一台 worker 在 03:12 被 chronyd 做了一次 step 校正，本机时间从 03:14:52 直接跳回到 03:14:22，回拨了约 30 秒。

二、原理与根因分析

为什么「时钟回拨」能造成重复执行？关键在于我们有两个组件都用墙钟（wall clock）做正确性判断，而不是用单调时间：

Redis 分布式锁的 TTL 过期判断。我们当时用的是 SET lock:{order} 1 NX EX 30 拿锁、业务跑完 DEL。问题不在拿锁，而在续租（watchdog）逻辑：我们用一个后台线程每 10s 判断「锁是否快到期、要不要续」，判断依据是 lockExpireTime 这个绝对时间戳，它是在加锁那一刻用 System.currentTimeMillis() 算出来的。时钟回拨 30s 后，now < lockExpireTime 突然变成「还没到期」的反面逻辑被打破，续租线程误判锁已过期、提前释放；另一台 worker 恰好在此窗口 SET NX 成功，于是两把锁在同一订单上先后生效，扣款跑了 3 遍。
- 更隐蔽的一点：Redis 服务端的 EXPIRE 也是用 Redis 节点的墙钟算的。客户端和 Redis 节点各自漂了 30s，锁的真实存活时间被压缩。
定时任务的去重。我们用的是「按 yyyyMMddHHmm 生成一个 job:{date}:{minute} 的 Redis 标记，存在才跳过」。时钟回拨让 03:14 这一分钟被「重放」，job:...:0314 的标记在回拨后被当作「新分钟」重新 SET，于是同一分钟任务又跑了一遍——3 台 worker 各触发一次，凑成 3 遍。

根因一句话：把「正确性」押在了「每台机器墙钟都准且单调」这个并不成立的假设上。NTP 的 step 模式（makestep）在漂移超过阈值时会直接跳变，而不是平滑 slew，这是回拨的元凶。

三、具体做法（可复现）

1. 先确认是不是时钟回拨。 在每台 worker 上：

# 看 chrony 是否在 step（跳变）而不是 slew（平滑）
chronyc tracking          # 关注 "System time" 与 "Skew"，跳变时 System time 会突变
chronyc sources -v
# 抓系统日志里的时间跳变证据
journalctl -u chronyd --since "2026-04-01 03:00" | grep -iE "step|slew|time"
# 应用侧：把「加锁/续租/now」都打点，事后比对 now 是否非单调

应用里加一个单调时钟哨兵，专门监控回拨：

// 用 System.nanoTime()（单调）对比 wall clock 的增量
long lastWall = System.currentTimeMillis();
long lastMono = System.nanoTime();
ScheduledExecutorService guard = Executors.newSingleThreadScheduledExecutor();
guard.scheduleAtFixedRate(() -> {
    long dWall = System.currentTimeMillis() - lastWall;
    long dMono = (System.nanoTime() - lastMono) / 1_000_000L;
    // 单调时间应 >= 墙钟增量；若 dMono - dWall > 1000ms 说明墙钟被回拨了
    if (dMono - dWall > 1000) {
        log.error("CLOCK_ROLLBACK wallDelta={}ms monoDelta={}ms", dWall, dMono);
        // 触发告警 + 主动降级：暂停该实例的定时任务与锁续租
    }
    lastWall = System.currentTimeMillis();
    lastMono = System.nanoTime();
}, 1, 1, TimeUnit.SECONDS);

2. 让 NTP 平滑收敛，禁止大步长 step。 /etc/chrony.conf：

# 默认漂移 <1s 用 slew，只有 >1s 才允许 step，且限一次
makestep 1.0 3
# 提高漂移容忍，减少 step 触发
maxslewrate 1000

同时把 NTP 源换成内网授时钟（我们原来混用了公网 NTP，跨运营商抖动大）。

3. 把「正确性」从墙钟解耦。

分布式锁不要用 System.currentTimeMillis() 算「还剩多久续租」，改成相对剩余时间：续租线程只判断「距离上次续租是否超过 8s」，用 System.nanoTime() 计时，彻底不碰墙钟；
定时任务去重标记，加一个「回拨保护」：记录本进程见过的最大分钟值，now < maxSeenMinute 时判定为回拨，直接跳过而不是重新 SET；
更彻底的做法：把锁的持有校验交给 Redis 端 PEXPIRE，客户端只负责续租、不自己判断绝对过期时间。

四、踩过的坑 / 反直觉之处

最反直觉的：所有性能指标都正常。 时钟回拨不会让 CPU、GC、P99 有任何异常，常规「看监控找毛刺」的思路完全失效——它是逻辑正确性问题，不是性能问题。这次我们多花了 1h 在「找毛刺」上纯属白找。
makestep 默认配置就是隐患源。 很多发行版默认 makestep 1 3 甚至更激进，漂移一超阈值就跳变，业务侧毫不知情。我们以为「配了 chrony 就稳了」，其实稳的是「最终收敛」，不保证「单调」。
System.currentTimeMillis() 在很多框架里被默认为「可靠时间源」，但 Javadoc 明确它是墙钟、可被系统改。任何用它做「过期判断 / 去重 / 限流窗口」的地方都是潜在雷点。
Redis 的 EXPIRE 用的是 Redis 节点时钟，客户端和 Redis 时钟各漂各的，锁的真实 TTL 是「两边时钟差」的函数——这是最容易被忽略的一层。

五、结论与可复用清单

结论：依赖墙钟做正确性判断（锁过期、定时去重、限流窗口、会话 TTL）是分布式系统的隐性雷。NTP 的 step 校正会让墙钟非单调，直接击穿这些假设。正确性该押在单调时钟 + Redis 端过期 + 回拨保护上，而不是「机器时间够准」。

可复用清单（建议贴进团队 checklist）：

[ ] 应用启动即打印 chronyc tracking，把「Skew / 是否 step」纳入巡检；
[ ] 每台 worker 部署「时钟回拨哨兵」（mono vs wall 对比），回拨 >1s 即告警 + 降级；
[ ] 分布式锁续租一律用 System.nanoTime() 相对计时，禁用 currentTimeMillis() 绝对过期判断；
[ ] 定时任务去重加「回拨保护」：now < maxSeenMinute 时跳过；
[ ] NTP 用内网授时钟，makestep 阈值放宽、优先 slew；
[ ] 关键幂等（扣款/发券）在存储层（DB 唯一键 / 状态机）兜底，别只靠 Redis 锁这一层。

留个开放问题想听听大家：你们团队现在「锁过期、限流窗口、定时去重」这三处，到底有几处是用墙钟在判断的？ 欢迎把你们的回拨哨兵实现贴出来对一对。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。