2. 强一致性模型：线性一致性、顺序一致性、因果一致性定义与对比
在分布式缓存与数据库一致性测试中，强一致性模型定义了系统对外呈现的操作顺序约束。理解线性一致性、顺序一致性与因果一致性的差异，是设计一致性测试用例的理论基础。本节从定义、形式化约束、典型场景与对比四个维度展开。
2.1 线性一致性 (Linearizability)
线性一致性是最强的一致性模型，也称为原子一致性或严格一致性。它要求每个操作在调用 (invocation) 与返回 (response) 之间的某个时刻瞬间生效，且所有进程看到的操作顺序与全局实时时钟顺序一致。
- 核心约束：若操作 A 在操作 B 开始之前已完成，则 A 必须排在 B 之前。
- 形式化定义：存在一个合法的全局历史 H，其中每个操作被分配一个唯一的线性化点（linearization point），该点位于操作的调用与返回之间，且 H 满足顺序化与实时性。
- 典型场景：分布式锁、主从复制中的强同步、金融交易系统。
测试要点：线性一致性测试通常需要记录所有操作的调用/返回时间戳，并验证是否存在违反实时顺序的线性化点。常用工具包括 Jepsen 的线性一致性检查器（基于 Wing & Gong 算法）。
2.2 顺序一致性 (Sequential Consistency)
顺序一致性由 Lamport 于 1979 年提出，它放宽了实时约束。要求所有进程看到的操作顺序一致（即存在一个全局合法的顺序），但不要求该顺序与实时时钟一致。
- 核心约束：每个进程自身的操作顺序必须保留；所有进程看到的全局操作顺序相同。
- 形式化定义：存在一个合法的全局历史 H，其中所有操作按某个全序排列，且每个进程的本地顺序是该全序的子序列。
- 典型场景：分布式共享内存、多副本数据库的异步主从复制。
测试陷阱：顺序一致性允许操作重排，只要所有进程看到相同的重排结果。测试时不能仅依赖时间戳排序，必须检查全局历史是否存在合法的全序。常见误判是将违反实时顺序直接判定为不一致。
2.3 因果一致性 (Causal Consistency)
因果一致性进一步放宽约束，只要求具有因果关系的操作按因果顺序被所有进程看到，而并发操作（无因果关系）可以以任意顺序被观察到。
- 核心约束：若操作 A 可能影响操作 B（即 A 发生在 B 之前），则所有进程必须先看到 A 再看到 B。
- 形式化定义：基于 Lamport 的 happens-before 关系。若存在因果关系，则顺序必须保留；否则允许任意顺序。
- 典型场景：社交网络时间线、分布式协作编辑、最终一致性系统的中间状态。
因果一致性测试关键：需要识别操作间的因果关系（如读-写依赖、进程内顺序）。测试工具通常使用向量时钟（Vector Clock）或版本向量来追踪因果依赖。
2.4 三种模型对比
| 对比维度 | 线性一致性 | 顺序一致性 | 因果一致性 |
|---|---|---|---|
| 实时约束 | 必须满足 | 不要求 | 不要求 |
| 全局顺序 | 唯一且与实时一致 | 唯一，但可重排 | 仅因果相关操作有序 |
| 并发操作 | 必须确定顺序 | 必须确定顺序 | 允许任意顺序 |
| 实现代价 | 高（需全局同步） | 中（需全局排序） | 低（仅追踪因果） |
| 典型延迟 | RTT 级别 | 异步复制延迟 | 异步 + 因果依赖 |
| 测试复杂度 | 高（需精确时间戳） | 中（需全局历史） | 中（需因果图） |
2.5 测试视角的关键差异
在分布式缓存与 DB 一致性测试中，选择哪种模型作为测试基准直接影响测试用例设计：
- 线性一致性测试：需要高精度时钟（NTP 同步）或逻辑时钟辅助，验证每个操作的线性化点是否落在实时区间内。适用于强同步复制场景。
- 顺序一致性测试：不需要实时时钟，但需要收集所有进程的操作日志，构建全局历史并检查是否存在合法全序。适用于异步主从复制。
- 因果一致性测试：需要追踪因果关系（如读-写依赖、进程内顺序），使用向量时钟或版本向量。适用于最终一致性系统的中间状态验证。
实践建议：在缓存与 DB 一致性测试中，建议先以线性一致性作为“黄金标准”进行压力测试，若无法满足则降级为顺序一致性或因果一致性测试，并记录违反的边界条件。这种分层测试策略能有效定位系统在不同负载下的行为边界。