4. 数据一致性基础
在金融推理特征缓存体系中，一致性不是抽象的理论标签，而是直接决定“同一客户在不同时点看到的额度、持仓、风险评分是否可信”的工程约束。本节从一致性模型出发，串联 CAP 定理与 BASE 理论，并给出它们在金融系统中的适用边界。
一、核心原理：三类一致性模型的语义差异
一致性模型描述的是“多个副本之间，读写操作对外呈现的顺序与可见性承诺”。金融场景中常用的三类模型如下：
- 强一致性：任何一次读操作都能读到此前已成功提交的最新写结果。对客户端而言，系统仿佛只有一份数据。典型实现依赖共识协议（如 Raft、Paxos）或同步复制，写操作需多数派确认后才返回。
- 最终一致性：写成功后，副本间允许存在短暂不一致窗口，但若无新写入，系统最终会收敛到相同值。它换取的是低延迟与高可用，代价是“读到的可能不是最新值”。
- 因果一致性：只保证有因果关系的操作按序可见，无因果关系的并发操作可任意排序。例如“先冻结额度，再扣减可用额度”必须被所有副本按序感知，而两个互不相关的客户操作可以乱序。
三者的关键区别在于“可见性承诺的强度”与“实现成本”。强一致成本最高，最终一致成本最低，因果一致居中，且更贴近真实业务中“部分操作有依赖、部分操作无依赖”的混合形态。
二、CAP 定理：金融系统无法同时满足三者的现实
CAP 定理指出：在分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）三者最多同时满足两个。由于网络分区在真实金融基础设施中不可避免，分区容错性通常必须保留，因此实际决策退化为“在分区发生时，选择 CP 还是 AP”。
| 系统类型 | CAP 取舍 | 金融场景示例 | 风险与代价 |
|---|---|---|---|
| 交易核心账务 | CP | 支付清算、额度扣减、持仓登记 | 分区时拒绝写入，牺牲可用性保正确 |
| 特征缓存/推荐 | AP | 风险画像、营销标签、实时评分 | 短暂读到旧特征，需容忍并补偿 |
| 行情与资讯 | AP 为主 | 行情推送、公告缓存 | 延迟可见，但不可用于最终结算 |
三、BASE 理论：最终一致性的工程化落地
BASE 是 Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致）的缩写，是对 ACID 的补充而非替代。它承认分布式系统中强一致代价过高，转而通过异步补偿达到业务可接受的收敛。
- 基本可用：分区或过载时允许降级，如返回缓存旧值、限流部分非核心请求。
- 软状态：允许中间态存在，例如“额度冻结中”“特征更新中”，并记录状态机。
- 最终一致：通过重试、对账、补偿任务使副本收敛。
在特征缓存中，BASE 的典型落地是“写主库 + 异步刷新缓存 + 版本号校验”。下面是一段带版本校验的缓存更新伪代码：
def update_feature(customer_id, new_value, version):
# 1. 写主存储，携带单调递增版本号
db.upsert(customer_id, new_value, version)
# 2. 异步失效缓存，避免双写不一致
mq.publish("feature.invalidate", {id: customer_id, ver: version})
def on_invalidate(msg):
cached = cache.get(msg.id)
# 3. 仅当缓存版本落后时才删除，防止旧消息覆盖新值
if cached and cached.version < msg.ver:
cache.delete(msg.id)
四、案例与复盘：额度冻结场景的一致性选择
某消费金融平台在“额度冻结—扣减—释放”链路中，最初将额度缓存设为强一致同步复制，导致高峰期写延迟飙升、超时率上升。复盘后改为分层策略：
- 额度扣减与账务落库走 CP 路径，保证资金正确；
- 额度查询与风控特征走 AP 路径，允许秒级旧值，但附带版本号与“数据时间戳”；
- 对账任务每 5 分钟扫描版本差异，触发补偿刷新。
改造后写延迟下降约 60%，且未出现资金类差错。关键经验是：一致性等级应按数据用途分级，而不是全系统一刀切。资金与账务必须强一致或因果一致；画像、评分、推荐等可最终一致，但必须可观测、可补偿、可追溯。
综上，一致性模型提供语义选项，CAP 划定分区期间的取舍边界，BASE 给出最终一致的工程方法。在金融推理特征缓存中，正确的做法是混合使用：核心资金链路坚持强一致或因果一致，特征与查询链路采用最终一致并配套版本、对账与补偿，从而在正确性、可用性与成本之间取得可解释的平衡。