一致性模型与 CAP 理论与 Zab 与 Gossip 等其他复制协议

• 线性一致性：实时全序（最强）
• 顺序一致性：全序但允许重排、不考虑实时
• 因果一致性：仅保证因果序

三者强弱关系为：线性一致性（linearizability）> 顺序一致性（sequential consistency）> 因果一致性（causal consistency）。线性一致性要求所有操作按"实时全序"生效，即操作在调用与返回之间某个瞬间生效，且与真实时间顺序一致，任何其他操作都不能插在中间；顺序一致性只要求存在一个全局全序，使所有节点看到相同顺序，但允许与真实时间不符（重排并发操作）；因果一致性只要求有因果关系的操作按因果顺序被观察到，无因果关系的并发操作可任意顺序。线性一致是最强、最利于推理，但成本最高；因果一致在分布式键值系统中常用，兼顾语义与性能。

强弱关系体现在"对顺序的约束"：线性一致约束实时序，顺序一致约束全序但允许重排，因果一致只约束因果序。理解该谱系有助于在系统设计中按需选择，避免过度强一致或过度弱一致。

• READ-YOUR-WRITES：自己写的自己必能读到
• MONOTONIC READS：读到的值单调不后退
• WRITES-FOLLOW-READS：先读后写保证写在其后

会话一致性保证提供"单个客户端会话内"的可预测读。READ-YOUR-WRITES（读己之写）：客户端写入后，后续读必须能看到该写入（或更新的值），避免"写后读不到"；MONOTONIC READS（单调读）：客户端多次读同一数据，读到的值只能单调前进，不会回退到旧值，避免"读到旧值后又读回更旧值"；WRITES-FOLLOW-READS（写后读/读后写）：客户端写完某值后，后续写必须因果上建立在该写之后，避免"先读到新值再写却基于旧值"。这些是很弱的保证，不需要全局一致，只约束单个会话内的可见性，常用于 AP 系统（如 Cassandra、DynamoDB）向客户端提供可接受的语义。

会话一致性是"客户端视角"的保证，比全局一致弱但比无保证强。它们把"最终一致"提升为"客户端可感知的确定顺序"，是分布式存储中重要的工程权衡手段。

• 最终一致性不保证实时/顺序一致
• 收敛需通信、无新写入、冲突解决
• 最终一致的时间不确定性

最终一致性是弱一致性的一种，因为它不保证读操作立即返回最新值，也不保证所有操作按全局顺序一致，只通过"最终所有副本收敛到相同状态"来保证一致性。收敛性（convergence）需要若干前提：副本间能持续通信（交换更新）、在没有新写入的稳定期后收敛、冲突解决是确定性的（如 LWW、CRDT 合并规则）、更新不丢失（或有可靠传播）。收敛时间不确定，取决于网络传播与副本状态。也正因如此，最终一致性无法提供强一致的系统级保证，但换取高可用与低延迟。

最终一致性的"弱"体现在"无实时保证、无全序"，其收敛依赖"通信 + 确定性冲突解决 + 稳定期"。理解收敛前提有助于判断某系统是否真正满足最终一致，以及何时可以安全使用。

• 线性一致性针对单键操作（读写）
• 可串行化针对事务（多操作）
• 严格可串行化 = 可串行化 + 线性一致

线性一致性（linearizability）针对单键/单对象操作，保证该对象的读写按实时全序生效；可串行化（serializability）针对事务，保证并发事务的执行结果等价于某个串行顺序，且事务内部操作作为一个整体原子执行。严格可串行化（strict serializability）是二者的组合：要求事务的执行顺序既满足可串行化（等价串行），又满足线性一致性（与实时时间序一致，即事务按提交顺序生效）。它是最强的事务隔离保证，常用于分布式数据库（如 Spanner、CockroachDB）对外承诺。严格可串行化比可串行化更强，因为多了"与实时序一致"的约束。

线性一致是"单对象"的实时全序，可串行化是"事务"的等价串行，严格可串行化把两者结合，要求事务的串行顺序同时尊重实时时间。理解这一组合有助于区分数据库隔离级别与系统级一致保证。

• 用时间戳近似因果顺序
• 时钟漂移导致时间戳与因果序不符
• 破坏因果一致性与读可见性

