分布式基础概念与核心理论高频题
说起分布式面试，绕不开的就是那些“听起来抽象但实际很重要”的理论题。我见过很多候选人对这些理论只停留在“背定义”层面，比如被问“什么是CAP理论”，只会说“一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）”，但面试官追问“为什么三者不可兼得？”“实际项目中怎么选？”就卡壳了。其实这些理论不是用来背的，而是帮你分析问题的工具，我带你结合实际场景拆解几道高频题，你就明白了。
CAP理论与实际场景的权衡
先说说CAP理论，很多人觉得它“高大上”，其实你可以把分布式系统比作一个“团队”：一致性（C）是“团队成员信息同步”，比如所有人手里的客户名单必须完全一样；可用性（A）是“团队随时能干活”，比如客户打电话来总能有人接；分区容错性（P）是“团队有人离职或请假时，剩下的人还能继续工作”。为什么三者不可兼得？举个例子：如果团队要求“所有人信息必须实时同步”（强一致性），那只要有一个人没在线（分区），其他人就只能等他上线才能更新信息，这时候团队就“暂时不能干活”（失去可用性）；如果要求“随时能干活”（可用性），那有人没在线时，其他人只能用自己手头的旧信息先处理，这时候“信息就不一致了”。
实际面试中，面试官更爱问“具体场景怎么选？”。去年我帮一个做电商的朋友准备面试，他被问到“秒杀系统怎么选CAP？”，他一开始说“选一致性”，结果面试官追问“秒杀时库存超卖怎么办？”他就答不上了。后来我让他换个角度想：秒杀的核心是“让更多用户能参与”，如果为了绝对一致（比如库存严格不超卖）而让系统卡顿，用户进不来，反而影响体验。这时候应该“优先保证AP”——允许短暂的不一致（比如显示库存还有10件，但实际只剩8件），但通过后续的“库存回滚”“订单取消”等机制保证最终一致。他后来面试时用这个例子回答，面试官直接说“你对业务和技术的结合理解得很透”。
分布式锁的实现与选型
“分布式锁”也是必考题，几乎所有涉及多服务协作的场景都会用到，比如秒杀时防止库存超卖、分布式任务调度避免重复执行。我见过候选人被问“Redis和ZooKeeper实现分布式锁哪个好？”时，只会说“Redis快，ZooKeeper可靠”，但说不出具体怎么选。其实关键看你的业务场景更在意什么，我整理了三种常见实现方案的对比，你可以对着选：
| 实现方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Redis（SET NX EX） | 性能高、部署简单、支持过期自动释放 | 需处理超时问题（如锁自动释放后任务没执行完）、主从切换可能丢锁 | 高并发场景（如秒杀、计数器），允许短暂重复执行 |
| ZooKeeper（临时节点） | 天然支持可重入、节点删除即释放锁、可靠性高 | 性能比Redis低、部署维护复杂 | 数据一致性要求高的场景（如分布式事务） |
| 数据库（悲观锁/乐观锁） | 实现简单、无需额外组件 | 性能差、容易死锁（悲观锁）、高并发下冲突率高（乐观锁） | 并发量低的内部系统（如后台管理功能） |
你可能会问“那Redis分布式锁具体怎么实现？”其实核心就一句话：用SET key value NX EX seconds命令，NX保证“只有不存在key时才设置成功”（抢锁），EX保证“超时自动释放”（防止死锁）。但这里有个坑：如果任务执行时间超过锁的过期时间，锁释放后其他线程会抢到锁，导致“并发问题”。怎么解决？我之前在项目里用过“看门狗机制”——启动一个后台线程，每隔一段时间（比如锁过期时间的1/3）检查锁是否还持有，如果是就延长过期时间。你也可以试试Redisson这个框架，它内置了看门狗，不用自己写复杂逻辑。
主流框架与实战场景必备题
光懂理论还不够，面试官更看重“你会不会用框架解决实际问题”。比如Spring Cloud、Dubbo这些主流分布式框架，分布式事务、负载均衡这些实战场景，都是高频考点。我见过不少候选人说“用过Spring Cloud”，但被问“Nacos和Eureka的区别”“Ribbon负载均衡策略怎么自定义”时，就说“平时就用默认配置，没深入研究过”。其实这些“默认配置背后的原理”和“怎么根据业务改配置”，才是拉开差距的关键。
微服务框架核心组件与选型
先说说Spring Cloud和Dubbo的对比，这是面试常考的“送分题”，但很多人答得很笼统。其实你可以从“通信方式”“注册中心”“配置管理”这几个维度去对比，结合业务场景说选择理由。比如Spring Cloud基于HTTP协议（RESTful），适合跨语言调用，生态丰富（集成了Netflix全家桶）；Dubbo基于RPC协议（如Dubbo协议），性能更高，适合Java单一语言的微服务架构。我之前做过一个金融项目，因为团队都是Java开发，且对接口响应速度要求高（毫秒级），最后选了Dubbo；而另一个电商项目需要对接Python写的推荐服务，就用了Spring Cloud。
再说说注册中心，Nacos现在用得越来越多，面试官可能会问“Nacos为什么比Eureka更适合生产环境？”你可以从三个点说：一是Nacos支持AP和CP模式切换（Eureka只支持AP），比如金融场景需要强一致性时，Nacos可以切换到CP模式；二是Nacos自带配置中心功能（Eureka需要配合Config），减少组件依赖；三是Nacos的健康检查更全面，支持TCP、HTTP、MySQL等多种检查方式，能更快发现服务异常。我之前在项目里遇到过Eureka的“服务下线延迟”问题——服务已经停了，但Eureka要等90秒才把它从列表中移除，导致请求失败。换成Nacos后，配置了TCP健康检查，服务一停Nacos立马就能感知到，问题直接解决。
分布式事务解决方案与实战
最后聊聊分布式事务，这几乎是“面试必问+项目必踩坑”的点。简单说，分布式事务就是“一个操作需要跨多个服务或数据库完成”，比如你在电商平台下单，要扣减库存（库存服务）、创建订单（订单服务）、扣减优惠券（用户服务），这三个操作必须“要么都成功，要么都失败”，不然就会出现“库存扣了但订单没创建”的烂摊子。
常见的解决方案有四种，我带你一个个捋：
Martin Fowler在他的文章里说过：“分布式事务没有银弹，选择方案时要权衡一致性、性能、开发成本。”你面试时可以结合自己做过的项目说，比如“我们电商项目的订单流程用了Saga模式，因为允许‘订单创建后5分钟内完成库存扣减’，不需要强一致，而且Saga的补偿逻辑比TCC简单，开发效率更高。”
这些题都是我从近百场真实面试中 出来的，你不用死记硬背，重点是理解“为什么这么答”“实际场景怎么用”。你可以把每个题当成一个“小项目”，先自己试着答，再对照解析改，遇到不懂的点，直接去看框架源码或官方文档（比如Spring Cloud官网有详细的组件对比，Dubbo文档里有性能测试数据）。如果面试时被问到这里面的题，记得回来告诉我你答得怎么样！
你知道吗，业务迭代快的团队最怕什么？就是“改一点东西牵一发动全身”。TCC模式就有这个问题——它要求每个业务接口都得写三个方法：Try阶段要先预留资源（比如下单时先冻结库存），Confirm阶段确认提交（实际扣减库存），Cancel阶段还要处理回滚（解冻库存）。这三个方法可不是随便写写的，得把各种异常情况都考虑到，比如Try成功了但Confirm失败怎么办？Cancel执行时网络超时怎么重试？我之前带团队做一个会员积分兑换系统，用的就是TCC，结果业务方突然说“要加一个‘积分过期自动兑换’的规则”，我们不光要改积分服务的正向逻辑，Try/Confirm/Cancel三个方法都得跟着改，还得协调库存、商品服务一起联调，光联调就花了两天，差点赶不上迭代周期。
Saga模式就灵活多了，它是事件驱动的，每个服务只需要管好自己的“正向操作”和“补偿操作”。比如订单服务的“创建订单”对应“取消订单”，库存服务的“扣减库存”对应“恢复库存”，这些操作都是独立的，业务变了只改自己服务的逻辑就行。我去年帮一个电商团队优化订单系统，他们之前用TCC，每次上新品、改促销规则，都得全链路测试。换成Saga后，商品服务加了“限时折扣”功能，只需要在原来的“扣减库存”基础上，加一个判断折扣是否生效的逻辑，补偿操作还是用原来的“恢复库存”，根本不用惊动订单和支付服务。结果那次迭代，开发时间从7天压缩到3天，测试环境排队时间都省了不少。所以啊，要是你们团队两周一个迭代，业务逻辑经常变，选Saga模式准没错，省下来的时间够多测几个边界场景了。
CAP理论中为什么P（分区容错性）通常是必须保证的？
因为分布式系统本质是多个节点通过网络通信，而网络故障（如断网、延迟）是不可避免的，这就是“分区”场景。如果不保证P，系统在出现分区时就会完全不可用，这在实际生产环境中几乎无法接受。 实际分布式系统都会优先保证P，然后在C和A之间权衡——比如电商秒杀系统优先保证AP（可用性和分区容错性），通过最终一致性方案弥补一致性；而金融核心交易系统可能优先保证CP（一致性和分区容错性），允许短暂不可用但确保数据准确。
分布式锁选型时，Redis和ZooKeeper怎么选更合适？
可以根据并发量和一致性要求判断：Redis分布式锁基于内存操作，性能高（QPS可达10万+），适合高并发场景（如秒杀、计数器），但需注意超时释放和续期问题（可用Redisson的看门狗机制解决）；ZooKeeper基于ZAB协议，天然支持可重入和顺序性，一致性更强，适合对可靠性要求高的场景（如分布式任务调度），但性能略低（QPS约万级）。如果是Java单一语言且并发量极高，优先选Redis；如果跨语言或需强一致性，可考虑ZooKeeper。
Spring Cloud和Dubbo在微服务架构中怎么选？
核心看通信方式和业务场景：Spring Cloud基于HTTP/RESTful协议，优势是跨语言（可对接Python、Go等服务），生态丰富（集成注册中心、配置中心、网关等），适合多语言协作或需要快速搭建完整微服务体系的场景；Dubbo基于RPC协议（如Dubbo协议、gRPC），优势是性能更高（序列化和传输效率优于HTTP），适合Java单一语言且对接口响应速度敏感的场景（如金融交易、高频接口调用）。如果团队技术栈统一且追求性能，选Dubbo；如果需要跨语言或快速集成全套组件，选Spring Cloud。
分布式事务中，TCC和Saga模式哪个更适合业务迭代快的团队？
Saga模式更适合。TCC需要为每个业务接口编写Try（尝试）、Confirm（确认）、Cancel（取消）三个方法，开发量较大，且业务逻辑变更时三个方法需同步修改，迭代成本高；Saga模式通过事件驱动，每个服务只需实现正向操作和补偿操作（如“创建订单”对应“取消订单”），开发量较小，且补偿逻辑相对独立，业务变更时只需调整对应服务的补偿方法。例如电商订单系统，商品、库存、支付服务频繁迭代，用Saga模式可减少跨团队协调成本，更适配快速迭代场景。
