2. 数据一致性核心概念
2.1 什么是数据一致性
在分布式系统与额度模型场景中，数据一致性指同一份数据在多个副本、多个服务或多个数据库之间的逻辑等价程度。当用户申请额度、模型计算授信、风控策略拦截或额度生效时，所有参与方看到的额度状态必须满足预先定义的约束规则，否则将导致“超授信”、“额度重复发放”或“策略失效”等严重生产事故。
额度场景下的数据一致性本质： 用户可用额度 = 授信总额度 − 已用额度 − 冻结额度，该等式在任何时刻、任何数据副本上都必须成立。
数据一致性通常从三个维度衡量：
- 时间维度： 数据更新后，多久能被所有节点感知。
- 顺序维度： 多个写操作的执行顺序是否全局唯一。
- 约束维度： 业务规则（如额度不超限）是否始终被满足。
2.2 强一致性与最终一致性
分布式系统中最经典的一致性模型对比如下：
| 特性 | 强一致性 | 最终一致性 |
|---|---|---|
| 定义 | 写操作完成后，后续任意读操作都能立即读到最新值 | 写操作完成后，允许短暂不一致，但最终所有副本会收敛到相同值 |
| 延迟容忍 | 零延迟，读必须等待写同步完成 | 可接受毫秒级到秒级延迟 |
| 可用性影响 | 网络分区时可能牺牲可用性（CP） | 网络分区时优先保证可用性（AP） |
| 典型实现 | 分布式事务（2PC/3PC）、Paxos/Raft 强同步 | 异步复制、Quorum 机制、CRDT |
| 额度场景适用性 | 核心扣减、额度生效、策略拦截 | 额度查询、报表统计、非实时风控 |
灰度上线中的权衡： 强一致性保证安全但降低吞吐，最终一致性提升性能但需设计补偿机制。额度模型灰度期间，建议对“扣额”路径采用强一致性，对“查询”路径采用最终一致性。
2.3 额度模型场景下的特殊要求
额度模型不同于普通电商库存或账户余额，其一致性要求具有鲜明的金融风控属性：
- 额度不超授信上限： 任何时刻，用户已用额度 + 冻结额度 ≤ 授信总额度。灰度期间新旧模型并行，必须防止模型切换导致额度重复计算。
- 幂等扣减： 同一笔借款申请在重试、超时或异步回调时，额度扣减必须幂等，不能重复扣减。
- 策略与额度联动： 风控策略拒绝后，额度必须回滚或解冻，不能出现“策略拒绝但额度已扣”的不一致状态。
- 灰度分桶隔离： 灰度桶与基线桶的额度数据必须物理或逻辑隔离，避免灰度模型错误影响全量用户。
- 可观测性： 一致性偏差必须可监控、可告警、可回溯，支持秒级对账。
常见陷阱： 灰度期间使用“先扣额后风控”或“先风控后扣额”两种顺序混用，极易导致额度不一致。必须统一扣额与策略的执行顺序，并在灰度上线前进行全链路对账。
2.4 灰度上线中的一致性策略选择
根据额度模型灰度上线的不同阶段，推荐采用不同的一致性策略：
| 灰度阶段 | 推荐策略 | 原因 |
|---|---|---|
| 小流量灰度（<5%） | 强一致性 | 风险可控，优先保证数据绝对正确，便于问题排查 |
| 中流量灰度（5%~20%） | 强一致性 + 异步对账 | 核心路径强一致，异步对账兜底，平衡性能与安全 |
| 大流量灰度（20%~50%） | 最终一致性 + 补偿机制 | 提升吞吐，通过补偿事务修复不一致，降低对主库压力 |
| 全量上线（100%） | 混合策略 | 扣额强一致，查询最终一致，配合实时对账 |
实践建议： 灰度上线初期不要盲目追求最终一致性带来的性能提升。先以强一致性跑通全链路，确认模型正确后再逐步放宽一致性约束，并配套对账与补偿机制。