基于领导者时间戳的因果一致性实现（如用单一时钟源为每个写操作打时间戳）依赖"时间戳近似因果顺序"：若操作 A 因果先于 B，则 A 的时间戳应小于 B 的时间戳，这样副本按时间戳应用即可保持因果序。这依赖时钟"近似有序"（leader 时钟单调、足够快）。若时钟漂移（回拨、剧烈跳变），则可能 A 的因果序在 B 之前但时间戳更大，导致副本按时间戳应用时顺序错乱，破坏因果一致性（用户可能看到"后来者"先于"先导者"）。时钟漂移因此破坏"时间戳反映因果序"这一前提，使基于时间戳的因果保证失效，需改用逻辑时钟或带误差界的时间戳（如 HLC、TrueTime）。

"时间戳近似因果序"是工程上用物理时钟近似因果的捷径，但强依赖时钟同步质量。时钟漂移打破这一前提，故高可靠因果系统采用逻辑时钟或带误差界的混合时钟，而非纯物理时间戳。

• Zxid 由 (epoch, counter) 组成
• 选主时比较 epoch 优先、counter 其次
• 保证新 leader 继承最新已提交事务

Zxid 是 Zab 中事务的全序标识，由两部分组成：高位的 epoch（纪元，对应 leader 任期）与低位的 counter（事务计数器，在 epoch 内单调递增）。两个 Zxid 比较时先比 epoch，epoch 大者更新；epoch 相同再比 counter，counter 大者更新。选主（leader election）时，各候选者携带自己最后处理的 Zxid，通过比较 Zxid 确定谁拥有最新的事务历史，从而保证新 leader 继承所有已提交事务、不丢失已提交数据。它把"任期"与"事务序"统一进一个可比较的标量，简化了选主时的事务新旧判断。

Zxid 用 (epoch, counter) 把"属于哪个 leader 任期"与"该任期内的顺序"编码为可全序比较的标量，是选主与全序广播的关键。epoch 防止旧 leader 的事务与新 leader 混淆，counter 保证任期内的提交顺序。

• lease holder 承担读写一致性
• 就近 replica 读需 lease 或共识
• 线性一致读与延迟的权衡

CockroachDB 中，每个 range 的副本中有一个 lease holder（租约持有者），它负责协调该 range 的读写与一致性。写操作由 lease holder 协调并经 Raft 提交；读操作若要保证线性一致，CockroachDB 优先把读路由到 lease holder（因为 lease holder 有最新提交信息），或通过对齐读时间戳（follower read）允许就近的 follower replica 读旧于 lease 时间戳的数据。FoundationDB 类似，读通过一致性协调定位最新副本。就近 replica 读（follower read）可降低延迟，但牺牲一定的实时一致性（读到稍旧数据），需在"延迟"与"新鲜度"间权衡。lease holder 机制让读在多数场景本地完成，避免每次读都走共识。

lease holder 提供"读的权威锚点"，就近读通过引入"时间戳/租约"换取低延迟。这种"lease holder + 就近 replica"的读路由是分布式数据库平衡线性一致读与延迟的经典设计。

• 崩溃恢复阶段的工作（发现、同步、广播）
• 已提交事务从多数派恢复
• 未提交事务被丢弃

Zab 的崩溃恢复阶段分为发现（Discovery）、同步（Synchronization）、广播（Broadcast）三个阶段。崩溃后，新 leader 在发现阶段收集各 follower 的已接受事务与 Zxid，找出已被多数派接受的最新已提交事务；同步阶段将 leader 确认的已提交事务（包括多数派已确认的）同步给所有 follower，保证已提交事务不丢失；未被多数派确认、未提交的事务则被丢弃（不作为提交状态）。通过"以多数派已处理的最新 Zxid 为基准"进行同步，Zab 保证崩溃后已提交事务完整保留、未提交事务被清除，从而维持一致性。

崩溃恢复的关键是"以多数派状态的并集为基准"：已提交事务必然存在于多数派中，新 leader 从多数派恢复并同步给所有人，从而不丢失；未达多数派的事务因未提交而被丢弃。这体现了"多数派相交"保证不丢失已提交事务的原理。

• 反熵：随机配对交换状态
• 信息传播的指数增长（每轮翻倍）
• O(log N) 轮的收敛

Gossip 协议中，节点周期性随机选取一个或多个对等节点交换状态（反熵 convergence），信息以"指数扩散"方式传播：每轮每个知情节点把信息传给随机邻居，知情节点数近似每轮翻倍（类似流行病传播），因此约 log2(N) 轮后所有节点都知情。因为每轮知情节点随机扩散，覆盖范围按指数增长，达到全体所需的轮数约为 O(log N)。随机配对保证信息最终覆盖所有节点，反熵的定期交换使状态收敛到一致。

信息传播的"指数级扩散"是 O(log N) 收敛的根源：每轮知情节点数翻倍，故轮数正比于 log N。随机配对 + 定期交换（反熵）保证无中心、无单点地最终一致，是 Gossip 的健壮性来源。

