线性一致性Linearizability**是分布式系统中的一种强一致性模型。一句话定义所有操作看起来都像是在某个唯一时间点瞬间完成并且这个时间点必须位于操作发起和响应之间同时不能违背现实时间顺序。核心要求假设有多个客户端同时访问一个分布式 KV 系统。线性一致性要求所有客户端看到一个统一的操作顺序。如果操作 A 已经完成后操作 B 才开始那么全局顺序中 A 必须在 B 前面。如果两个操作时间上重叠可以任选一个合理顺序。每次读取都必须看到它之前已经完成的最新写入。简单例子初始状态x 0执行过程客户端 APut(x, 1) ───────── 返回成功 客户端 BGet(x)因为Put(x, 1)已经返回后B 才发起读取所以线性一致性要求Get(x) 必须返回 1或者返回在它之后写入的更新值不能返回旧值0。并发操作的情况客户端 APut(x, 1) ─────────── 客户端 BPut(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 主要提供以下基础所有写请求通过 LeaderLeader 决定日志顺序避免不同节点各自决定顺序。日志按照统一顺序复制index 1Put(x, 1) index 2Put(y, 2) index 3Get(x)所有状态机按照日志 index 顺序执行。获得多数派确认后才能提交Leader 不能收到请求后立即返回成功必须先把日志复制到多数节点。提交后再应用到状态机客户端请求 ↓ Leader 写入日志 ↓ 复制到多数节点 ↓ 更新 commitIndex ↓ applierTicker 应用日志 ↓ KVServer 执行命令 ↓ 返回客户端任期机制隔离旧 Leader网络分区后旧 Leader 可能仍然认为自己是 Leader。Raft 通过任期和多数派提交规则避免旧 Leader 独立提交新操作