CAP 理论面试题（对话式 + 脑图）

学习目标

学完本文，你应该能够：

1. 说清三者的边界与递进关系：CAP 讲"分区时怎么选"，PACELC 补上"正常运行时延迟与一致性的权衡"，BASE 是 AP 系统的工程落地。
2. 建立分布式系统的知识体系：从存储、计算、通信、调度四个角度拆解任意一个分布式问题。
3. 用一句话解释 CAP 三要素，并说明为什么在真实分布式系统里 P 必须保留。
4. 结合一次读写流程讲清 CAP 的原理，并随手举出 CP / AP 的代表系统与适用场景。
5. 用 Redis 分布式锁这个真实案例，指出"AP 架构用在 CP 场景"的选型错误，并给出改进思路。

前置知识：基本网络概念（请求、延迟、故障）；至少用过一种 NoSQL 或注册中心（Redis / etcd / ZooKeeper 任一即可）；知道主从复制、哨兵机制的大致含义。

本章你会动手做的事：

• 画一张"CAP → PACELC → BASE"的递进关系脑图（见下方）。
• 拿简历里的一个分布式组件，判断它偏 CP 还是 AP，并解释原因。
• 用 etcd / ZooKeeper 写一个最小分布式锁，跑通"主节点宕机不出现双锁"的测试。

一、考点脑图

先给整篇文章一张总览图。三个理论从"理论边界"到"常态权衡"再到"工程实践"层层递进，篇末的实战案例会把它们全部串起来。

二、先有地图：分布式系统的知识体系

在背 CAP 之前，先建立一张"地图"。面试里最怕的就是背完理论却落不到具体系统上——而建立知识体系，正是把理论和工程连起来的那根线。

从这个类比出发，分布式系统的知识体系可以从四个角度概括，拿到任何一个分布式问题，先看它落在哪个角度，再往下深挖：

记住这个框架，后面讲 Redis 分布式锁时，你会看到它正好落在"存储器"这一支，而它的数据复制、一致性做法，正是 CAP 理论要回答的问题。

三、CAP 理论：分区发生时 C 与 A 的取舍

CAP 是分布式系统里最经典的理论，面试几乎必问。下面用对话把它的定义、原理和局限一次讲透。

四、PACELC 定理：补上"正常运行时"的权衡

既然 CAP 有局限，自然会问：没有网络分区的时候，系统又该怎么权衡？这就是 PACELC 要补上的那一块。

五、BASE 理论：AP 系统的工程实践

CAP / PACELC 是"理论边界"，BASE 则是当你的系统选了 AP 之后，在工程上到底怎么落地。它不追求强一致，而是接受"最终一致"。

六、实战推演：用 Redis 分布式锁串起整套理论

前面都是"讲理论"，这一节用一个真实案例把知识体系和 CAP 全部串起来。这也是面试官最喜欢追问的"你真懂还是背的"分水岭。

6.1 现象：一个会"双锁"的 Redis 锁

最常见的 Redis 分布式锁实现，是用 setNX 加一个超时时间来控制锁的自动失效：

// 步骤 1：用 setNX 抢锁，并带上过期时间（原子操作，避免死锁）
ok, err := rdb.SetNX(ctx, "order_lock", clientID, 30*time.Second).Result()
if err != nil || !ok {
    // 没抢到锁，直接返回"请稍后重试"
    return errors.New("acquire lock failed")
}
// 步骤 2：执行业务（扣库存 / 记账）……
// 步骤 3：释放锁（用 Lua 保证只删自己的锁）

逻辑上没问题，但极端情况下会出事：当 Redis 主节点挂掉，而锁还没同步到从节点时，根据哨兵机制，从节点被提升为新主，继续对外服务。此时另一个线程再来请求锁，新主上并没有这把锁的记录，于是它也能抢到锁——结果就是两个线程同时拿到了锁。

6.2 回归理论：这是一次"选型错误"

6.3 升华：从单点到知识体系

把视野再放大一层：Redis 属于分布式存储系统，也就是我们在第二章画的"存储器"这一支。真正的高手拿到这种问题，脑子里会有完整的分布式存储知识体系——它会去追问：

• 数据存储怎么组织的？
• 数据分布（分片）怎么做？
• 数据复制（主从 / 多副本）怎么做？
• 数据一致性靠什么保证？用了哪些技术、为什么这么选？

学会从多维度、多角度对比分析同一分布式问题的不同方法，综合权衡优缺点，你才能形成自己的知识体系和技术判断力——这也是高级研发工程师和初级的差别。

七、自测题与动手练习

下面几道是进阶自测，专门覆盖本文新增的"知识体系"和"Redis 实战"两条线，用来检验你是否真懂，而不只是会背。

动手练习（建议真做一遍）：

1. 画出"CAP → PACELC → BASE"的递进关系图，用自己话写一段 100 字内的说明。
2. 拿你简历里的一个分布式组件（如 Redis / MySQL / Kafka），判断它偏 CP 还是 AP，并解释为什么。
3. 用 etcd 或 ZooKeeper 实现一个最小分布式锁（基于租约 / compare-and-swap），跑通"主节点宕机不出现双锁"的测试。

八、本章小结