逻辑时钟（Logical Clock）

一、为什么需要逻辑时钟#

分布式系统里有一个看似简单实则致命的问题：两台机器上的事件，谁先发生？ 你可能会说，看时间戳就行了。但物理时钟不可靠——会漂移（每台机器的时钟走得快慢不一），NTP 同步时会跳变，不同机器间可能有几十毫秒甚至几百毫秒的偏差。

考虑这个场景：机器 A 在 10:00<00>.000 发送请求，机器 B 的时钟快了 50ms，在 09:59<59>.950 收到请求。按时间戳排序，B 的接收事件反而「早于」A 的发送事件——因果顺序被颠倒了。

逻辑时钟不依赖物理时间，而是用一个单调递增的计数器为事件排序。Lamport 时钟的规则很简单：本地事件时递增，收到消息时取 max(本地, 远端) + 1。这保证了：如果事件 A 因果上先于事件 B，那么 clock(A) < clock(B)。不需要同步时钟，不需要网络往返，只需要在消息里带上计数器值。

二、现实类比#

在一个所有人都在不同时区的群聊中给消息编号。不用挂钟时间（各地不同），而是给每条消息打一个序号，保证「我看到你的消息后才发的我的」——因果顺序，而非时钟顺序。

三、核心思想#

Lamport 时钟的核心规则只有三条：

本地事件：计数器 +1
发送消息：计数器 +1，将当前值附带在消息中
接收消息：clock = max(本地时钟, 消息中的时钟) + 1

sequenceDiagram participant P1 as 进程 P1 participant P2 as 进程 P2 P1->>P1: tick → 1 P1->>P1: tick → 2 P1->>P2: send(2) P2->>P2: receive: max(0, 2)+1 = 3 P2->>P2: tick → 4 P2->>P1: send(4) P1->>P1: receive: max(2, 4)+1 = 5 P1->>P1: tick → 6

因果序：P1<1> → P1<2> → P2<3> → P2<4> → P1<5> → P1<6>

属性	值
递增	O(1)——counter++
接收	O(1)——max + 1
保证	若 A → B（因果），则 clock(A) < clock(B)
局限	反之不成立：clock(A) < clock(B) 不意味着 A → B

四、变体与对比#

模式	关系	区别
向量时钟	向量时钟是 Lamport 时钟的增强版	Lamport 时钟只能排序；向量时钟还能检测并发事件
混合逻辑时钟（HLC）	HLC 结合物理时钟和逻辑时钟	HLC 提供因果排序 + 实时近似；Lamport 只有排序
物理时钟	逻辑时钟的替代方案	物理时钟提供真实时间但不可靠；逻辑时钟提供因果序但数字无时间含义
MVCC	MVCC 使用逻辑时间戳作为版本标识	逻辑时钟是排序工具；MVCC 是并发控制方案

Warning

clock(A) < clock(B) 不意味着 A 因果先于 B。两个从未通信的并发事件可以有任意的时钟值大小关系。要判断两个事件是否并发，需要向量时钟——每个节点一个计数器，按分量比较。

五、多语言实现#

Go：Lamport 时钟#

1
type LamportClock struct {
2
    mu   sync.Mutex
3
    time uint64
4
}
5

6
func (c *LamportClock) Tick() uint64 {
7
    c.mu.Lock()
8
    defer c.mu.Unlock()
9
    c.time++
10
    return c.time
11
}
12

13
func (c *LamportClock) Send() uint64 {
14
    c.mu.Lock()
15
    defer c.mu.Unlock()
16
    c.time++
17
    return c.time
18
}
19

20
func (c *LamportClock) Receive(remote uint64) uint64 {
21
    c.mu.Lock()
22
    defer c.mu.Unlock()
23
    if remote > c.time {
24
        c.time = remote
25
    }
26
    c.time++
27
    return c.time
28
}
29

30
func (c *LamportClock) Now() uint64 {
31
    c.mu.Lock()
32
    defer c.mu.Unlock()
33
    return c.time
34
}

TypeScript：Lamport 时钟#

1
class LamportClock {
2
  private time = 0;
3

4
  /** 本地事件：递增时钟 */
5
  tick(): void {
6
    this.time++;
7
  }
8

9
  /** 发送事件：递增并返回时间戳 */
10
  send(): number {
11
    this.time++;
12
    return this.time;
13
  }
14

15
  /** 接收事件：取 max 后递增 */
16
  receive(remoteTimestamp: number): void {
17
    this.time = Math.max(this.time, remoteTimestamp) + 1;
18
  }
19

20
  /** 当前时钟值 */
21
  now(): number {
22
    return this.time;
23
  }
24
}
25

26
// 使用示例：两个进程通信
27
const p1 = new LamportClock();
28
const p2 = new LamportClock();
29

30
p1.tick();                    // p1: 1
31
p1.tick();                    // p1: 2
32
const msg = p1.send();        // p1: 3, 消息携带时间戳 3
33
p2.receive(msg);              // p2: max(0, 3)+1 = 4

六、生产验证#

etcd — kvstore.go#L53-L72：store 结构体包含 currentRev int64——单调递增的修订计数器，每次写事务递增。Watch 和快照使用此修订号实现一致性读——「给我修订号 42 之后的所有变更」
LevelDB — dbformat.h#L62-L66：SequenceNumber 是每次写操作递增的 uint64_t，用于 WAL 中的写入排序、快照可见性判断和压缩时的键冲突解决
CockroachDB — 混合逻辑时钟（HLC），结合物理时钟 + 逻辑计数器实现可序列化事务，提供因果排序和实时边界

七、小结#

何时使用：

数据库修订追踪——etcd、CockroachDB 用单调修订号实现一致性快照和 watch API
缓存失效——基于 epoch 的失效：「如果你缓存的 epoch < 当前 epoch，你的数据已过期」
分布式事件排序——在没有同步时钟的节点间排序消息
MVCC——每个事务获得一个序列号，读者看到某个时间点的一致快照
乐观并发——「仅当版本匹配时更新这行」（逻辑时间戳的 compare-and-swap）

何时不用：

需要物理时间——如果需要「这发生在下午 2<30>」这样的时间戳，用混合逻辑时钟（HLC）或 TrueTime
检测并发事件——Lamport 时钟无法判断两个事件是并发还是因果相关，需要向量时钟
单进程顺序代码——简单计数器或数组索引就够了，Lamport 机制只增加复杂性
单写者事件存储——自增序列号比 Lamport 时钟更简单有效

八、参考资料#

Lamport 原始论文 - 1978 年，Leslie Lamport 的奠基论文「Time, Clocks, and the Ordering of Events」
etcd MVCC 实现 - etcd 修订号作为逻辑时钟
CockroachDB HLC - 混合逻辑时钟设计文章
向量时钟 - 向量时钟的原理和与 Lamport 时钟的对比
Raft 共识协议 - Raft 中的 term 是逻辑 epoch 的应用