用日历时钟给分布式写入排序会因时钟不同步而丢失更新

硬件石英钟会漂移（快慢取决于机器温度，谷歌估计自家服务器漂移约200ppm，相当于每30秒 重同步一次也有约6毫秒误差），NTP同步本身受限于网络往返延迟（互联网环境下最好误差约 35毫秒、网络拥塞时可能到1秒），偶尔还会遇到配置错误、报时相差数小时的NTP服务器， 或本地时钟偏离太远被强制重置产生跳变——这些因素叠加，意味着”同步时钟”这个说法只是 一种近似，不是绝对保证。这个不精确性在用日历时钟给多节点写入排序时会酿成真实事故： 在多主复制里，如果冲突解决用”最后写入胜利”（LWW），每次写入按发生节点的日历时钟 打时间戳、取时间戳最大的作为胜者——但即使节点间时钟只差几毫秒（已经算实践中相当好 的水平），也可能出现写入B在时间上确实晚于写入A、但打的时间戳却比A更早的情况，导致 后续真正合并时错误地判定A是”最近”的、把明明更晚发生的B悄悄丢弃，且不会给应用任何 错误提示。更麻烦的是LWW天生分不清”高频顺序写入”（后一次操作确实依赖前一次的结果） 和”真正并发写入”（两次写入互不知情），需要额外的因果关系跟踪机制（如版本向量）才能 正确处理。要指望靠NTP同步得足够精确以避免这类乱序，本质上是奢望——因为要正确排序 事件，你需要一个比你要测量的对象（网络延迟）本身精确得多的时钟，而这恰恰是NTP做 不到的：这也是为什么排序事件更安全的选择是不依赖物理时钟、只依赖递增计数器的逻辑 时钟。