3. 一致性理论基础
在银行账务系统中，一致性不是一句口号，而是一组需要被量化、被验证、被权衡的工程约束。很多团队在架构评审时争论“到底选强一致还是最终一致”，本质上是没有把业务语义、故障模型和成本边界讲清楚。本节把CAP、BASE、ACID与最终一致性放在同一张坐标系里，帮助你在真实账务场景中做出可解释的选择。
一、核心原理：CAP不是三选二，而是分区时的取舍
CAP定理指出：在分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）三者不可同时满足。关键点在于：网络分区在跨机房、跨可用区的银行架构中不是“是否发生”，而是“何时发生”。因此P通常必须保留，真正的决策发生在C与A之间。
- CP倾向：分区期间拒绝部分请求，保证读到的数据一定是最新已提交值。典型如核心账务主库、强一致账务登记。
- AP倾向：分区期间继续提供服务，允许短暂读到旧值，事后通过补偿达到一致。典型如查询流水、积分、营销权益。
- CA的误解：单机数据库看似CA，但一旦跨节点复制，就必须面对分区，CA只在“无分区”的理想条件下成立。
二、ACID与最终一致性的对比
ACID是单库事务的经典保证：原子性、一致性、隔离性、持久性。它解决的是“一个事务内的状态跃迁”。而最终一致性解决的是“跨服务、跨库、跨机房的状态收敛”。两者不是替代关系，而是不同粒度上的工具。
| 维度 | ACID（强一致事务） | 最终一致性 |
|---|---|---|
| 一致性时机 | 提交后立即可见 | 经过同步/补偿后可见 |
| 典型范围 | 单库、单服务事务 | 跨服务、跨库、跨机房 |
| 可用性 | 分区时可能降级 | 通常优先保可用 |
| 实现手段 | 锁、MVCC、日志 | 消息、事务消息、对账、补偿 |
| 银行场景 | 扣款、记账、余额更新 | 流水查询、通知、积分、报表 |
三、BASE理论：把“最终一致”拆成可执行动作
BASE是Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致）的缩写。它不是放弃一致性，而是把一致性从“瞬时强约束”转化为“可验证的收敛过程”。
- 基本可用：分区时允许降级，例如查询走只读副本、非核心功能限流。
- 软状态：允许中间态存在，例如“转账处理中”“待对账”。
- 最终一致：通过重试、补偿、对账，使所有副本在有限时间内收敛到同一状态。
四、强一致与弱一致的适用场景
选择一致性模型时，先问三个问题：这笔操作是否涉及资金？错误可见窗口能否被业务容忍？补偿成本是否可控？
- 必须强一致：账户余额扣减、记账凭证生成、额度占用、清算指令。这些场景一旦出现双花或丢失，直接构成资金风险。
- 可最终一致：交易流水查询、消息通知、积分累计、风控画像、报表统计。短暂延迟不影响资金安全，但需要可追溯。
- 弱一致可接受：推荐位、广告计数、非关键埋点。银行核心账务一般不涉及此类，但外围运营系统常见。
五、案例与误区复盘
某银行在“转账+通知”链路中，最初把通知也做成强一致：转账成功后同步调用短信服务，失败则回滚转账。结果短信网关抖动导致大量转账失败，资金业务被非核心依赖拖垮。复盘后改为：转账主链路强一致，通知走事务消息+重试，允许秒级延迟，最终一致。这就是典型的“把一致性级别用错位置”。
账务一致性检查清单：
1. 该操作是否涉及资金变动？是 → 强一致或事务消息。
2. 中间态是否可被业务感知？是 → 设计状态机与超时。
3. 失败后是否有补偿入口？无 → 不允许上线。
4. 是否有对账任务兜底？无 → 最终一致不成立。
5. 错误可见窗口是否在业务容忍范围内？否 → 升级一致性级别。总结来看，CAP告诉你分区时只能取舍，BASE告诉你如何把取舍变成可收敛的工程过程，ACID负责单点事务的正确性，最终一致性负责跨域状态的收敛。银行账务架构的真正难点，不是记住这些名词，而是为每一类业务找到它该待的位置。