如何选择 NTP、PTP 与单调时钟？
题干与适用场景
面试题：多台服务器需要记录可比较的事件时间，同时部分服务还要测量超时和延迟。请说明 NTP、PTP 与进程内单调时钟各自解决什么问题，给出部署选择、失步处理和验证方法。假设网络存在可变延迟、节点可能重启，且业务不能把时间同步误当成因果一致性。
面试官考察点
面试官看重候选人能否分离三个概念：对外可比较的墙上时间、节点本地经过时间、事件因果顺序。强回答会先问精度和网络边界，再说明 NTP 适合广域网的通用同步，PTP 适合受控局域网和硬件时间戳，单调时钟只用于同一节点的持续时间计算；不会笼统宣称“PTP 永远更准确”。
回答前需要澄清的问题
- 需要的最大允许偏差是多少？毫秒级审计通常可用 NTP，微秒级控制才值得评估 PTP 和硬件时间戳。
- 网络是否受控、交换机是否支持 IEEE 1588、链路是否有边界或透明时钟？不支持时 PTP 的理论精度无法落地。
- 时间用于排序、超时、签名还是合规留痕？超时使用单调时钟；跨节点排序仍需逻辑时钟、序列号或业务版本。
- 失去上游时间源时，系统应停止写入、降级还是继续服务？答案决定 holdover、告警阈值和数据标记。
推荐方案与推导
先建立分层时间架构：少量受 GPS、原子钟或可信上游约束的时间源，向区域 NTP 服务器提供服务；普通主机通过 NTP 校准墙上时间。NTP 的报文交换要面对往返延迟和路径不对称，因此工程上应记录 offset、频率误差、round-trip delay、stratum 和最后同步时间，而不是只看“服务已启动”。
PTP 将 grandmaster 的时间沿交换机传播，并可用硬件时间戳减少操作系统调度和网卡排队误差。在同一受控局域网、交换机支持 boundary/transparent clock、端点有硬件时间戳时，它可满足比 NTP 更紧的误差预算；跨互联网或经常变化的云网络则先验证设备与网络是否真的支持这些假设。
wall_now = CLOCK_REALTIME # 日历、日志、跨节点时间戳
elapsed = CLOCK_MONOTONIC # 超时、重试、延迟测量
deadline = monotonic_start + timeout单调时钟不会因 NTP 校时而倒退，适合计算经过时间；Linux 文档也区分了 CLOCKREALTIME 与 CLOCKMONOTONIC 的语义。即使墙上时间同步良好，也不能用它计算 30 秒超时，因为校时可能产生跳变或频率调整。
替代方案与取舍
只用 NTP 的优点是部署简单、跨网络可用、运营工具成熟；缺点是误差受路径和主机时间戳影响。PTP 的优点是受控网络中更低的偏差和抖动；缺点是依赖网卡、交换机、驱动和时钟源，配置与故障域更复杂。对事件排序，逻辑时钟或数据库序列比继续提高物理时钟精度更直接；对单机耗时，单调时钟比两种网络协议都合适。
失败场景、边界与反例
- 把 NTP 的“同步成功”当作业务时间准确，忽略 offset、stratum 和源切换。
- 用
CLOCK_REALTIME做超时；人工改时、闰秒处理或校时跳变会让计时过早或过晚。 - 在不支持硬件时间戳的云主机上声称 PTP 达到微秒精度；必须把网络能力作为前置条件。
- 用物理时间判断跨节点因果关系。两个事件可能因网络延迟而出现相同或逆序时间戳，应使用序列号、版本或逻辑时钟。
- 失步后继续生成看似精确的签名和审计记录；记录 time-source、sync-age 和 uncertainty，超过阈值时标记或拒绝高风险操作。
测试与验证清单
验证分三层：先在节点上检查实时钟与单调钟的语义测试，再采集 NTP/PTP offset、jitter、频率误差和同步年龄，最后注入网络延迟、丢包、上游切换和重启。验收指标应写成“在指定网络与硬件条件下，99.9% 时间窗口的偏差小于 X”，并分别测试 holdover 和恢复时间；不能只做一次 date 对比。
追问与延伸
如何处理跨节点事件排序？
把物理时间当作显示和审计字段，把因果关系交给单调递增的版本、消息序号、数据库提交序列或逻辑时钟。若必须展示时间顺序，明确允许的时钟不确定区间，并在相同区间内使用稳定的 tie-breaker。
PTP 是否可以完全取代 NTP？
不能直接下结论。PTP 适合有明确精度预算且网络可控的域；NTP 仍可覆盖管理网络、广域链路和没有 PTP 硬件的节点。常见架构是 PTP 约束关键域，再由域内服务向其他主机提供 NTP。
失去时间源时是否应该停机？
按业务风险分级：普通缓存或指标可在有界 holdover 内继续；签名、证书、金融撮合等功能应在 uncertainty 超过阈值时拒绝或转人工。所有降级都要产生告警、数据标签和恢复后的校准记录。