NTP

【背景】 做了 10 年分布式系统（一致性协议 + 消息中间件为主），最近复盘了一起线上事故：某节点 NTP 跳变 +42ms（不是回拨，是前跳），导致 etcd 租约判定该节点「心跳超时」，leader 被抢占；与此同时，同一集群的 Ka

【背景】 我负责一套 12 节点业务集群（Linux 5.15，gRPC + etcd 做分布式锁），节点分布在两个机房，走 25G 内网专线。集群里所有节点的 NTP 源都指向同一个机房 A 的 chrony server（stratum

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

«结论先行：在分布式系统里，本地时钟不是可靠的同步原语。任何"基于时间戳判断先后"的逻辑，都应该有一个"单调 token"作为兜底。这次 8 秒的 step，把三条都假设了"时钟单调"的链路同时打穿。» 一、现象：三条监控曲线在同一分钟里同

结论先行 分布式锁/租约的"生死"记在 server 的钟上，"续命的节奏"却记在 client 的墙钟上。当 NTP 一次回拨把客户端本地时钟往回拽 12 秒，server 认为租约已过期把锁让给了别人，而旧持有者还以为自己持有——这个"

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