• last-write-wins 用时间戳/版本号胜出
• vector clock 检测并发写
• 冲突解决的交由客户端或 LWW

Cassandra 等基于 Gossip 的最终一致系统，用版本号/时间戳解决并发写冲突：每个写携带客户端的写入时间戳（或版本），合并时 last-write-wins（LWW）取时间戳最大的值。同时用 vector clock（或版本向量）检测并发写：若两个写互为因果（一方更新），则取更新者；若并发（无因果），则保留多个冲突值（sibling），由客户端在读取时解决，或用 LWW 以时间戳定型。时间戳提供"最新胜出"的确定性，vector clock 提供"因果/并发"的检测，二者配合使并发写最终收敛到确定状态。

LWW 用时间戳提供确定性胜出，vector clock 提供并发检测。二者结合让 Cassandra 在"无中心 + Gossip 传播"下能处理并发写冲突并最终一致，代价是 LWW 可能覆盖语义上更重要的并发更新。

• lease 授予以 leader 为中心的时长
• 租约期内 leader 本地读、无需共识
• 时钟漂移可能导致租约重叠、读到过期

lease（租约）机制中，leader 在当选时向多数派发起"租约授予"，租约有个期限（通常为选举超时下限）。在租约有效期内，leader 保证多数派在租约结束前不会选举新 leader，因此 leader 可以确认自己仍是 leader，从而在本地直接读（无需每次向多数派发心跳确认），显著降低读延迟。此时只有 leader 能提交，故本地读是线性一致的。风险在于：若 leader 时钟漂移（过快/过慢），租约可能被多计或重叠——例如 leader 认为自己租约仍在，但实际租约已过期、多数派已选出新 leader，此时 leader 本地读会读到过期数据，破坏线性一致。故租约长度必须保守，且依赖时钟同步质量。

lease 用"多数派承诺 + 时间"换取"本地读"，是性能与安全性的权衡：租约期内 leader 免于每读一次共识，但必须严格控制租约边界与时钟漂移，否则可能读到过期数据，破坏线性一致。

• Zab 的过半 ACK + 多数派容错
• 2PC 协调者单点 + 全参与方阻塞
• 崩溃恢复 vs 阻塞

Zab 通过"leader 广播 proposal + 多数派（过半）ACK + 提交"实现事务全序：只要多数派确认，事务即提交，即使少数派故障也能继续，且可选出新 leader 继续，不阻塞。2PC 则需要所有参与者都同意（全部 ACK）才能提交，且协调者单点故障时参与者会阻塞等待（无法确定提交或中止），导致阻塞性。本质区别：Zab 用"多数派 + 可恢复的 leader 选举"保证活性与不阻塞，2PC 用"全体一致 + 无选主"在协调者故障时阻塞。Zab 牺牲了"所有节点强一致"换取了不阻塞与高可用。

Zab（及 Raft）的"过半 ACK + 选主恢复"是克服 2PC 阻塞性的关键：多数派存活性 + 可恢复的协调者，使协议在故障下不阻塞。2PC 的阻塞源于"全体一致"与"协调者单点"的组合，无选主机制时的典型缺陷。

• CAP：分区时在 C 与 A 间取舍
• PACELC：无分区时也有 E 与 C 的取舍
• 两类场景的权衡

CAP 定理指出，在分布式系统中，一致性（C）、可用性（A）、分区容忍性（P）三者不可能同时满足：当发生网络分区（P 被强制满足）时，系统只能在"保持一致性（拒绝部分请求）"与"保持可用性（响应但可能过期）"之间二选一。CAP 只覆盖"分区时"的权衡。PACELC 扩展了 CAP：PACELC 表示"如果分区（P），则在一致性（A/C）间取舍；否则（E，无分区时），在延迟（L）与一致性（C）间取舍"。即 PACELC 指出，即使没有分区，系统也可以在"降低延迟"与"保持一致性"之间权衡（如副本地读延迟低但可能陈旧）。因此完整权衡是"分区时 C/A + 平时 E/L/C"。

CAP 是不完备的，PACELC 补全了"无分区时"的权衡。理解二者有助于在系统设计中明确：分区时选 C 还是 A，平时选更低的延迟还是更强的一致，从而做出符合业务的取舍。

• 向量时钟完整记录每节点因果序
• 比较向量判断因果/并发
• Lamport 无法区分并发，向量时钟可以

