《后端架构设计·分布式与数据一致性》附录 C 分布式一致性验证清单

清单怎么用

这不是一张"跑一遍就打勾"的表。它的用法是：每次改动涉及复制、分片、事务、消息或锁时，从六类场景里选出受影响的两到三类，按表准备、注入、观测、判定、回滚。

使用前先确认三个前提：

1. 每个场景都有明确的业务不变量，且不变量能写成断言；
2. 注入手段可停止、作用范围可控；
3. 观测信号能在同一条时间轴上对齐。

缺任何一条，验证都会退化为"看起来恢复了"。附录 A 给模型与故障语义，本附录给可执行步骤，两者配合使用。

共用前置：六类场景都要准备

数据准备容易被低估。跨分片与对账场景需要可构造的"漏单、重复、金额差、状态差"，如果只能等真实流量出现，验证就无法按计划执行。正确做法是准备一组可重置的订单与流水样本，并在每次执行前恢复到已知状态。

判定不变量先写成断言

断言要能直接查库或查接口，不接受"人工看一眼"。人工判断只用于分类与处置，不用于判定通过与否。

场景 1：单主复制切换

这张表里最容易写错的是"通过标准"。RPO 与 RTO 必须是团队自己确认的目标值，不能照抄别处的数字。同步复制声明 RPO 为 0，前提是提交确认确实等待了多数派；如果客户端在本地提交后就收到成功，故障切换仍可能丢尾部。

“假死"比"进程退出"更值得测。进程暂停时，健康检查可能仍认为它存活，选主不会立即发生；恢复后它可能带着旧任期继续写。判定要点不是"多久恢复”，而是"恢复后有没有被 fencing 拦住"。

场景 2：跨分片下单

跨分片场景的难点不是"失败"，而是"不知道失败"。订单提交超时后，订单可能已创建，也可能没有；库存可能已预留，也可能没有。验证时必须覆盖四种组合，而不是只测"两边都成功"和"两边都失败"。

判定时先看订单，再看预留，最后看补偿记录。如果订单不存在但预留存在，说明补偿还没跑或丢了；如果订单存在但预留不存在，说明订单侧越过了预留直接提交。两种都是不变量破坏，不能只看最终库存数。

场景 3：重复消费

重复消费的验证不能只看"第二次有没有报错"。正确做法是对比两次执行后的业务快照：订单状态、库存余量、流水条数、账户余额都必须一致。

还要测"副作用已发生但确认未发出"的窗口。消费者在写业务表和写去重表之间崩溃，恢复后消息重投，如果去重表尚未写入，副作用就会发生第二次。解决方式是把业务写入与去重写入放在同一本地事务，或者让业务操作本身带唯一约束。相关分析见 8.2 消费端幂等、去重表与恰好一次的真实边界 。

场景 4：锁过期

锁过期场景的核心不是"锁会不会过期"，而是"过期之后旧持有者还能不能造成影响"。如果存储侧只认"当前锁的 key 存在"，旧持有者恢复后可能在新持有者持锁期间写入；只有比较 fencing token 或版本号，才能拒绝陈旧写。

本场景必须与业务不变量一起判定。锁本身没有对错，只有"锁失效时业务是否仍然正确"。这和第 10.3 锁失效后的正确性：从互斥到幂等 的结论一致。

场景 5：时钟回拨

回拨的影响面比想象中宽：Snowflake 类 ID 可能重复，基于时间的 TTL 可能提前过期，租约可能被误判失效，按时间排序的事件流可能乱序。验证时要分别检查这四条，不能只看 ID。

“示例 5 分钟"只是注入幅度，不代表真实环境的最大偏差。真实偏差取决于 NTP 配置、虚拟化时钟和运维操作；团队应记录自己环境的历史最大偏差，并据此设计回拨策略。

场景 6：对账收敛

对账是最后一道防线，不是唯一防线。它验证的是"前面的机制漏了之后，系统能不能发现并收敛”，因此必须故意制造差异，而不是等差异自然出现。

判定时要区分"收敛"与"掩盖"：如果对账任务把差异直接改成一致，却没有留下分类与原因，下一次同类问题仍会发生。通过标准里必须包含"差异可解释"，否则只是把问题藏起来。

