3. 一致性验证基础
在金融账务系统中，“一致性”不是一个抽象口号，而是直接决定资金安全、对账结果和监管合规的工程约束。做故障注入与一致性验证之前，必须先厘清强一致性、最终一致性、CAP 定理与 BASE 理论在账务语境下的真实含义，否则测试用例会失去判定基准。
一、核心原理：四种概念在账务系统中的落地含义
强一致性指任何一次成功写入后，后续任意读操作都能立即读到该结果。在账务中，它通常表现为：同一账户的余额扣减与流水写入在同一事务内完成，且主库提交后所有读路径（含从库、缓存）不得返回旧值。典型实现是单库事务、分布式事务（如 TCC、XA）或基于共识协议的复制。
最终一致性指系统允许中间状态存在，但经过有限时间后，所有副本必须收敛到同一结果。账务中的典型场景是跨行转账的异步清算、积分与主账的异步入账、对账文件的批量补账。它不承诺“立刻正确”，但承诺“最终可验证正确”。
CAP 定理指出，在分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）三者不可同时满足。金融账务系统必须选择 P（网络分区不可避免），因此真正的取舍发生在 C 与 A 之间：是拒绝服务保一致，还是继续服务但接受短暂不一致。
BASE 理论是对 CAP 中 AP 方向的延伸，包含基本可用（Basically Available）、软状态（Soft state）、最终一致（Eventually consistent）。它适合高并发支付、营销账务等场景，但不适合核心总账的实时扣款路径。
二、方法流程：一致性取舍的判定步骤
面对一个账务接口，不能凭感觉选择一致性模型，建议按以下流程判定：
- 识别资金风险等级：是否直接扣减用户可用余额，是否涉及监管报送，是否允许事后冲正。
- 确定读写路径：写主库还是分片，读主库、从库还是缓存，是否存在跨服务调用。
- 标注分区场景：网络抖动、主从延迟、机房故障时，系统应拒绝还是降级。
- 选择一致性模型：核心扣款走强一致；通知、积分、统计走最终一致。
- 设计验证断言：强一致验证“读后写立即可见”，最终一致验证“窗口期内收敛且可对账”。
三、案例/场景：转账与积分入账的差异
以“用户 A 向用户 B 转账 100 元”为例。A 的扣款与 B 的入账若在同一核心账务库，应采用强一致事务：
BEGIN;
UPDATE account SET balance = balance - 100 WHERE user_id = 'A' AND balance >= 100;
INSERT INTO ledger(user_id, amount, type) VALUES ('A', -100, 'TRANSFER_OUT');
UPDATE account SET balance = balance + 100 WHERE user_id = 'B';
INSERT INTO ledger(user_id, amount, type) VALUES ('B', 100, 'TRANSFER_IN');
COMMIT;若 B 的入账通过消息队列异步完成，则属于最终一致。此时必须验证：消息不丢、不重、可补偿，且在对账窗口内 B 的余额与流水一致。故障注入可模拟“扣款成功但消息发送失败”，观察补偿任务是否在 5 分钟内完成冲正或重投。
| 业务场景 | 一致性模型 | CAP 取舍 | 验证重点 |
|---|---|---|---|
| 核心总账实时扣款 | 强一致 | CP | 提交后读主库立即可见，余额不为负 |
| 支付结果通知 | 最终一致 | AP | 消息幂等、重试、窗口内收敛 |
| 积分/权益入账 | 最终一致 | AP | 软状态可追踪，T+1 对账平衡 |
| 跨行清算文件 | 最终一致 | AP | 批量补账、差错挂账可核销 |
四、误区/复盘：常见错误与纠正
- 误区一：所有账务都必须强一致。强一致会牺牲可用性，高并发营销账务若全量强一致，容易在分区时整体不可用。应按资金风险分级。
- 误区二：最终一致等于“不用管”。最终一致必须配套幂等、重试、对账和补偿，否则会永久不一致。
- 误区三：CAP 是“三选二”的静态选择。实际系统可在不同接口、不同时段做动态取舍，核心链路 CP，边缘链路 AP。
- 误区四：BASE 可以用于核心扣款。BASE 的软状态不适合实时余额扣减，否则会出现超扣、重复扣。
掌握这些基础后，后续故障注入才能有的放矢：对 CP 链路注入分区与主从延迟，验证拒绝策略；对 AP 链路注入消息丢失与重复，验证补偿与对账收敛。一致性模型的选择，最终要落到可验证的断言和可复现的故障场景上。