分布式系统 25 问：CAP、共识协议与分布式事务选型

分布式系统面试的考察点很明确：你能不能在「理论」与「工程妥协」之间给出有依据的选择。这份 25 问覆盖一致性理论、共识协议、分布式事务、幂等与锁四个板块，每问给出答题骨架与加分点。

一、理论基石（6 问）

1. 用一句话说清 CAP，并说明它在工程上的正确用法。

网络分区发生时，一致性与可用性只能选一个。工程正确用法：P 是必然存在的（不是选项），真正在选择的是「分区时的行为」——计费/库存选 CP（拒绝服务），社交 feed 选 AP（容忍暂时不一致）。加分点：指出同系统不同子系统可以分别取 CP/AP。

2. BASE 是什么？与 ACID 的关系？

基本可用、软状态、最终一致——AP 路线的工程化表达。不是放弃一致性，而是把「强一致」换成「可观测的收敛时间」。

3. 线性一致性与顺序一致性的区别？

线性一致：操作有全局全序且尊重实时顺序（最强，代价最高）；顺序一致：保持各客户端的操作序，但不要求实时性。Redis 主从、ETCD 的读语义差异常被拿来追问。

4. 什么是读己之写与单调读？为什么重要？

读己之写：自己写入后自己能读到（会话黏住主副本/读你刚写的节点）；单调读：不会出现「读回退」（会话内固定副本）。这是 AP 系统用户体验的底线保障。

5. Quorum 怎么推导？W+R>N 说明了什么？

N 副本、写 W 份、读 R 份，W+R>N 保证读写集合有交集，读能拿到最新写入。加分点：N=3, W=2, R=2 是常见取舍，并说明这不是完整的事务语义。

6. Raft 的核心机制三句话？

领导者选举（任期 + 多数派投票）、日志复制（Leader 追加并同步，多数派确认才提交）、安全性（日志匹配特性保证已提交日志不被覆盖）。能画图讲清「提交边界」就是满分答案。

二、分布式事务（8 问）

7. 2PC 的两个阶段与致命缺陷？

准备（锁资源并投票）+ 提交/回滚。缺陷：协调者单点（它挂了参与者锁死）、同步阻塞、网络分区下可能数据不一致。适合短事务、高可靠的内部场景。

8. 3PC 改进了什么？为什么还是不够？

加 CanCommit 阶段与超时机制，降低阻塞；但网络分区下仍可能两阶段各自推进，出现脑裂不一致——所以生产上很少用 3PC。

9. TCC 的三个阶段？空回滚与悬挂怎么处理？

Try 预留资源、Confirm 确认、Cancel 释放。空回滚：Cancel 先于 Try 到达（事务 ID 查无 Try 记录则直接返回成功并落「回滚标记」）；悬挂：Try 在 Cancel 之后到达（看到回滚标记拒绝执行）。这是 TCC 面试的必考细节。

10. SAGA 与 TCC 的取舍？

SAGA 是长事务拆成一串本地事务 + 逆序补偿，不锁资源、吞吐高，但无隔离性（中间态可见）；TCC 隔离性好但每个参与方都要写三个接口。资源紧张选 TCC，链路长、吞吐优先选 SAGA。

11. 本地消息表的原理与前提？

业务数据与消息记录在同一个本地事务落库，异步投递 + 对账重试。前提：消费方幂等。它把「分布式事务」降维成「本地事务 + 可靠投递」，是性价比最高的方案。

12. 事务消息（RocketMQ 类）与本地消息表的区别？

半消息机制由 MQ 承担重试与回查，省掉本地表，但强绑特定 MQ；本地消息表通用但多一张表与扫描任务。加分点：两者都需要「消息可查、消费幂等」。

13. 最大努力通知是什么？

适用于对时效不敏感的通知场景（支付结果通知商户）：按衰减间隔重试 N 次 + 提供查询对账接口兜底。

14. 给「下单扣库存」设计一致性方案，你怎么答？

先问约束（能不能超卖？能不能少卖？链路多长？），再选型：库存强内聚用 DB 乐观锁/原子扣减；跨服务用「本地消息表 + 补偿」；秒杀场景用「Redis 预扣 + 异步落库 + 对账」。展示「先问约束再选方案」就是加分项。

三、幂等与锁（7 问）

15. 幂等的常用实现？

唯一索引/唯一约束（最硬）、状态机（只允许合法迁移）、token 机制（先取 token 再提交）、乐观锁版本号。答出「按操作类型选择，唯一键兜底」即可。

16. 分布式锁的实现对比？

Redis（SET NX PX + 唯一值 + Lua 释放）：性能高，主从切换可能丢锁；RedLock：多数派部署，争议较大；ZooKeeper/ETCD（临时顺序节点 + watch）：强一致但吞吐低。观点题：多数业务用 Redis 锁 + 兜底对账即可，资金级用 ETCD/数据库。

17. Redis 锁为什么要带唯一值并用 Lua 释放？

防止释放别人的锁（自己的锁已过期被他人持有）。Lua 保证「判断 + 删除」原子性。加分点：续期看门狗解决「业务没执行完锁先过期」。

18. 缓存与 DB 的一致性策略？

Cache Aside（更新 DB 后删缓存）是默认答案；追问会引到「先删后更的并发窗口」「延迟双删」「订阅 binlog 异步删（Canal 类）」。能画出并发时序图是关键加分。

19. 缓存三兄弟：穿透、击穿、雪崩的定义与对策？

穿透（查不存在的 key）：空值缓存/布隆过滤器；击穿（热 key 过期）：互斥重建/逻辑过期；雪崩（大量同时过期）：过期时间加随机抖动 + 多级缓存。

20. 分布式 ID 方案对比？

UUID（无序，索引不友好）、号段模式（DB 批量取段）、雪花算法（时间戳 + 机器 ID，注意时钟回拨）。答出「趋势递增对 InnoDB 聚簇索引的意义」是加分点。

四、综合设计（5 问）

21. 分布式链路的 TraceID 怎么全链路透传？

入口生成 → Header/Context 透传 → 日志、MQ、线程池（需包装 Runnable）全带上下文。异步场景丢上下文是最常见 bug。

22. 时钟不一致会引发什么问题？怎么缓解？

事件序错乱（下单时间晚于支付时间）。缓解：NTP 消偏 + 业务上用单调递增序列号而非墙钟；跨地域一致性用混合逻辑时钟（HLC）或真时钟（TrueTime 类）。

23. 服务雪崩的传导路径与断路点？

慢调用占满线程池 → 上游超时堆积 → 级联拖垮。断路点：每层独立超时（小于下游超时）、线程池/信号量隔离、熔断降级、重试必须带退避 + 预算。

24. 最终一致的对账系统怎么设计？

定时全量对账 + 实时增量对账，差异记录进「差错池」，自动修复（可重放的操作）与人工审核（资金类）分流。对账是最终一致架构的安全网，面试提它就说明有实战视角。

25. 让你设计一个秒杀系统，答题框架？

分层削峰：前端限流与答题 → 网关令牌桶 → Redis 原子预扣（Lua）→ MQ 异步下单 → DB 兜底幂等消费。强调三个原则：库存不超卖（原子扣）、请求层层递减、失败路径体验友好（排队页/兜底页）。这问考的是分层思维，不是单点技术。