Java分布式架构面试题库
生成时间：2026-05-21 23:36
【面试题】1. Raft算法的Leader选举过程中，如果出现网络分区导致多个Candidate同时竞选，最终如何保证只有一个Leader当选？
【标准答案】Raft通过任期号（Term）和随机超时时间来解决split vote问题。每个Candidate发起选举时会自增Term，向其他节点拉票。关键机制是每个节点在同一个Term内只能投一票，先到先得。如果出现多个Candidate平票导致选举失败，各Candidate的选举超时时间是随机化的（150ms~300ms），所以总有一个Candidate先超时、先发起下一轮选举，从而打破僵局。实际工程中，这个随机超时是Raft最精妙的设计之一——面试中只要点出"随机超时打破平票"和"同Term一票制"就到位了。
【面试题】2. TCC模式中，如果Confirm阶段执行失败，应该怎么处理？和2PC的第二阶段提交失败有什么本质区别？
【标准答案】TCC的Confirm失败和2PC的第二阶段提交失败有本质区别：2PC是资源层面的协议，第二阶段失败后资源被锁定，只能不断重试直到成功，整个事务处于阻塞状态；而TCC是业务层面的协议，Confirm失败后应该记录事务日志，通过定时任务不断重试Confirm，重试成功即完成。如果重试多次仍失败，需要人工介入处理。核心区别就是——TCC没有资源锁定的问题，失败后不会阻塞其他事务，只是需要补偿。面试中强调"业务层面补偿vs资源层面锁定"这个对比，就踩到点上了。
【面试题】3. Snowflake雪花算法在时钟回拨时会出现什么问题？业界主流的解决方案有哪些？
【标准答案】时钟回拨会导致生成的ID重复或乱序，因为Snowflake依赖系统时间戳作为ID的高位部分。主流解决方案有三种：一是百度UidGenerator的方案——用环形缓冲区预生成ID，消费时不依赖实时时钟，回拨时从缓冲区取；二是美团Leaf的方案——检测到回拨后等待回拨时间过去再生成，小回拨直接wait，大回拨抛异常；三是维护一个上次时间戳，如果当前时间小于上次时间戳，说明发生了回拨，短时间（比如5ms内）就自旋等待，超时则抛异常拒绝服务。生产环境推荐Leaf-segment+snowflake双buffer方案，既解决回拨又保证高可用。
【面试题】4. 缓存穿透、缓存击穿、缓存雪崩三者有什么区别？请分别给出生产级解决方案。
【标准答案】三者区别：穿透是查根本不存在的数据，缓存和DB都没有；击穿是热点key过期瞬间大量请求打到DB；雪崩是大面积key同时过期导致DB压力暴增。穿透方案：布隆过滤器拦截+空值缓存设短TTL（5分钟），布隆过滤器前置拦截不存在的key，漏网的用空值兜底。击穿方案：互斥锁（setnx）只放一个请求回源+热点key永不过期（逻辑过期，后台异步刷新），生产环境两者结合用。雪崩方案：过期时间加随机偏移量打散+多级缓存（本地缓存Caffeine+Redis）+熔断降级，绝不让全部流量同时打到DB。面试中三个问题一起问，关键是要区分清楚场景再分别给方案。
【面试题】5. Seata的AT模式和TCC模式在实现原理和使用场景上有什么核心差异？
【标准答案】AT模式是自动补偿模式，对业务零侵入。原理是一阶段拦截SQL，解析语义生成回滚日志（undo_log）并提交本地事务，二阶段异步删除undo_log或根据undo_log反向补偿。适用于常规CRUD业务，接入成本低。TCC模式是手动补偿模式，需要业务方自己实现Try/Confirm/Cancel三个接口，一阶段Try预留资源，二阶段Confirm确认或Cancel回滚。适用于复杂业务场景，比如涉及资金扣减、库存预占等需要精细控制资源预留的场景。核心差异就两点：AT自动补偿无需改业务代码，TCC手动补偿更灵活但侵入性强；AT有一阶段本地提交+undo_log，TCC是资源预留型。面试答到"AT无侵入自动补偿vs TCC有侵入手动补偿"这个对比就稳了。
【面试题】6. Zookeeper的临时节点和持久节点有什么区别？在分布式锁实现中为什么用临时节点而不是持久节点？
【标准答案】持久节点创建后永久存在，需要主动删除；临时节点的生命周期和客户端会话绑定，会话断开（包括客户端宕机）后节点自动删除。分布式锁用临时节点的原因是防止死锁——如果持锁客户端宕机，临时节点自动删除，锁自动释放，其他客户端可以获取锁。如果用持久节点，客户端宕机后节点不会被删除，锁永远无法释放，就造成死锁。实际实现中用的是临时顺序节点，结合watch机制实现公平锁——每个客户端创建临时顺序节点，序号最小的获得锁，其他客户端watch前一个节点的删除事件。面试重点强调"防死锁"这个核心原因。
【面试题】7. Redis Cluster集群模式下，如果某个主节点宕机，集群是如何进行故障转移的？整个过程中集群是否可用？
【标准答案】Redis Cluster故障转移流程：主节点宕机后，其从节点通过Gossip协议感知主节点下线（客观下线需要半数以上主节点确认），然后从节点发起选举，获得多数主节点投票后晋升为新主节点，集群更新slot映射。关键点：故障转移期间，该主节点负责的slot请求会报错MOVED或暂时不可用，但其他slot正常服务，所以集群是部分可用。如果主节点没有从节点，则对应slot完全不可用。面试中要区分两个阶段：感知阶段（主观下线→客观下线）和选举阶段（从节点拉票→晋升），然后说清楚"部分可用"这个结论。
【面试题】8. Sentinel和Guava RateLimiter在限流实现上有什么本质区别？在微服务架构中如何选型？
【标准答案】Guava RateLimiter是单机限流，基于令牌桶算法，纯内存计算，只适合JVM内部的流量控制；Sentinel是分布式限流框架，支持集群限流模式，有限流+熔断+降级+系统保护等多维度的流量防护，还支持热点参数限流、链路限流等细粒度控制。选型原则：单体应用或只需要单机限流用Guava就够了，轻量简单；微服务架构必须上Sentinel，因为需要集群维度的统一流量控制、熔断降级、实时监控和动态规则配置。本质区别就是"单机令牌桶vs分布式多维流量防护"——面试答到这个点就够了。
【面试题】9. 在微服务架构中，如何实现配置的热更新？Nacos Config的推送机制和Apollo的推送机制有什么区别？
【标准答案】配置热更新的核心是长轮询或长连接监听配置变更。Nacos Config用的是长轮询机制——客户端发起长轮询请求，服务端持有请求29.5秒，期间如果配置变更则立即返回，否则超时返回后客户端再次发起。优点是兼容性好，不需要额外端口。Apollo也是长轮询，但架构上多了一层——配置中心通知Config Service，Config Service再通知客户端，且配置先写入数据库再推送。区别在于：Nacos更轻量，配置直接在内存中处理；Apollo更重但更安全，有完善的权限、审批、灰度发布流程。选型角度：中小项目用Nacos够用，大厂需要审批流程选Apollo。
【面试题】10. SkyWalking和Zipkin在分布式链路追踪的架构设计上有什么核心差异？如何根据业务规模选型？
【标准答案】核心架构差异：Zipkin是简单的Collector→Storage→UI三层架构，agent采集数据直接推送到Collector；SkyWalking是Agent→OAP（Observability Analysis Platform）→Storage三层，OAP是核心，做流式聚合分析。关键区别在于数据处理方式——Zipkin存储原始span数据，查询时聚合计算，数据量大时查询慢；SkyWalking在OAP层做实时流式聚合，只存储聚合后的指标数据，查询快但原始链路数据会丢失部分细节。选型：小规模（日span量亿级以下）Zipkin够用，部署简单，依赖少；大规模（亿级以上）必须SkyWalking，OAP层流式聚合解决了大数据量下的查询性能问题，而且SkyWalking的告警、拓扑图、服务指标都是开箱即用的。面试重点：Zipkin查询时聚合vs SkyWalking写入时聚合，这个设计差异决定了两者的性能天花板。
共10题，覆盖：一致性算法(Raft)、分布式事务(TCC vs 2PC)、分布式ID(雪花算法)、分布式缓存(穿透/击穿/雪崩)、分布式事务框架(Seata)、分布式协调(Zookeeper)、分布式缓存集群(Redis Cluster)、分布式限流(Sentinel vs Guava)、分布式配置中心(Nacos vs Apollo)、分布式链路追踪(SkyWalking vs Zipkin)