4）CAP 落地实践

CAP 理论（Consistency 一致性、Availability 可用性、Partition Tolerance 分区容错性）在实际系统中的落地是一个非常考察架构功底的话题。以下是关于 CAP 落地实践 的五个面试问题设计，逐步加深难度，并配合答案说明和实践类比。

🌱 第 1 题：CAP 理论的基本理解

Q1：什么是 CAP 理论？请解释三个要素之间的关系。

📝 标准答案：

CAP 理论指出，在一个分布式系统中，最多只能同时满足以下三个性质中的两个：

• C - 一致性（Consistency）：所有节点在同一时间看到的数据是一样的。
• A - 可用性（Availability）：每次请求都能在有限时间内返回结果（不保证最新数据）。
• P - 分区容忍性（Partition Tolerance）：系统可以容忍网络分区，即部分节点之间通信失败时，系统仍能继续运行。

⚖️ 理论重点：在出现网络分区时（P 必选），系统必须在 C 和 A 中做取舍。

🌿 第 2 题：现实系统中的 CAP 取舍

Q2：在实际系统设计中，CAP 理论是如何影响架构选择的？请举例说明一个选择 CA、AP 或 CP 的真实场景。

📝 标准答案：

• CA 系统（理想状态）：仅在无网络分区的理想局域网中成立，如单机数据库（MySQL）。
• CP 系统（牺牲可用性）：如 HBase、Zookeeper。系统宁愿拒绝访问（不可用），也要保证数据一致性。
• AP 系统（牺牲一致性）：如 Couchbase、Cassandra、Eureka。系统保证服务响应，但可能返回旧数据。

🔍 示例对比：

• 购物下单系统：通常选 CP，因为订单不能重复或出错。
• 用户评论或点赞系统：选 AP，即使延迟同步也无伤大雅，保证用户流畅体验更重要。

🌳 第 3 题：类比思维解释 CAP

Q3：请用一个生活中的例子，形象地说明 CAP 的三者冲突与选择。

📝 参考类比：异地开会

假设你和两个朋友异地视频会议写合同（三人分别代表 A、B、C）：

• C（一致性）：三人合同版本必须一致。
• A（可用性）：任何人随时都能参与会议。
• P（分区容错）：网络时断时续。

⚖️ 情景冲突：

• 如果网络断了（P），你就必须在一致性（C）和可用性（A）之间做选择：
  • 选择一致性（C）：你暂停会议，等网络恢复再继续。
  • 选择可用性（A）：继续会议，但不同人记录的版本可能不一致。

✅ 现实中的系统就像这场会议——我们要根据业务需求决定优先保哪两个。

🌲 第 4 题：CAP 与实际中间件落地

Q4：请谈谈 CAP 理论在以下中间件中的体现（任选其一：Redis、Kafka、ZooKeeper、Etcd）。

📝 标准答案（以 ZooKeeper 为例）：

• ZooKeeper 是一个 CP 系统：
  • 优先保证一致性（C）和分区容忍性（P）。
  • 当网络异常或主节点宕机时，为防止脑裂或数据不一致，会牺牲可用性（A），不再对外服务。
  • 因此它常用于协调性、配置、选主、分布式锁等场景，不能用于对实时响应要求极高的业务场景。

📝 其它举例简要：

• Redis Cluster：AP 为主（尤其在异步主从模式下，可能返回旧值）。
• Kafka：CP 倾向，但可根据 ack 机制调整偏向。
• Etcd：CP 系统，和 ZooKeeper 类似。

🪵 第 5 题：你实际项目中如何处理 CAP 的抉择？

Q5：在你负责或参与的项目中，有没有遇到 CAP 抉择的情况？你是如何做取舍和架构设计的？

📝 参考答案（以秒杀系统为例）：

在我们做秒杀系统时，为了保证性能和用户体验，我们采用了AP 优先的设计思路，使用 Redis 缓存库存和用户抢购状态，确保高并发下系统的可用性。同时采用最终一致性策略，在用户下单成功后异步写入数据库，后台进行库存校验和补偿。对于关键数据（如订单生成），则使用消息队列和数据库事务做 CP 保证，防止数据丢失。

✅ 总结（落地要点）

模块	优先选择	原因
用户注册、下单	CP	数据一致最重要
浏览记录、点赞	AP	可用性更重要
选主服务	CP	保证唯一选举
高并发接口	AP + 最终一致性	保证响应快速