演练顺序：先单点，后组合

六类场景不要一次全上。推荐的顺序是先验证单点机制，再验证复制与分片，最后才做组合。原因很简单：多个故障叠加后，观测信号会互相污染，归因变得不可能。

组合场景一次只加一个变量。例如先做"复制切换 + 重复消费"，确认消息在切换后重投仍幂等；再加"跨分片"，观察补偿与切换是否冲突。一次叠加三个以上故障，通常只能得到"系统很乱"的结论。

数字口径：实测、目标与示例

附录里的每个数字都必须带口径，否则无法判断它能不能用于验收。

三条规则：

1. 目标值不能从别处照抄，必须由业务与运维共同确认；
2. 实测值必须附环境与命令，换机器、换版本后不能直接复用；
3. 示例值不能进入验收标准，只能出现在讲解与注入设计里。

把"目标 RPO 为 0"写成"实测 RPO 为 0"，是文档里最危险的错误之一。前者是承诺，后者是结论，两者需要的证据完全不同。

观测信号怎么对齐

验证失败最常见的原因不是系统坏了，而是信号对不上。下面五类信号要能在同一时间轴上关联：

对齐不了时，先修观测再演练。凭日志猜时间线，得到的结论无法复现，也无法说服别人。

上线前 20 条检查

二十条里，1、2、12、14、19 最容易被跳过。它们不直接产生功能，却决定故障时能不能发现问题、能不能拒绝陈旧写、能不能复现结论。

通过、失败、无效三态

验证结论只有三种，不要用"基本通过"糊过去：

“无效"最容易被误记为"通过”。例如注入的网络分区实际没有切断流量，服务自然一切正常；或者观测指标没有采集，只能凭日志猜测。这类结果必须标记为无效，否则会给出虚假的信心。

执行记录模板

每次验证至少记录以下字段：

场景：
目标不变量：
环境与版本：
注入手段与幅度：
开始时间 / 结束时间：
观测到的关键信号：
不变量检查结果：
结论：通过 / 失败 / 无效
失败或无效的原因：
回滚是否执行、耗时：
后续改进项与 owner：

记录要能支撑另一个工程师复现同一次验证。只写"切换成功"没有价值；写清"在什么拓扑、什么复制模式、什么注入幅度下，哪个不变量在什么时间点被检查、结果如何"，才有价值。

场景选择：改了什么就测什么

不必每次跑满六类。按改动触及的机制选场景，既省时间，也不遗漏关键风险：

一次改动触及多条机制时，取并集，不要只选"最相关"的一条。例如同时改分片与消息消费，就要覆盖跨分片下单和重复消费，并额外做一次组合验证。

六个常见错误

第一，只测成功路径。跨分片下单如果只测"库存和订单都成功"，永远发现不了悬挂。

第二，把超时当失败。超时是"未知"，需要查询或幂等重试；直接判失败会掩盖已提交的副作用。

第三，注入不可停止。任何故障注入都必须有对应的停止手段和范围限制。

第四，没有基线。注入前不记录正常指标，事后无法判断"恢复了没有"。

第五，只验证最终数值，不验证中间态。最终库存正确，不代表过程中没有超卖；最终订单正确，不代表没有重复扣款。

第六，把一次通过当成永久结论。拓扑、版本、流量、配置变化后，原来的结论不再成立，需要重新验证。

小结

六类场景覆盖了卷三的主要风险面：复制切换看丢失窗口，跨分片下单看中间态，重复消费看副作用边界，锁过期看 fencing，时钟回拨看 ID 与 TTL，对账收敛看兜底能力。

执行时记住三句话：

1. 先写不变量，再设计注入，最后才看指标；
2. 目标值必须注明来源，实测值必须可复现；
3. 通过、失败、无效三态分明，不用"基本正常"代替结论。

把这六类场景和二十条检查接进发布流程，比在事故后补文档更省成本。卷四会讨论如何把其中可自动化的部分平台化，但在那之前，先把每一次验证做成可重复、可追溯的记录。