Appearance
分布式系统中的时钟：同步、顺序与期限
修订于 2026-10-12：原文的电商扣款事故、未注明出处的漂移数字和通用告警阈值已删除。下文只讨论可验证的设计原则。
三种不同的问题
**现在是几点？**日志、报表和对外显示需要墙上时间（wall clock）。各机器的本地时钟可能有偏差；同步服务能减小偏差，但不能把不确定性消除。
**过去了多久？**请求超时、任务期限和性能测量应使用系统提供的单调时间或期限机制。墙上时间可能因校时或人工调整而变化，不适合作为经过时间的唯一依据。
**哪件事先发生？**跨节点事件顺序不能只靠比较两台机器的本地时间戳。需要依据业务保证选择数据库事务、单调序号、因果关系标记或一致性协议。时钟同步与事件排序是两个不同问题。
NTP 能提供什么
NTP 通过网络交换时间信息并估计本地时钟与时间源的偏差。估计受网络延迟及路径不对称影响。RFC 5905 描述了 NTPv4 协议和算法，但不能由此推出任意环境中固定的毫秒级误差值。
运维上应确认机器有可信的时间源，监测同步状态、偏移、抖动和时间源变更。告警阈值应由具体业务容忍度、时间源和环境测量决定，不能照搬一张通用表。涉及证书有效期、跨系统审计或到期计算时，应单独测试时钟异常和回拨。
TrueTime 不能简单复制
Google Spanner 的 TrueTime 把时间表示为带不确定区间的结果，并将其用于事务时间戳和外部一致性。它依赖特定的时间基础设施和事务协议。应用在普通虚拟机上配置 NTP，不会自动得到 TrueTime 的保证。
设计检查清单
- 为每个时间字段写明语义：事件发生时间、系统接收时间、提交时间、显示时间，不能混用。
- 跨服务传递明确的时区或统一时间表示；界面展示时再转换到用户时区。
- 超时与重试共享一个整体期限，并使用单调时间计算剩余预算。
- 需要严格顺序的业务由存储或协调协议保证顺序，不依赖“服务器时间差不多”。
- 注入时钟回拨、时间源失联、网络延迟和跨时区输入，验证告警与恢复流程。