2025年java分布式面试题库及答案.docxVIP

2025年java分布式面试题库及答案

Q1：请解释CAP理论的核心含义，并说明在实际分布式系统中如何权衡这三个特性？

CAP理论指出，一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（PartitionTolerance）中的两个。其中：

一致性：所有节点在同一时间看到的相同数据副本；

可用性：每次请求都能收到非错误的响应，但不保证是最新数据；

分区容错性：系统在网络分区（节点间通信中断）时仍能继续运行。

实际系统中，分区容错性是分布式系统的基本要求（网络不可靠），因此通常需要在C和A之间权衡。例如，ZooKeeper选择CP，当发生分区时，为保证一致性会牺牲部分可用性（主节点不可用时停止服务）；而Eureka选择AP，允许节点返回旧数据以保证服务可用，通过心跳机制最终同步数据。

Q2：分布式事务的常见解决方案有哪些？各自的适用场景和优缺点是什么？

常见方案包括：

1.两阶段提交（2PC）：协调者先询问各参与者是否准备好提交，所有参与者确认后再统一提交。优点是强一致性；缺点是阻塞（参与者需锁定资源直到提交完成）、协调者单点故障、网络延迟敏感，适用于低并发、短事务场景（如传统金融系统）。

2.三阶段提交（3PC）：增加“预提交”阶段，降低阻塞时间，但未完全解决单点问题，实际应用较少。

3.TCC（Try-Confirm-Cancel）：业务层定义三个操作：Try（预留资源）、Confirm（确认提交）、Cancel（回滚）。优点是无资源阻塞，适合长事务；缺点是需业务代码实现回滚逻辑，复杂度高，适用于电商订单、支付等业务流程明确的场景。

4.本地消息表：将事务操作记录到本地消息表，通过定时任务发送消息给其他服务，其他服务消费消息后更新状态。优点是解耦，依赖数据库事务；缺点是消息延迟，需处理重复消费，适合异步场景（如订单通知库存）。

5.事务补偿（Saga）：通过反向操作补偿已提交的事务。优点是无中心节点；缺点是补偿逻辑需幂等，可能产生中间不一致状态，适用于流程可分解的长事务。

Q3：如何用Redis实现分布式锁？需要注意哪些问题？

Redis实现分布式锁的核心是通过`SETkeyvalueNXPXtimeout`命令原子性地设置锁（NX保证只有一个客户端能设置成功，PX设置过期时间防死锁）。释放锁时需检查锁是否属于当前客户端（避免误删其他客户端的锁），通常用Lua脚本保证原子性：

```lua

ifredis.call(get,KEYS[1])==ARGV[1]then

returnredis.call(del,KEYS[1])

else

return0

end

```

需注意的问题：

锁过期时间：需合理设置，若业务执行时间超过过期时间，可能导致多个客户端同时持有锁。可通过“锁续约”机制（后台线程定时延长锁过期时间）解决。

集群环境下的RedLock：单实例Redis的锁在主从切换时可能丢失，RedLock通过多数节点（如5个节点选3个）获取锁，提高可靠性，但增加了复杂度，需权衡性能。

可重入性：普通Redis锁不支持，需通过记录客户端ID和重入次数（如使用Hash结构存储`lock_key:client_id`的计数）实现。

Q4：分布式Session的常见解决方案有哪些？各自的优缺点是什么？

1.Session复制（Tomcat的DeltaManager）：节点间同步Session数据。优点是无需修改代码；缺点是网络开销大（节点数越多，同步延迟越高），适用于小规模集群。

2.Session共享（Redis/Memcached）：将Session存储在集中式缓存中。优点是扩展性好，支持水平扩容；缺点是依赖缓存可用性（需考虑缓存击穿、持久化），适用于大多数分布式系统。

3.Cookie存储：将Session数据加密后存储在Cookie中。优点是无服务器存储压力；缺点是Cookie大小限制（通常4KB），安全性风险（需HTTPS+强加密），适用于轻量Session（如用户ID）。

4.客户端绑定（IP哈希）：通过负载均衡器将同一IP的请求路由到固定节点。优点是无需额外存储；缺点是节点故障时Session丢失（需结合Session持久化），适用于无状态或短会话场景。

Q5：如何设计一个高并发系统的限流策略？常见的限流算法有哪些？

限流的核心是控制单位时间内的请求量，防止系统过载。设计时需考虑：

限流维度：IP、用户ID、接口、服务等；

限流阈值：根据系统容量（如QPS、CPU/内存使用率）动态调整；

降级策略：限流后返回友好提示或降级