分布式系统面试，别只盯着算法题

分布式系统面试，别只盯着算法题

面试官问分布式系统，很多人第一反应是背算法题，比如Paxos、Raft流程画得清清楚楚。但真正到技术面时，面试官往往不会让你默写协议，而是抛出一个业务场景，比如“用户下单后库存扣减怎么保证不超卖”，或者“服务间调用超时了怎么办”。这些才是分布式系统面试核心问题的真实面貌：它不是孤立的八股文，而是对一致性、可用性、分区容错性之间权衡的理解。

从CAP理论出发，理解取舍的底层逻辑

任何分布式系统都绕不开CAP理论。但很多候选人的理解停留在“三者只能取其二”这个口诀上。面试官真正想听的，是你能否结合具体场景解释为什么不能同时满足。比如在一个电商系统中，网络分区是不可避免的。当分区发生时，你是选择保持可用性但牺牲一致性，还是保持一致性但拒绝写入？前者如最终一致性的DNS缓存，后者如ZooKeeper的强一致性模型。面试官期待的不是背诵，而是你能否说出：在支付场景下，宁可拒绝服务也不能出现账目不一致；而在用户头像更新场景下，短暂的不一致完全可以接受。这种对业务场景的敏感度，才是分布式系统面试核心问题要考察的第一层能力。

一致性协议，不是背流程而是看设计权衡

Raft和Paxos是面试高频点，但面试官很少让你手写协议。更常见的问题是：“Raft为什么引入Leader？Paxos的Multi-Paxos和Raft有什么区别？”回答的关键在于理解Leader的作用是为了简化决策流程，减少消息交互次数。如果你能进一步指出，Raft通过强Leader和日志连续性保证了更简单的实现，但代价是Leader成为单点瓶颈，而Paxos虽然更灵活，但实现复杂且容易出错，这就说明你真的理解了设计取舍。另一个常问的点是：ZAB协议和Raft有什么异同。ZAB用于ZooKeeper，它强调崩溃恢复后的消息顺序性，而Raft更强调Leader的权威性。这些细节差异，恰恰是分布式系统面试核心问题中区分“背答案”和“真理解”的关键。

分布式事务，别只记住两阶段提交

两阶段提交是经典方案，但面试官会追问它的缺陷：协调者单点、同步阻塞、数据不一致风险。如果你能自然引出三阶段提交、TCC、Saga等方案，并说明各自适用场景，就能体现出深度。比如TCC适用于短事务、高并发场景，但需要业务方实现Try、Confirm、Cancel三个接口，对代码侵入性强；Saga则适合长事务，通过补偿机制实现最终一致性，但需要处理补偿失败的情况。面试官还会问：为什么很多互联网公司不用XA协议？因为XA是强一致性方案，在跨库跨服务场景下性能损耗大，而业务上往往能接受短暂不一致。这种对性能和业务容忍度的权衡，才是分布式系统面试核心问题中真正有价值的思考。

服务发现与负载均衡，细节决定成败

服务发现听起来简单，但面试官会问：Eureka和Consul的区别是什么？为什么Eureka强调AP，而Consul倾向CP？Eureka的设计哲学是“宁可返回一个可能不健康的节点，也不让客户端拿不到任何节点”，这适合内部服务调用，容忍短暂的不一致；Consul则通过Raft保证强一致性，适合对配置信息准确性要求高的场景。负载均衡方面，面试官会问：一致性哈希解决了什么问题？如果节点数量变化，如何减少数据迁移？如果你能说出虚拟节点、哈希环、数据倾斜等概念，并解释为什么Redis集群采用一致性哈希而Kafka采用分区分配，就能展现出对分布式系统设计细节的熟悉。这些看似零散的知识点，其实都是分布式系统面试核心问题中考察系统设计能力的缩影。

分布式缓存，穿透、击穿、雪崩的应对逻辑

缓存问题是面试中几乎必问的场景题。面试官会问：缓存穿透怎么解决？布隆过滤器的误判率如何控制？缓存击穿时，为什么互斥锁比“永不过期”方案更可靠？缓存雪崩时，为什么随机过期时间比统一过期更有效？这些问题背后考察的是对缓存与数据库一致性的理解。比如更新缓存时，先删缓存还是先更新数据库？如果先删缓存，在更新数据库的间隙，另一个请求会把旧数据加载到缓存，导致脏数据。如果先更新数据库再删缓存，又可能因为删除失败导致不一致。面试官期待的不是标准答案，而是你能分析出不同方案的优缺点，并说出在实际项目中如何通过消息队列、延迟双删等机制来兜底。这种对细节的推敲，才是分布式系统面试核心问题中真正拉开差距的地方。

消息队列，幂等性与顺序性的权衡

消息队列在分布式系统中承担解耦和削峰的作用，但面试官会问：如何保证消息不丢失？如何保证消息不重复消费？如何保证消息的顺序性？这些问题背后是对消息中间件原理的理解。比如Kafka通过ACK机制和副本同步保证不丢失，但需要权衡吞吐量；RabbitMQ通过确认机制和持久化保证可靠性，但性能相对较低。顺序性方面，Kafka只能保证分区内有序，跨分区无法保证，因此需要业务上合理设计分区键。幂等性则依赖业务层实现，比如通过去重表或版本号。面试官还会问：为什么RocketMQ支持事务消息而Kafka不支持？这涉及到对两阶段消息和本地事务表的理解。这些问题的本质，是考察你能否在消息可靠性、吞吐量、顺序性之间做出合理取舍，而这正是分布式系统面试核心问题中反复出现的主题。

面试官真正想看到的，不是你能背出多少概念，而是你能在具体场景下做出合理的权衡。分布式系统的核心在于“没有银弹”，每一个设计选择都意味着某种妥协。能清晰说出为什么在A场景选A方案、在B场景选B方案，并讲清楚背后的代价，这才是分布式系统面试核心问题想要筛选出的能力。