第2章 高频面试问题与回答框架（通用）
本章聚焦 Python 分布式系统面试中最常出现的通用型问题，帮你建立“识别考察点→结构化回答→结合公司侧重点”的闭环能力。先通过下图掌握核心回答路径：
高频面试问题分类与回答框架速查表
| 问题类型 | 典型问题 | 推荐框架 | 公司侧重点 |
|---|---|---|---|
| 技术理解 | CAP 定理怎么理解？ | PREP | 大厂偏理论深度，中小厂偏落地场景 |
| 项目经历 | 讲一个你解决过的分布式难题 | STAR | 关注量化指标、故障复现与修复过程 |
| 系统设计 | 设计一个分布式任务调度系统 | 面试官引导+层层递进 | 大厂看扩展性设计，小厂看快速可用方案 |
面试问答卡片
面试问题：“请解释一下 CAP 定理，并说说在分布式系统中你是怎么权衡的？”
面试官考察点：基础理论掌握程度；是否能将理论和实际系统决策结合；对常见分布式产品（如 ZooKeeper、Cassandra）的取舍了解。
回答框架：PREP（Point→Reason→Example→Point）。先亮出 CAP 定义，再解释一致性、可用性、分区容错性的内在矛盾，然后举一个自己项目中权衡的例子，最后总结取舍原则。
简短示例回答：“CAP 定理指出分布式系统最多满足其中两项。我在设计订单系统时选择了 CP，因为一旦分区发生，宁可暂停写入也要保证数据一致。比如使用 ZooKeeper 做一致性协调，最终在 99.9% 可用性下保证了零数据错误。”
可能追问：“如果业务要求高可用，你怎么改设计？”“ZooKeeper 的 ZAB 协议如何保证一致性？”
面试问题：“请用 STAR 法则介绍一个你解决过的分布式系统故障案例。”
面试官考察点：问题分析与解决能力；系统排错经验；沟通表达能力；是否具备复盘总结习惯。
回答框架：STAR（Situation→Task→Action→Result）。 Situation 描述故障背景，Task 说明目标，Action 详细讲排查和修复步骤，Result 给出量化结果并讲事后改进。
简短示例回答：“某次线上消息队列堆积导致订单延迟，我负责排查。S：高峰期 Kafka 分区 leader 频繁切换。T：恢复消息实时性并防止复发。A：分析发现消费者线程死锁，修复后增加监控告警。R：延迟从 5 分钟降到 2 秒，后续零复发。”
可能追问：“具体怎么定位死锁的？”“如果消费者再出现同样问题，你怎么提前发现？”
面试问题：“你的项目里遇到过分布式事务问题吗？怎么解决的？”
面试官考察点：对分布式事务实现方案（TCC、Saga、2PC）的理解；在业务场景中的选型能力；对一致性要求的边界把握。
回答框架：先说明业务场景和数据一致性需求等级，再列出可选方案，最后给出选择的理由和实现要点。
简短示例回答：“在订单跨库转账场景中，我们采用了 Saga 模式。原因是业务允许最终一致性且需要高吞吐。具体用本地消息表加定时任务补偿，回滚时发送补偿事件。线上 99.9% 的事务在 5 秒内完成补偿，数据对账误差小于万分之一。”
可能追问：“Saga 的隔离性怎么保证？”“如果补偿也失败了怎么办？”