分布式全局时钟：NTP 精度问题，Google TrueTime / Spanner 的全局快照隔离
问题：时钟不一致，问题到底出在哪
分布式系统里，每台机器都有自己的物理时钟。代码里写 System.currentTimeMillis()，不同机器拿到的结果可能差几十甚至几百毫秒。这个差距会带来一系列连锁问题：
- 日志时间错乱：A 服务调用 B 服务，A 的日志时间比 B 还晚，排查故障时方向反了
- 分布式事务提交顺序错误：两个事务在不同节点提交，读到的顺序跟实际发生顺序相反
- 缓存过期时间不准确：TTL 基于本地时间，节点间时钟偏差大，缓存同时过期打崩 DB
- 分布式 ID 重复：Snowflake 依赖时间戳 + 机器 ID，时钟回拨直接产生重复 ID
这些问题的根源只有一个：物理时钟不可靠。那怎么解决？先看最通用的方案——NTP，再看 Google 的豪横方案——TrueTime，最后看工程上更实用的替代。
NTP 同步方案：精度瓶颈在哪里
NTP（Network Time Protocol）是目前最广泛使用的时间同步协议。它的工作原理是分层架构：
- Stratum 0：原子钟、GPS 时钟等硬件参考源
- Stratum 1：直接与 Stratum 0 同步的服务器
- Stratum 2-15：逐级向下同步，每层增加一次网络延迟
同步过程本质上是测量网络往返时间并校正本地时钟。客户端向 NTP 服务器发送请求，记录时间 T1；服务器收到后记录 T2，回复时带上 T3；客户端收到时记录 T4。通过这 4 个时间戳，可以估算出网络延迟和时钟偏移，然后调整本地时间。
NTP 的核心瓶颈是网络延迟不确定性：
- 局域网内，往返延迟 0.1-1ms，同步精度约 1-10ms
- 跨机房 / 同城数据中心，延迟 1-5ms，精度约 10-50ms
- 跨城市 / 跨地域，延迟 10-100ms，精度 50-200ms
而且 NTP 是软件层面的同步，会受到操作系统调度、中断、CPU 负载的影响。机器时钟本身也会漂移（普通石英钟每日漂移约 1-10ms），所以 NTP 只能缩小偏差，无法消除偏差。
对于大多数业务系统，10ms 内的偏差可以接受。但对于需要严格全局一致性的系统（如分布式数据库、金融交易），NTP 远远不够。
Google TrueTime：用物理硬件堆出来的全局一致性
Google Spanner 是全球级分布式数据库，需要跨数据中心保证外部一致性（External Consistency）——即事务的提交顺序和实际发生的先后顺序完全一致，不会出现"先提交的事务反而被后读"的情况。
为了做到这一点，Google 的工程师没有选择依赖 NTP，而是直接上硬件：每个数据中心部署 GPS 接收器 + 原子钟。
TrueTime 的核心设计
TrueTime 不返回一个精确的时间点，而是返回一个时间区间 [earliest, latest]，表示当前真实时间一定落在这个区间内。这个区间宽度称为误差边界（uncertainty interval）。
- 典型误差：1-7ms（大部分时候在 1-4ms 之间）
- 使用 Marzullo 算法融合多个时间源（GPS + 原子钟），计算出最保守的区间
- 原子钟在 GPS 信号丢失时作为后备，短时间内误差不会快速扩大
Spanner 如何利用 TrueTime 实现外部一致性
Spanner 的读写事务流程：
- 事务参与者准备提交，向协调者报告各自的 TrueTime 时间戳
- 协调者选择最大时间戳作为 commit 时间戳 T
- 协调者等待
commit_wait，即等待当前 TrueTime 的latest确认超过 T（确保 T 是过去的时间） - 提交事务，写入数据
关键就在第 3 步：commit_wait 保证任何后续读操作都能看到这个事务的结果。因为 TrueTime 的误差是有界的，等待误差边界过去后，全世界所有节点都能确认该事务已经提交。
读操作也很简单：读事务指定一个时间戳 T_read，在所有副本上读取 时间戳 <= T_read 的最新数据。由于 TrueTime 保证了写事务的 commit 时间戳一定小于等于真实时间，读事务拿到的数据一定是已经提交且不会回滚的。
代价是什么
TrueTime 的工程成本极高：
- 每个数据中心需要 GPS 接收器 + 天线，需要屋顶视线开阔
- 原子钟每年维护成本不低
- 跨多个数据中心的硬件部署，总成本百万级
这也是为什么 TrueTime 基本只有 Google 用得起。其他公司需要更务实的方案。
更实用的替代方案：HLC 和中心化授时
混合逻辑时钟（HLC）
HLC 的思路是：结合物理时钟和逻辑时钟，取两者的优点。
- 正常情况：物理时钟基本同步，HLC 的物理部分 ≈ 真实时间，精度接近 NTP 级别
- 时钟回拨 / 偏差：HLC 通过逻辑部分补偿，保证事件的因果顺序不被破坏
- 跨节点对比：HLC 值可以直接比较大小，不依赖两节点时间精确同步
CockroachDB 使用 HLC 替代 TrueTime，实现了全局一致性快照读，但不需要特殊硬件。HLC 的精度在毫秒级，对于大多数 OLTP 场景已经足够。
其他行业做法
- 中心化授时服务：部署一台高精度 PTP 硬件时钟（精度微秒级），所有节点通过 NTP 同步到这台服务器，配合实时监控时钟偏移（如 Chrony 最佳实践 + 偏移量告警）
- 业务层面容忍：大多数系统不需要严格的外部一致性，最终一致性 + 版本号 / 时间戳对比即可。关键业务加乐观锁或版本号校验
- 时钟回拨容错：Snowflake 类算法支持回拨等待（短回拨睡眠）和兜底（长回拨切到备选时钟源）。分布式锁不要依赖 TTL + 本地时间，用 Lease 续约机制
总结
| 方案 | 精度 | 成本 | 适用场景 |
|---|---|---|---|
| NTP 软件同步 | 1-100ms | 免费 | 绝大部分应用 |
| PTP 硬件时钟 | 微秒级 | 中等 | 金融交易、高频交易 |
| TrueTime | 1-7ms | 极高 | 全球级分布式数据库 |
| HLC | 毫秒级 | 免费 | CockroachDB 等替代方案 |
核心教训：在分布式系统设计中，永远不要假设物理时钟是可靠的。用逻辑时钟、版本号、Lease 续约、时间戳校验等机制，消除对物理时钟的直接依赖，才是长久之计。
面试官如果追问 TrueTime，重点不是背论文摘要，而是说清楚 commit_wait 的时间窗口怎么算，以及不用 TrueTime 怎么实现类似效果——这两点比背 Spanner 的架构图更有区分度。