4. 分布式系统设计题
本章聚焦面试中最高频的三大分布式系统设计主题：分布式锁、一致性协议（Paxos / Raft）和 CAP 理论。面试官通常要求你在实际场景中权衡取舍，并设计可落地的方案。以下结构化框架将帮助你从“背概念”升级到“讲设计”。
面试黄金原则：先确认场景 → 再选方案 → 主动权衡CAP → 最后兜底异常。不急于背出所有实现细节，而是展示你的“设计决策能力”。
① 面试问题：如何设计一个高可用的分布式锁？
| 考察点 | • 框架选择（Redis / ZK / etcd）• 锁超时与续期 • 死锁防范 • 性能与正确性平衡 |
| 回答框架 | 1. 明确场景（如秒杀 / 分布式调度）→ 2. 对比选型（Redis RedLock vs ZK 临时顺序节点）→ 3. 锁过期续期（watch dog）→ 4. 异常处理（网络分区、GC 停顿）→ 5. 降级方案（本地锁 + 乐观锁） |
| 简短示例回答 | “我会首选 Redis 实现，因为性能好。用 SET NX + 值包含请求 ID 作为锁标识，设置合理过期时间；再启动一个后台定时线程（watch dog）每 2/3 过期时间续期一次。如果客户端宕机，锁过期自动释放；遇到网络分区则结合 RedLock 算法提升容错。” （约95字） |
| 可能追问 | • RedLock 是否真安全？• 时钟漂移如何影响？• 如何避免锁被其他线程误删？ |
| 避坑提醒 | ❌ 不要只背 Redis SET NX 命令；❌ 避免忽略客户端 GC 停顿导致锁过期；✅ 主动讨论“使用 Lua 脚本保证原子性”是加分点。 |
② 面试问题：Paxos / Raft 的核心区别以及在分布式锁中可以怎么用？
| 考察点 | • 算法理解深度 • 工程落地思考 • 选型判断力（Paxos vs Raft）• 与锁场景的结合 |
| 回答框架 | 1. 简述两者目标（强一致性）→ 2. 对比核心差异（Leader 选举机制、日志复制过程、可理解性）→ 3. 如何用于锁（基于 Raft 的 etcd 租约锁）→ 4. 性能 vs 一致性权衡 → 5. 实际案例（etcd Watch / Lease） |
| 简短示例回答 | “Paxos 和 Raft 都保证强一致性，但 Raft 通过强 Leader 和日志预写简化了实现。在分布式锁中，我倾向于用 etcd 的 Raft 协议，因为租约机制天然支持锁续期，且 Watch 能监听锁释放，避免轮询。相比 Paxos，Raft 更容易排查脑裂问题。” （约95字） |
| 可能追问 | • Raft 中 Leader 宕机后锁状态如何恢复？• 如何用 Raft 实现排他锁？• 仲裁失败怎么办？ |
| 避坑提醒 | ❌ 不要只背算法名词；❌ 避免说“Paxos 更难、Raft 更好”；✅ 强调“Raft 更易工程化，但 Paxos 在无 Leader 场景仍有优势”。 |
③ 面试问题：CAP 理论中，为什么通常选 AP 而不是 CP？举例说明。
| 考察点 | • CAP 本质理解 • 业务场景决策能力 • trade-off 思维 • 对“分区容忍”的实操体会 |
| 回答框架 | 1. CAP 三选二的前提（网络分区时）→ 2. 业务类型分类（金融选 CP，社交/内容选 AP）→ 3. 举例：分布式锁场景更倾向于 CP（一致性要求高）→ 4. 如何通过妥协保持可用性（如降级为本地锁）→ 5. 实际架构中的 CAP 感知 |
| 简短示例回答 | “大多数互联网业务在分区时优先保障可用性（AP），因为用户无法接受系统不可用。比如商品下订单，分区时允许稍后最终一致。但分布式锁必须选 CP，否则会造成库存超卖。所以锁场景我使用 etcd（CP），而普通缓存用 Redis（AP）。” （约98字） |
| 可能追问 | • 网络分区恢复后如何解决数据冲突？• 哪些场景可以接受最终一致性？• 如何量化一致性损失？ |
| 避坑提醒 | ❌ 不要死记“三选二”；❌ 避免忽略分区是前提；✅ 主动指出“CAP 只在 P 发生时成立，正常时 CA 可兼得”是高级认知。 |
📌 面试速查：三大主题选型矩阵
| 场景 | 推荐方案 | CAP 偏重 | 关键风险 |
|---|
| 高并发秒杀锁 | Redis RedLock + watch dog | AP（可容忍少量锁冲突） | 时钟漂移、主从异步 |
| 金融事务锁 | etcd / ZK（Raft / Zab） | CP | Leader 故障恢复时间 |
| 配置管理/服务发现 | etcd（强一致 Watch） | CP | 写放大、心跳开销 |
| 分布式计数器/限流 | Redis Lua 脚本 + 本地缓存 | AP | 原子性、过期丢失 |