Java分布式面试题及答案.docx

Java分布式面试题及答案

1.什么是分布式系统？实际工作中你遇到过哪些分布式系统的核心挑战？

答案：简单说就是多台服务器协同完成一个任务的系统，比如电商的订单系统、支付系统分开部署，再配合缓存集群。核心挑战常见的有3个：

网络不可靠：比如服务A调用服务B时，网络突然断了，得考虑重试、超时控制；

数据一致性：比如下单时扣库存，订单服务成功但库存服务失败，就会出现超卖，这时候要靠分布式事务解决；

节点故障：比如缓存集群里某台Redis宕机，得保证服务还能正常访问，一般用集群容错（像Redis哨兵）。

2.你用过哪些RPC框架？RPC的核心组件有哪些？

答案：实际项目里用过Dubbo和SpringCloudOpenFeign。RPC就是远程过程调用，比如本地调用一个方法，实际是调用另一台服务器的方法。核心组件得有5个：

服务注册中心：存服务地址，比如Dubbo用ZooKeeper，Nacos也能当注册中心，服务启动时把自己的IP:端口注册进去，调用方从这拿地址；

序列化器：把Java对象转成二进制流（方便网络传输），反序列化再转回来，常用Protobuf、Hessian，比Java自带序列化效率高；

传输层：负责数据传输，一般用Netty（基于NIO），比BIO更适合高并发；

负载均衡：调用方拿到多个服务地址后，选一个调用，比如Dubbo的加权轮询（性能好的机器权重高）；

容错机制：比如调用某个服务失败了，是重试还是返回默认值，Dubbo里有失败重试、降级策略。

3.分布式事务怎么解决？你项目里用的哪种方案？

答案：常见方案有4种，各有适用场景，我项目里电商下单用的SeataAT模式：

2PC（两阶段提交）：比如MySQL的XA协议，第一阶段所有数据库准备提交，第二阶段统一执行。但缺点明显，只要一个节点卡了，整个事务会阻塞，适合并发低的场景；

TCC（Try-Confirm-Cancel）：分3步，Try先预留资源（比如扣库存前先冻结），Confirm确认执行，Cancel回滚。优点是性能好，缺点是要写大量业务代码（比如Cancel得恢复库存），适合复杂业务；

本地消息表：服务A执行完本地事务后，写一条消息到本地表，再异步把消息发给服务B，服务B执行完再回调确认。优点是简单，缺点是要维护消息表，适合非核心链路（比如订单完成后发通知）；

SeataAT：基于2PC优化，不用手动写回滚代码，Seata会自动生成undolog（回滚日志），如果失败就用undolog回滚。我们电商下单量中等，用这个既省心又能保证一致性。

4.分布式锁怎么实现？Redis和ZooKeeper实现的锁有什么区别？

答案：项目里主要用Redis和ZooKeeper做分布式锁，避免多台机器同时操作一个资源（比如抢单）。

Redis实现：用setnxex命令（nx是不存在才设置，ex是过期时间），比如setlock:order:123truenxex10，释放锁时用Lua脚本（先判断是不是自己的锁，再删除，避免误删）。缺点是如果锁过期了业务还没执行完，会出现并发问题，所以一般用Redisson的可重入锁（自动续期）；

ZooKeeper实现：基于临时有序节点，比如客户端创建lock:order:123-001这样的节点，只有序号最小的能拿到锁，其他节点监听前一个节点，前一个释放锁后自己再抢。优点是天然可重入、不会出现锁过期问题，缺点是ZooKeeper集群有延迟，适合一致性要求高的场景；

区别：Redis锁性能高（适合高并发），但需要处理续期、超时问题；ZooKeeper锁一致性强，但性能稍低，适合并发不高但要绝对安全的场景。

5.分布式缓存出现穿透、击穿、雪崩怎么解决？

答案：这三个问题都是缓存没命中导致大量请求打到数据库，我们项目里都遇到过，解决方案很明确：

穿透：缓存和数据库都没有这个数据（比如有人恶意查id=-1的商品），导致请求全去数据库。解决：①用布隆过滤器（把数据库里所有商品id存进去，不存在的直接返回）；②缓存空值（比如查不到的商品，缓存一个空值，设置短过期时间）；

击穿：一个热点key突然过期（比如秒杀商品的缓存），大量请求同时查这个key，全打到数据库。解决：①互斥锁（比如Redis的setnx，只有一个线程能去数据库查，查到后更新缓存）；②热点key永不过期（手动更新缓存，不设过期时间）；

雪崩：大量缓存key同时过期，或者缓存集群宕机，请求全压到数据库。解决：①过期时间加随机值（比如原本过期1小时，改成1小