向量时钟用长度等于节点数的向量记录每个节点的事件计数，发送消息时携带本节点的向量并合并，接收时逐分量取 max。比较两个向量：若 v1 所有分量 ≤ v2（且至少一个 <），则 v1 因果先于 v2（v1→v2）；若存在分量互有大小（一个分量大、另一个分量小），则两者并发（无因果）。相比 Lamport 时钟（只有一个标量，只能给出全序但无法区分并发），向量时钟多捕获了"并发关系"的信息：它不仅能判断因果先后，还能识别无因果关系的并发事件，从而用于冲突检测（如检测并发写）。代价是存储开销与节点数成正比（O(N)）。

Lamport 时钟把并发事件也强行排序，无法区分"因果"与"并发"；向量时钟通过记录每个节点的分量，能精确判断因果/并发，是冲突检测和因果一致性的基础。其代价是 O(N) 的元数据开销。

• R+W>N 保证读写集合相交
• 相交使读必包含最新写的副本
• R+W<=N 时读可能错过最新

在 Quorum NWR 模型中，W 个副本写完才算成功，R 个副本读齐才算成功。当 R+W>N 时，读集合与写集合必然相交（因为两者数量之和大于节点总数），因此读操作至少会读到一份最新写入的副本，从而保证读到最新值。当 R+W≤N 时，读集合可能与写集合不相交，读可能错过所有最新写入的副本，读到过期数据，从而丢失"读到最新值"的保证。因此 R+W>N 是"读写不冲突"的安全条件，工程上常取 R+W=N+1（如 R=1,W=N 或 R=N,W=1）平衡。

R+W>N 是"读必须读到最新写"的集合论条件：读写集合相交使其必然包含最新副本。R+W≤N 允许读写集合不相交，读到过期但可能被接受。这是多数派相交思想在 NWR 模型中的体现。

• CP 系统分区时拒绝请求保一致
• AP 系统分区时正常响应保可用
• 代表系统（ZooKeeper、Raft vs Cassandra、DynamoDB）

CP 系统（C 优先）在网络分区时选择保持一致性：放弃部分节点的可用性，拒绝分区侧的请求（少数派不服务），保证所有返回的数据一致，代表如 ZooKeeper、etcd、Raft 类系统、HBase。AP 系统（A 优先）在分区时选择保持可用性：所有分区仍正常响应请求（可能返回过期或冲突数据），用最终一致收敛，代表如 Cassandra、DynamoDB、CouchDB。差异本质是：分区时 CP 把"一致"放首位、牺牲可用，AP 把"可用"放首位、牺牲实时一致。设计上根据业务对"一致 vs 可用"的偏好选择。

CP 与 AP 是 CAP 权衡的两端：CP 采用"少数派拒绝"保障安全，AP 采用"多活 + 最终一致"保障可用。选择取决于业务对可用性与一致性的容忍度，常见系统是二者混合（如按操作选择）。

• Zab 的 DISCOVER/SYNC 阶段
• Raft 的 AppendEntries 一致性检查
• 同步方式与差异

Zab 与 Raft 都采用 leader 复制，但日志同步阶段不同。Zab 在选主后先经历 DISCOVER 阶段（new leader 收集 follower 的已接受事务与 Zxid，确定同步起点）与 SYNC 阶段（把 leader 确认的事务按序同步给 follower，使 follower 追上 leader），然后再进入 BROADCAST 阶段复制新事务。Raft 则用 AppendEntries 统一处理：leader 通过携带 prevLogIndex/prevLogTerm 的一致性检查，逐条/批量把日志同步给 follower，冲突时回退对齐，无需单独的发现阶段，选主后直接开始复制。差异在于：Zab 把"同步追平"显式拆为发现+同步阶段，Raft 把"同步 + 新复制"统一在 AppendEntries 的一致性检查中完成。

两者目标一致（让 follower 追上 leader 的已提交日志），但 Zab 用显式 DISCOVER/SYNC 阶段、Raft 用 AppendEntries 的一致性检查 + 回退。Raft 更简洁统一，Zab 更显式。理解差异有助于对比两种协议的设计取舍。

• read-any-replica 低延迟但可能陈旧
• majority-read 保证最新但延迟高
• 一致性与延迟的权衡

Speculative Replication（推测性复制）中，read-any-replica 允许读取任意副本，延迟最低（就近读），但可能读到过期/未提交数据，一致性弱；majority-read 要求读取多数派副本并合并，保证读到最新已提交值，但延迟高（需多数派 RTT）。两者是"延迟 vs 一致性"的权衡：read-any-replica 以一致性换取低延迟，majority-read 以延迟换取强一致。工程上常按数据/请求类型选择：低价值数据用 read-any-replica，关键数据用 majority-read 或 lease/ReadIndex 保证一致。

