限流器被 NTP 时钟跳变打穿：一次 19000 次 429 的风暴复盘与时间源治理

作者谢知远-118

限流NTP时钟Sentinel性能调优后端

结论先行：几乎所有基于"滑动窗口 / 令牌桶"的单机限流器，都默认时间源是平滑的；一旦 NTP 用 step 模式把本机时钟往前跳 300ms+，限流器会在同一瞬间把整个窗口的配额一次性烧完，表现就是"没有任何改动、突然一片 429"。这篇把现象、机制、代码、坑一次讲清楚。

一、现象：大促压测日，5 台机器"约好了一样"开始限流

3 月 14 号下午 14:03:11，支付网关（JDK 17，Sentinel 1.8.6，42 台实例，单机阈值 2000 QPS）压测中突然出现：

90 秒内网关返回 19,432 次 429，其中 5 台机器在同一秒触发；
P99 从 34ms 飙到 1.4s，压测侧 QPS 掉 20%；
更诡异的是：压测客户端的重试率从 0.3% 拉到 11%——被拒的请求被 SDK 自动重试，反而把压力放大了一倍。

排查时最先怀疑的是配置被改、规则下发错、GC 卡死，全部否掉：GC 日志干净、规则版本一致、CPU/内存正常。最后从内核日志里看到一行 time change detected，时钟在 14:03:11 往前跳了 320ms。

二、机制：滑动窗口对"时间跳变"是零容忍的

Sentinel 的滑动窗口（以及大多数自研限流器）核心逻辑是：

按墙钟把时间切成固定长度的桶（Sentinel 默认 1s 一个 bucket，1s 分 2 段）；
每次请求到来，取 now / bucketLength 作为 key，往当前桶里累加计数；
判断"最近 1s 总计数是否超过阈值"。

问题就出在 now 是墙钟：

向前跳 320ms：下一个请求取到的 bucket key 直接跳过当前桶，但 Sentinel 的判定逻辑会把"当前已用掉的配额"和"跳过去的桶"一起算进窗口——等效于一个请求瞬间消耗掉了本该在 300ms 内慢慢用完的额度，阈值立刻打满，后续请求全部 429。
向后跳 50ms：更反直觉——bucket key 会回退，已经记过的桶会被"重开"，配额相当于被重复使用，限流在跳变期间完全失效。
放大效应：我们 42 台机器全用同一台内网 NTP 源，跳变时刻在时间上同步、在空间上全局化。单机 300ms 的跳变，变成了整个集群同一秒同时限流。
重试风暴：客户端 SDK 看到 429 自动重试，把"限流拒绝"变成了"流量放大"，P99 从 34ms → 1.4s 主要就是这一步贡献的。

三、做法：把"时间源"从隐式依赖变成显式组件

1) 引入 ClockGuard：检测跳变、冻结时间

不要让业务代码直接调 System.currentTimeMillis()，统一走一个 TimeSource：

final class ClockGuard {
    private final long THRESHOLD_MS = 5;   // 5ms 内的漂移视为正常
    private long lastNow;
    private long frozenAt;                 // 冻结时刻

    ClockGuard() { lastNow = System.currentTimeMillis(); }

    synchronized long now() {
        long t = System.currentTimeMillis();
        if (t - lastNow > THRESHOLD_MS || t < lastNow) {
            // 向前跳 or 向后跳：都冻结
            if (frozenAt == 0) {
                frozenAt = lastNow;
                // 这里打点 + 告警：clock_jump direction, delta
            }
            // 冻结后：用 lastNow + 单调时钟补一个"伪平滑时间"
            long elapsed = System.nanoTime() - frozenNano;
            return lastNow + Math.max(0, elapsed / 1_000_000);
        }
        lastNow = t;
        frozenAt = 0;
        return t;
    }
    private long frozenNano;
}

关键约束：

向前跳：冻结时间，让限流器继续用"旧时间"计数，等效于"这段时间没有经过"——保守但不会误伤；
向后跳：同样冻结，避免 bucket key 回退导致配额复用；
告警：clock_jump 事件必须进监控，阈值 5ms，任何一次触发都是 P2 级事件。

2) NTP 从 step 改成 slew

在 /etc/ntp.conf（或 chrony.conf）里：

# ntp.conf
tinker step 0          # 禁止 step，只允许 slew（频率微调）
tinker panic 0

或 chrony：

makestep 0.1 -1        # 只有偏差 > 100ms 且是第 1 次同步才允许 step

改完压测：连续 48h 观察 chronyc tracking，System time 漂移始终 < 1ms，Skew < 200us。

3) 限流算法侧留 20% 余量

把单机阈值从 2000 QPS 下调到 1600 QPS（留 20% 余量），配合 Sentinel 的匀速排队模式（CONTROL_SPEED），即使时间源偶尔抖动 100ms，也不会瞬间打满。

4) 监控三件套

| 指标 | 阈值 | 动作 | |---|---|---| | clock_jump 事件 | ≥ 1 次/分钟 | P2 告警，自动切到备用 NTP 源 | | 429 拒绝率 | > 1% 持续 10s | P3 告警，联动检查时钟 | | sentinel.block.qps | 突增 > 5 倍 | P3 告警 |

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

回跳比前跳更危险：前跳是"误伤"（不该拒的拒了），回跳是"失效"（该拒的没拒）。很多人只防前跳，回跳的窗口配额复用是静默的，压测都测不出来。
共享 NTP 源 = 全局同步故障：42 台机器同一个时间源，跳变时刻在时间上对齐、在空间上铺满，单机问题秒变集群问题。
重试是放大器不是救兵：429 被 SDK 自动重试，压力翻倍。限流器的拒绝策略必须和客户端重试策略联合设计，不能各管各的。
System.nanoTime() 不是万能的：它单调但跨重启不连续、不同进程间不可比，适合做"间隔"不适合做"绝对时间戳"。限流桶的 key 必须用墙钟，所以 ClockGuard 是必须的。
Sentinel 的 CONTROL_SPEED（匀速排队）对时间更敏感：它内部用排队时间来算放行节奏，时间跳变时排队时间会算错，反而比固定窗口更容易翻车。我们最后改回了固定窗口 + 20% 余量。

五、结论与可复用清单

结论：限流器不是"配置问题"，是时间源问题。任何基于墙钟的滑动窗口 / 令牌桶 / 过期判断，都默认了"时间平滑前进"这个前提；一旦 NTP step 模式介入，这个前提就碎了。

可复用清单：

[ ] 所有时间敏感组件（限流、过期、去重、会话）统一走 TimeSource 接口，禁止裸调 System.currentTimeMillis()
[ ] ClockGuard：5ms 阈值，前跳/后跳都冻结，触发即 P2 告警
[ ] NTP 配置：tinker step 0 或 makestep 0.1 -1，只允许 slew
[ ] 限流阈值留 20% 余量，避免时间抖动瞬间打满
[ ] 客户端 429 重试策略与限流器联合设计，避免重试风暴
[ ] 监控：clock_jump、429 拒绝率、sentinel.block.qps 三件套

一句话：你限流限的不是 QPS，是时间——先把时间源治理好，再谈限流。

参考：社区里 @林砚舟的《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》也提到超时和重试是容量规划的一部分，本文从"时间源"这个更底层的角度补一刀。

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

暂无评论。