线性一致性

线性一致性（Linearizability）**是分布式系统中的一种强一致性模型。一句话定义：

所有操作看起来都像是在某个唯一时间点瞬间完成，并且这个时间点必须位于操作发起和响应之间，同时不能违背现实时间顺序。

核心要求

假设有多个客户端同时访问一个分布式 KV 系统。线性一致性要求：

1. 所有客户端看到一个统一的操作顺序。
2. 如果操作 A 已经完成后，操作 B 才开始，那么全局顺序中 A 必须在 B 前面。
3. 如果两个操作时间上重叠，可以任选一个合理顺序。
4. 每次读取都必须看到它之前已经完成的最新写入。

简单例子

初始状态：

x = 0

执行过程：

客户端 A：Put(x, 1) ───────── 返回成功 客户端 B：Get(x)

因为Put(x, 1)已经返回后，B 才发起读取，所以线性一致性要求：

Get(x) 必须返回 1，或者返回在它之后写入的更新值

不能返回旧值0。

并发操作的情况

客户端 A：Put(x, 1) ─────────── 客户端 B：Put(x, 2) ───────────

两个操作时间上发生重叠，那么系统可以将它们排列为：

Put(x, 1) → Put(x, 2)

也可以排列为：

Put(x, 2) → Put(x, 1)

只要所有节点和客户端最终遵循同一个顺序即可。

线性一致性不要求按照请求开始时间排序，只要求尊重已经完成的先后关系。

“线性”是什么意思

可以把分布式系统中并发执行的操作，拉成一条全局时间线：

Put(x, 1) → Get(x)=1 → Put(x, 2) → Get(x)=2

每个操作都存在一个“线性化点”：

请求发出 ───── 线性化点 ───── 收到响应

从外部观察，操作就像在线性化点瞬间生效。

在 Raft 中，写操作的线性化点通常可以理解为：该日志被多数节点确认并提交的时刻。但服务一般要等日志应用到状态机后，才能安全地向客户端返回结果。

Raft 如何支持线性一致性

Raft 主要提供以下基础：

1. 所有写请求通过 Leader

   Leader 决定日志顺序，避免不同节点各自决定顺序。

2. 日志按照统一顺序复制

   index 1：Put(x, 1) index 2：Put(y, 2) index 3：Get(x)

   所有状态机按照日志 index 顺序执行。

3. 获得多数派确认后才能提交

   Leader 不能收到请求后立即返回成功，必须先把日志复制到多数节点。

4. 提交后再应用到状态机

   客户端请求 ↓ Leader 写入日志 ↓ 复制到多数节点 ↓ 更新 commitIndex ↓ applierTicker 应用日志 ↓ KVServer 执行命令 ↓ 返回客户端

5. 任期机制隔离旧 Leader

   网络分区后，旧 Leader 可能仍然认为自己是 Leader。Raft 通过任期和多数派提交规则，避免旧 Leader 独立提交新操作