📐 基础理论
CAP 定理 · BASE 理论 · 一致性模型 · 幂等设计
1. CAP 定理是什么？怎么理解"三选二"？
- C（Consistency 一致性）：所有节点同一时刻看到相同的数据（线性一致性）
- A（Availability 可用性）：请求总能在合理时间内返回（不报错，即使返回旧数据）
- P（Partition tolerance 分区容错）：网络分区（节点间断连）时系统仍能工作
核心结论：分布式系统必须保证 P（网络分区不可避免），所以在 P 发生时只能在 C 和 A 之间二选一：
- CP 系统：写路径在分区时拒绝服务以保证一致（ZooKeeper、etcd、Raft 类）——宁可不可用，不可错。注意 ZooKeeper 的读可由 Follower 本地返回，可能读到旧数据（除非调 sync()）
- AP 系统：分区时继续服务但数据可能不一致（Eureka、多数缓存、DNS）——宁可有旧数据，不可挂
注意：不是"平时三选二"，而是"发生分区时选 C 还是 A"。平时可以同时满足。
🎯 面试要点
- 经典对比：ZooKeeper（CP）vs Eureka（AP）——服务注册选型问题
- 一致性细分：强一致（CP）、弱一致、最终一致（AP + 异步收敛）
- 面试常问"你系统是 CP 还是 AP"：答"核心数据 CP（订单/账户），非核心 AP（点赞数/浏览数）"最加分
2. BASE 理论？
- BA（Basically Available 基本可用）：系统可以部分功能降级（如秒杀时排队），但整体可用
- S（Soft state 软状态）：允许中间状态存在（数据同步中，各节点短暂不一致）
- E（Eventually consistent 最终一致）：经过一段时间，数据收敛到一致
BASE 是 CAP 中 AP 的实践展开：用"最终一致"换"可用性"。分布式事务的柔性方案（本地消息表、TCC、Saga）都是 BASE 思想的落地。
🎯 面试要点
- BASE 与 ACID 是对立统一：强一致场景用 ACID（单库事务），跨库降级用 BASE（最终一致）
- 提到"对账"（定时比对修复）是最终一致落地的关键手段
3. 分布式系统的幂等设计？
为什么必须幂等：网络重试（RPC 超时重发）、MQ 重复投递、用户重复提交——分布式环境下"一次请求被执行多次"是常态。
方案：
- 唯一键 + 数据库约束：幂等表（biz_id UNIQUE），重复插入失败即跳过
- Redis SETNX：请求 ID 去重（防重复提交）
- 状态机：只允许合法状态流转，重复的旧状态更新被拒
- Token 机制：页面预取 token，提交时校验消费（防表单重复提交）
🎯 面试要点
- 幂等设计三问：什么能唯一标识一次请求？（biz_id/请求号）哪里做约束？（DB/Redis）失败怎么处理？（返回已处理结果）
- GET 天然幂等、DELETE 幂等、POST 不幂等——REST 设计也遵循