read-any-replica 与 majority-read 是"读一致性"的两个端点。read-any 牺牲一致性换延迟，majority-read 牺牲延迟换一致。设计需根据数据新鲜度要求在两极间权衡，或用 lease 等机制折中。

• Cosmos DB 多区写用 speculative replication
• session consistency 保证单会话读写一致
• 低延迟与一致性的平衡

Cosmos DB 的多区写（multi-region writes）采用推测性复制（speculative replication）支持多区域并发写，同时提供 session consistency（会话一致性）作为默认的一致性级别。session consistency 保证单个客户端会话内"read-your-writes、monotonic reads、writes-follow-reads"等确定性，使客户端在多区写、就近读下感知到一致的读写顺序，而不必牺牲全局实时一致。工程价值在于：speculative replication 提供多区低延迟写入，session consistency 在客户端层面提供可预测的一致性，二者结合让 Cosmos DB 在"多区高可用 + 低延迟 + 客户端可感知一致"之间取得平衡，是分布式数据库多写场景的实用设计。

speculative replication 换取多区低延迟多写，session consistency 提供"客户端视角"的一致保证，避免每个请求都走全局强一致。这是"多写 + 会话级一致"的典型权衡，兼顾延迟与可接受的一致性。

• Lamport 时钟只给全序标量
• 并发事件被强行排序
• 向量时钟记录每节点分量以区分并发

Lamport 时钟为每个事件分配一个标量时间戳，且满足"若 a 因果先于 b，则 L(a)<L(b)"。但反过来不成立：若 L(a)<L(b)，无法推出 a 因果先于 b，因为两个并发事件也可能得到不同的 Lamport 时间戳（被强行排序）。因此 Lamport 时钟无法从时间戳判断两个事件是否并发。向量时钟用长度等于节点数的向量记录每个节点的事件计数，比较两个向量可精确判断：若 v1 所有分量≤v2 则为因果，若互有大小则为并发。向量时钟弥补了 Lamport"无法区分并发"的缺陷，能识别无因果关系的并发事件，用于冲突检测。

Lamport 时钟用"一个标量"换取全序，代价是丢失了"并发"信息；向量时钟用"N 个分量"恢复并发信息，代价是 O(N) 开销。向量时钟是 Lamport 时钟在"因果 vs 并发"识别上的完备化。

• HLC 物理时间 + 逻辑计数器
• 逼近物理时间且满足因果序
• 相对 Lamport 的优势（贴近物理时间）

HLC（Hybrid Logical Clock）为每个事件维护 (physical time, logical counter) 二元组：物理时间取本地物理钟与消息携带的最大物理时间，逻辑计数器在物理时间相同时递增。HLC 值始终逼近物理时间（接近真实时间），同时满足因果序（若 a 因果先于 b，则 HLC(a)<HLC(b)）。相对纯 Lamport 时钟，HLC 的优势在于：它保留了"近似物理时间"这一信息，使时间戳可直接用于排序、推断"某个物理时刻之后"等场景（如跨数据库排序、快照），而 Lamport 时钟的时间戳与物理时间脱节、无法给出有意义的"真实时间"参考。因此 HLC 兼具因果序与物理时间近似，是分布式数据库（如 CockroachDB、TiDB）的主流选择。

HLC 把"物理时间"与"逻辑因果"结合：物理时间保证贴近真实、逻辑计数器保证因果序与冲突时的区分。它弥补了 Lamport"无物理时间参考"的缺陷，是"要物理时间又要因果序"场景的工程折中。

• Gossip 的随机传播与概率性收敛
• 反熵（anti-entropy）的最终一致
• 节点失效与网络分区对收敛的影响

Gossip 的收敛是概率性的：因为信息传播依赖随机选择对端节点进行交换，每个节点在每轮只与随机选中的少数节点交换，经过多轮后信息以高概率扩散到全网，但收敛所需轮数（或覆盖率）是概率性的而非确定性的——存在很小的概率某些节点迟迟未收到更新。节点失效与网络分区会显著影响反熵（anti-entropy，定期交换全量数据使节点渐趋一致）的最终一致：分区的节点无法交换数据，反熵无法进行，分区两侧数据各自演化，只有分区恢复后才重新收敛；失效节点丢失数据则可能导致已传播的数据丢失，破坏最终一致。因此 Gossip 的最终一致是"概率性 + 分区恢复后"的收敛，而非强一致。

Gossip 收敛取决于随机交换的传播覆盖，概率性来自随机对端选择；分区与失效阻断信息交换，使反熵无法推进，只能等分区恢复、节点存活后重新收敛，故最终一致是概率性与有条件（分区恢复）的。