📚 课程目录第4章高频技术问题

第4章分布式系统一致性：CAP权衡、BASE最终一致性、Raft/Paxos原理

一致性是交易系统稳定性面试的核心高地。面试官通过 CAP/BASE/Raft 考察你对理论权衡与工程落地的掌握深度。本章助你构建从“理论判断”到“实战案例”的完整回答链。

面试得分点：先快速定性（选CP还是AP），再展开具体算法细节，最后落到交易场景中的折中手段和工程优化。避免只背理论不谈业务。

考察点	是否理解CAP的严格选择特性，能否结合交易业务做出合理决策。
回答框架	① 简述CAP定义（一致性、可用性、分区容忍性只能三选二）；② 指出交易场景分区不可避免，故在C和A间权衡；③ 说明关键支付/订单数据通常选CP（强一致），非关键状态可选AP并最终一致；④ 举例：分布式事务+心跳保活。
示例回答	“CAP定理告诉我们网络分区时必须在C和A之间选择。交易系统通常优先保证一致性（CP），例如使用Paxos同步订单状态避免资金错账；但查询类服务可牺牲强一致换可用，通过最终一致性补偿。我们曾用Raft实现配置同步，选主保障写入一致。” (85字)
可能追问	① 如果网络分区恢复后怎么处理？② 你用过哪些具体的一致性协议？③ 如何判断当前场景该选CP还是AP？
避坑提醒	不要回答“CAP是完美的三选二”，要强调分区发生时必须取舍；另外避免把“可用性”等价于“响应快”，可用性指非故障节点正常响应请求。

考察点	对最终一致性设计模式的理解，以及实际落地方案（幂等、补偿、异步消息）。
回答框架	① 解释BASE（基本可用、软状态、最终一致）；② 指出这是对CAP中AP场景的实践指导；③ 列举实现手段：异步消息队列+重试、本地消息表（可靠事件日志）、Saga事务/TCC补偿；④ 强调幂等性是最终一致的基础。
示例回答	“BASE主张系统基本可用，数据副本经过一段软状态最终一致。我在订单履约项目里用本地消息表保证创建订单与扣库存最终一致：业务写入本地DB后发消息给MQ，下游消费重试（幂等），若失败则回滚补偿。核心是保证消息可靠投递与幂等消费。” (90字)
可能追问	① 本地消息表如何保证不丢消息？② 补偿事务和回滚的区别？③ 如果下游一直失败怎么处理？
避坑提醒	不要只说概念不提具体方案；记得强调“幂等”这个关键前提，否则面试官会质疑你的落地经验。

考察点	对主流共识算法的理解深度，能否对比出Paxos的复杂性与Raft的可理解性。
回答框架	① Raft核心：Leader选举 → 日志复制 → 安全性；② 对比Paxos：Raft引入强Leader + 限制日志只能从Leader到Follower单向复制，简化了理解；③ 优点：易实现、集群变更方便；缺点：性能略低于多Paxos（单Leader瓶颈）；④ 实际选择：中小规模用Raft，大规模多Paxos（如ZooKeeper的Zab是类Paxos）。
示例回答	“Raft通过强Leader和任期选举简化共识：Leader接收请求并广播日志，多数派写入后提交。相比Paxos，Raft更易理解和工程实现，但单Leader可能成为瓶颈。我们交易系统配置管理用Raft（如Etcd），状态一致且运维简单。Paxos适用于更复杂的多副本场景如Chubby。” (95字)
可能追问	① Raft选举时如果两个Follower同时超时发起投票怎么办？② 日志压缩与快照机制？③ 如何保证日志复制是幂等的？
避坑提醒	避免只背书式描述流程，要体现你对“为什么Raft更容易”的理解；同时不要贬低Paxos，说它“太复杂没人用”，应客观指出其学术价值和应用场景。

项目模板优势：该案例涵盖CAP权衡、Raft配置、最终一致补偿三大考点，可迁移至各种交易场景（支付、清结算、股票交易等）。

维度	内容
项目名称	分布式交易订单一致性保障系统
业务背景	交易系统日均千万级订单，要求资金与订单状态严格一致，同时需要高可用（不允许单点故障）。
规模指标	服务节点30+，日订单量1000万+，数据一致性SLA：P99差异率0.001%，可用性99.99%。
技术栈	Raft（Etcd）、Kafka消息队列、MySQL本地事务、Saga补偿框架、Redis幂等去重。
核心难点	① 多数据中心网络分区下如何保证配置一致性？② 订单状态机与库存扣减的最终一致不丢数据？③ 补偿事务的幂等设计与循环重试。
面试高频追问	① 为什么用Raft而不是Paxos？② 如果Etcd挂了怎么办？③ 补偿事务失败后策略（回滚/人工介入）？④ 如何测试一致性？
可迁移回答话术	“在XX项目中，因为交易核心链路要求强一致，所以我们选择Raft管理配置（选Etcd实现）。对于订单与库存这类非强一致场景，我们采用本地消息表+MQ，并强制所有消费端做幂等。最终用定期对账发现并修复不一致数据。这套组合可适配多数交易场景。”

避坑提醒：项目模板不要照搬，务必将“规模指标”改成你真实项目的数据；如果没做过Raft，可以用ZooKeeper类比，但要说明你理解选主与日志复制原理；补偿事务部分一定要强调幂等设计，否则面试官会质疑方案的可靠性。

第4章 分布式系统一致性：CAP权衡、BASE最终一致性、Raft/Paxos原理