逻辑时钟表达因果先后而不是墙上时间

分布式系统没有一个所有进程都能瞬时读取、绝对一致的时钟。即使机器使用时间同步，网络延迟、时钟漂移和校时跳变仍会让时间戳相近的事件难以排序。许多一致性问题真正需要的不是“几点发生”，而是“一个事件是否可能影响另一个事件”。

逻辑时钟从通信关系中构造顺序，不试图还原物理世界的精确时刻。它适合表达因果、调试消息链和解决冲突，但不能直接计算真实持续时间或证明两个机房的墙上时间一致。

Happened-before 定义可传播的先后关系

同一进程内，程序观察到的先后形成顺序。发送消息先于接收该消息；若事件 A 先于 B，B 又先于 C，则 A 先于 C。三条规则的传递闭包构成 happened-before 关系。

这个关系描述潜在因果：后一个事件可能接收到前一个事件的信息。若 A 与 B 之间既不存在 A 到 B 的路径，也不存在 B 到 A 的路径，它们就是并发事件。并发不表示物理上同时，只表示系统现有通信证据不能建立因果先后。

真实业务因果可能通过系统外渠道传播。例如用户看到一条短信后在另一个设备提交请求，如果追踪上下文没有连接两个入口，逻辑时钟看不到这条关系。因此它表达的是已建模通信中的因果，不是社会世界的完整因果。

每个进程维护递增计数器。本地事件发生时递增；发送消息时附带当前值；接收方把本地值更新为本地与消息值的较大者再递增。这样，只要 A happened-before B，就一定有时钟值 $C(A) < C(B)$ 。

逆命题不成立。 $C(A) < C(B)$ 可能只是两个独立进程的计数碰巧如此，不能据此断言 A 导致 B。这个单向边界非常重要：Lamport 时间可以维护与因果一致的排序，却无法仅凭两个标量判断并发。

若业务要求稳定全序，可以用逻辑时间和进程标识组成排序键。该全序便于决定日志展示、互斥请求或确定性处理顺序，但它对并发事件增加的是人为裁决，不应被解释为真实因果。

向量时钟为参与者维护一个分量。进程更新自己的分量，消息携带向量，接收方逐项取最大值。若一个向量所有分量不大于另一个且至少一项更小，可以判断前者发生在后者之前；两个向量互不支配时，可识别为并发。

代价是元数据随参与者数量增长，成员动态加入、离开和身份复用也需要治理。大型系统常采用版本向量、点时钟或压缩变体，在可判定性与空间成本之间取舍。

向量时钟能指出冲突版本并发产生，却不能决定如何合并。购物车集合、文本、余额和权限的业务语义不同，冲突解决仍需领域规则、用户选择或更强协调。

物理时间用于证书有效期、计费窗口、监管记录和用户可读时间。逻辑时间用于因果关系和协议顺序。把墙上时间直接用作唯一版本号，可能因时钟回拨、闰秒或不同步产生倒序和覆盖。

混合逻辑时钟把物理时间近似值与逻辑计数结合，可让时间戳接近现实时间并保持因果单调，但仍依赖明确的漂移边界和实现协议。它不是把普通系统时钟加一个自增序号就自动正确。

数据库提交时间、消息代理偏移量和共识日志索引也各有语义。偏移量通常只在分区内有序，共识日志索引只对同一日志成立，不能跨系统当作全球时间线。

系统设计要先问需要哪种顺序：单个实体、单个分区、一个共识组，还是所有事件的全局顺序。作用域越大，协调成本和故障影响越高。很多业务只需要同一订单内有序，没有必要为无关订单建立全局队列。

消息重试和重复投递会让到达顺序不同于产生顺序。事件应携带实体版本、因果标识或幂等键，消费者还要定义发现缺口、旧版本和并发更新时的行为。仅按接收时间排序无法恢复丢失的因果信息。

跨分区聚合时，可接受水位线、迟到窗口或最终修正；强制等待所有分区可能把一个故障扩大为全局停顿。顺序保证应与延迟、可用性和纠错方式一起写入契约。

分布式追踪通过 trace 和 span 关系记录请求链，比对日志墙上时间更可靠。日志仍应保存物理时间用于运维，但还要保存请求标识、父子关系、实体版本和消息标识。

排障界面可以按因果边展示，再用物理时间帮助理解延迟。若发现子事件时间早于父事件，不应立刻篡改记录，而应检查时钟同步和采集管道，同时保留原始证据。

测试应模拟延迟、乱序、重复、时钟回拨和进程重启，验证版本单调性与冲突处理。逻辑时钟的价值不是给每个事件一个更大的数字，而是把系统真正依赖的顺序写成可验证协议。

Leslie Lamport：Time, Clocks, and the Ordering of Events in a Distributed System，https://www.microsoft.com/en-us/research/publication/time-clocks-ordering-events-distributed-system/
Diego Ongaro、John Ousterhout：In Search of an Understandable Consensus Algorithm，https://raft.github.io/raft.pdf