Java分布式架构面试题库
生成时间：2026-05-21 22:01
【面试题】1. CAP定理中，为什么分布式系统只能三选二？在实际系统中真的只能选两个吗？
【标准答案】 CAP定理的核心逻辑是：网络分区（P）是客观存在的，不是你选不选的问题——在分布式系统中网络一定可能断，所以P是必须面对的现实。真正需要权衡的是C和A：当网络分区发生时，你要么牺牲一致性保证可用性（AP），要么牺牲可用性保证一致性（CP）。
但面试中不要止步于此——实际系统中并不是非黑即白的"三选二"。大多数系统在不同场景、不同操作上做不同选择。比如Redis Cluster默认是AP，但可以通过WAIT命令实现一定程度的CP；Zookeeper是CP，但读取可以连接Follower走弱一致性。现代分布式系统更倾向于"CAP权衡"而非"CAP取舍"，根据业务场景在同一系统内灵活组合。面试官听到这个认知层次，基本就稳了。
【面试题】2. Redis分布式锁用SET NX EX实现有什么隐患？Redisson是怎么解决的？
【标准答案】 SET NX EX的核心隐患有三个：第一，锁超时释放问题——业务没执行完锁就过期了，别的线程拿到锁导致并发冲突；第二，误删别人的锁——线程A的锁超时释放后，线程B加锁，线程A执行完直接DEL把B的锁删了；第三，不可重入——同一线程无法对同一把锁重复加锁。
Redisson的解决方案：针对锁超时，引入了看门狗（Watchdog）机制，默认锁30秒，后台线程每10秒续期一次，业务没完成就一直续，避免锁提前过期；针对误删，每个锁的value是UUID+线程ID，释放时用Lua脚本先比较value再删除，保证只删自己的锁；针对不可重入，用Redis Hash结构记录重入次数，加锁时计数+1，释放时-1，到0才真正删除。这三个点答出来，Redisson的锁就讲透了。
【面试题】3. TCC模式和Saga模式的核心区别是什么？分别适合什么场景？
【标准答案】 核心区别在于补偿的方向和粒度。TCC是"预留-确认-取消"三步走，Try阶段冻结资源而不是真正执行，Confirm才真正提交，Cancel回滚释放冻结的资源——本质是业务层面的两阶段提交，每个参与方都要实现三个接口，侵入性强但一致性保证好。Saga是正序执行+逆序补偿，每个事务真正执行，失败时通过补偿操作反向撤销——没有Try预留阶段，侵入性相对低，但只能保证最终一致性，且中间状态对外可见。
场景选择：TCC适合资金类、库存类等对一致性要求极高的核心业务——钱的事不能出岔子；Saga适合长流程编排类业务，比如订单流转涉及多个服务调用，流程长、参与方多，TCC三个接口的改造成本太高，用Saga更实际。一句话总结：TCC重一致性轻灵活，Saga重灵活轻一致性。
【面试题】4. Snowflake雪花算法的时钟回拨问题怎么解决？生产环境有哪些改进方案？
【标准答案】 Snowflake的核心结构是：1位符号位+41位时间戳+10位机器ID+12位序列号，单机每毫秒最多4096个ID。它依赖系统时钟单调递增，时钟回拨会导致生成重复ID，这是最大的坑。
生产环境的改进方案：第一，轻度回拨（几毫秒）直接等待追上——检测到回拨就sleep等时钟追回来，简单粗暴但有效；第二，Leaf-segment方案（美团）——放弃纯时钟驱动，用号段模式从数据库预取ID段，本地发号，完全不依赖时钟，但ID不严格递增；第三，UidGenerator的RingBuffer方案——预生成一批ID放环形缓冲区，消费端直接取，时钟回拨不影响已生成的ID；第四，百度UidGenerator默认使用宽松模式，允许一定程度的时钟回拨。实际选型建议：对ID严格递增没要求的用Leaf号段，有要求的用Snowflake+回拨检测，资金级严格场景用数据库号段。
【面试题】5. 缓存穿透、击穿、雪崩分别是什么？你的项目中怎么解决的？
【标准答案】 三者本质都是缓存失效导致请求打到DB，但触发条件不同。穿透是查询根本不存在的数据，缓存没有DB也没有，每次请求都穿透到DB；击穿是某个热点key突然过期，瞬间大量并发请求打到DB；雪崩是大量key同时过期，DB瞬间承受海量请求。
解决方案：穿透——布隆过滤器拦截不存在的key + 空值缓存（设短TTL）；击穿——互斥锁更新（只让一个线程回源DB，其他等）或热点key永不过期（逻辑过期，后台异步刷新）；雪崩——TTL加随机偏移量避免同时过期 + 多级缓存兜底 + 溶断降级。面试中加分点：说清三者的区别而不是混为一谈，然后结合项目举例——比如电商商品详情页的SKU信息用逻辑过期+异步刷新防击穿，用户搜索词用布隆过滤器防穿透。
【面试题】6. Raft算法的Leader选举过程是怎样的？如果出现网络分区会怎样？
【标准答案】 Raft的节点有三种状态：Follower、Candidate、Leader。正常情况下只有一个Leader。选举过程：Follower在选举超时（150~300ms随机）内没收到Leader心跳，就转为Candidate，自增term，给自己投票，然后向其他节点发RequestVote RPC。收到多数票就升级为Leader，立刻发心跳确立权威。随机选举超时是为了避免多个Follower同时竞选导致选票分散。
网络分区场景：如果分区导致少数派和多数派，少数派的Leader无法提交日志（拿不到多数确认），term会逐渐落后；多数派选出新Leader正常工作。分区恢复后，旧Leader发现自己的term落后，自动降级为Follower，日志被新Leader的日志覆盖。这就是Raft的"term机制+多数派"保证的安全性。面试官追问的点：为什么选举超时要随机？——避免活锁，Split Vote后快速重选。
【面试题】7. Sentinel和Hystrix在限流熔断机制上的核心差异是什么？
【标准答案】 三个核心差异：第一，熔断器状态模型不同——Hystrix是闭→开→半开三状态，半开时放一个请求探测；Sentinel也是三状态，但半开时可以按比例放行（比如放行10%的请求），探测更精细，恢复更平滑。第二，限流算法不同——Hystrix用信号量或线程池隔离，本质是并发数控制；Sentinel支持QPS限流，内置滑动窗口、令牌桶、漏桶等多种算法，还能基于调用链路做热点参数限流。第三，扩展性——Hystrix已停止维护，Sentinel还在活跃迭代，支持Dubbo/Spring Cloud/GRPC等多框架，有控制台实时监控和动态规则推送。
实际选型：新项目直接Sentinel，老项目如果已经在用Hystrix且稳定运行可以不动。面试中要强调的一点：熔断不是目的，降级才是——触发熔断后必须有兜底逻辑（fallback），返回缓存数据或默认值，而不是直接报错。
【面试题】8. 分布式链路追踪中，TraceId和SpanId是怎么传递的？异步调用场景有什么坑？
【标准答案】 同步调用中，TraceId和SpanId通过请求头传递——Spring Cloud Sleuth默认用X-B3-TraceId、X-B3-SpanId等Header，入口网关生成Root Span和TraceId，每层调用创建Child Span，通过HTTP Header往下游传。跨线程时用InheritableThreadLocal或手动包装Runnable把上下文传过去。
异步调用的坑：线程池场景下，InheritableThreadLocal只能传给子线程创建时的快照，线程池复用时上下文会串——线程A提交任务时绑定了TraceId，线程执行时可能还是上一次任务的上下文。解决方案：用TransmittableThreadLocal（阿里TTL）自动跨线程池传递；或者手动包装Runnable/Callable，在submit时捕获当前上下文，run时还原。消息队列场景更麻烦——生产者要在消息体里塞TraceId，消费者取出后恢复上下文，中间件要支持才行（比如RocketMQ内置支持）。
【面试题】9. Nacos和Apollo作为配置中心，在架构设计和使用场景上有什么核心区别？
【标准答案】 架构差异：Nacos是Config + Registration二合一，配置中心和服务发现一体化，数据存储默认内嵌Derby也支持MySQL，配置推送基于长轮询（客户端发起长连接，服务端hold住直到有变更或超时）；Apollo是纯配置中心，只做配置管理，存储依赖MySQL，配置推送基于长连接（客户端和服务端维持长连接，变更时服务端主动推）。
使用场景区别：如果你用Spring Cloud Alibaba全家桶，Nacos一站式解决注册中心+配置中心，运维成本低；如果你要精细化的配置管理——比如灰度发布配置（按IP/集群/namespace逐步推送）、配置审计和回滚、多环境隔离——Apollo的权限模型和发布流程更成熟，大厂用得更多。一句话：小团队图省事选Nacos，大团队要管控选Apollo。还有一个点：Nacos的配置历史只保留30天，Apollo支持配置全量历史和一键回滚，这对生产环境很关键。
【面试题】10. 微服务架构中，API网关应该承担哪些职责？哪些不应该放在网关？
【标准答案】 网关应该承担的职责：路由转发（核心能力）、认证鉴权（JWT校验/OAuth2.0）、限流熔断（入口处统一管控）、请求日志和链路追踪（注入TraceId）、协议转换（HTTP→GRPC）、灰度路由（按权重/Header分流）、跨域处理、请求聚合（BFF模式合并多个后端接口）。
不应该放在网关的：业务逻辑处理——网关是基础设施不是业务层，不要把订单计算、数据组装塞进去；数据持久化——网关不连数据库；重量级数据转换——大文件上传下载不要走网关，直接穿透；长时间阻塞操作——网关要求快进快出，耗时操作会拖垮整个入口。面试中要强调的核心原则：网关是"门卫"不是"管家"，它做准入控制不做业务处理。职责越清晰，网关越稳定；逻辑越重，网关越容易成为瓶颈和单点故障。