高并发交易系统中 CAP 与 BASE 的适用边界如何影响一致性、可用性和故障恢复设计

在高并发交易系统里，我一般不会简单说系统选 CP 还是 AP，而是按业务域拆分一致性边界。

核心原则是： 涉及资金、库存、订单状态流转这类不可逆或强约束数据，优先保证一致性；涉及通知、报表、推荐、风控画像、搜索索引这类派生数据，可以接受 BASE 的最终一致性。

CAP 主要是在网络分区发生时做取舍。交易系统不可能牺牲分区容错，所以真正取舍的是一致性和可用性。

对于核心交易链路，比如下单扣库存、支付扣款、账户余额变更，我会偏向 CP 或者局部强一致。比如：

订单状态机要严格控制状态流转，不能出现已取消又支付成功这种乱序状态； 扣库存要避免超卖，可以通过数据库行锁、乐观锁、Redis 原子扣减加异步校准，或者库存中心统一扣减； 资金账户变更必须有流水，余额变更和流水写入要在本地事务内保证一致； 支付回调要做幂等，不能因为重复通知导致重复入账或重复发货。

这类场景下，如果出现分区或者依赖不可用，宁可降级、排队、拒绝部分请求，也不能返回一个看似成功但实际状态不确定的结果。比如支付系统异常时，可以让订单进入“支付处理中”，而不是直接标记支付成功。

BASE 更