第3章：CAP与BASE理论面试题
支付系统面临着对一致性与可用性的极致要求。面试官通过CAP与BASE理论考察候选人能否在真实业务中做出合理取舍，并设计出可落地的最终一致性方案。本章聚焦三大核心问答，帮助你将抽象理论转化为面试加分项。
面试问答卡片
问题1：在分布式支付系统中，你会如何权衡C、A、P三者？
面试官考察点：是否理解不同业务的取舍逻辑，能否结合支付场景具体分析，是否具备强一致性与最终一致的落地经验。
回答框架：① 先明确业务场景对一致性的容忍度；② 强一致场景（余额、限额）选择CP方案；③ 弱一致场景（订单状态、通知）选择AP+最终一致；④ 举例说明具体技术选型（如2PC vs 异步消息）。
简短示例回答：“账户余额扣减必须强一致，我会用分布式锁+两阶段提交保证CP；订单查询允许短暂不一致，选择AP并通过消息队列最终同步。核心是根据数据一致性要求动态权衡，而非一刀切。” （88字）
可能追问：“如果选择AP，网络分区时怎么保证最终一致？” “两阶段提交的阻塞问题如何解决？”
避坑提醒：不要只背诵理论定义，必须给出具体的支付场景案例。避免声称“全选CP”——实际大促场景下可用性优先级更高。
问题2：请介绍BASE最终一致性在支付系统中的典型实现方式。
面试官考察点：是否掌握最终一致性的工程手段，能否设计可靠的消息机制和补偿策略。
回答框架：① 定义业务允许的不一致窗口；② 使用本地消息表+MQ实现异步同步；③ 生产者确保消息可靠投递，消费者保证幂等处理；④ 定时对账检测差异并触发补偿。
简短示例回答：“用户充值后先返回成功，钱包服务通过本地消息表记录事件，MQ异步更新账户余额。消息消费使用唯一流水号防重复，配合定时对账扫描未处理消息，发现不一致则发送补偿请求。” （90字）
可能追问：“消息重复如何保证幂等？” “对账发现数据不一致后，具体的补偿流程是什么？”
避坑提醒：不要只提“最终一致”概念，必须说出具体组件（本地消息表、MQ）和保障机制（重试、死信、补偿）。避免忽略生产者消息丢失风险。
问题3：如何设计支付接口的幂等性？
面试官考察点：是否理解幂等的本质，能否在重复请求、超时重试等场景下保证结果唯一。
回答框架：① 客户端生成唯一幂等键（如支付流水号）；② 服务端根据幂等键先查已处理状态，若已处理则直接返回历史结果；③ 数据库加唯一索引或分布式锁防止并发重复写入；④ 状态机控制订单状态流转，避免回退。
简短示例回答：“上游传入全局唯一ID，服务端用Redis检查是否已处理，未处理则落库并设置唯一索引。重试时根据唯一ID查询状态：已成功则返回成功，处理中则等待后返回。订单状态用枚举确保不能重复完成。” （95字）
可能追问：“如果幂等键重复但参数不同，怎么处理？” “Redis宕机后如何降级？”
避坑提醒：不要只依赖数据库唯一键防重——高并发下应先查缓存。避免忽略幂等键的生成规则（必须全局唯一且可解析）。
CAP vs BASE 核心对比
| 维度 | CAP | BASE |
|---|---|---|
| 核心思想 | 一致、可用、分区容忍三选二 | 基本可用、软状态、最终一致 |
| 设计取舍 | 强一致 vs 高可用 二选一 | 允许短暂不一致，保证最终一致 |
| 支付适用场景 | 余额、限额（CP）；订单查询（AP） | 充值异步到账、订单状态流转 |
| 实现技术 | 2PC、分布式锁、Paxos/Raft | 本地消息表、MQ、定时对账、补偿 |
| 面试高频点 | 网络分区时的策略，一致性级别区别 | 幂等性、消息可靠性、补偿方案 |