Java大厂面试真题：Spring Boot + Kafka + Redis 在电商场景下的高频提问与解析

最新推荐文章于 2026-08-20 15:42:09 发布

原创最新推荐文章于 2026-08-20 15:42:09 发布 · 826 阅读

11 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

Java场景面试宝典

Java大厂面试真题：Spring Boot + Kafka + Redis 在电商场景下的高频提问与解析

面试官：我们开始吧。你做过电商项目是吧？来聊聊你在里面负责的模块。

谢飞机：做过做过！我可是主力开发！我们那系统可牛了，日活百万，订单哗哗的！

面试官（微微一笑）：好，那我们从实际场景入手——假设现在要做一个限时秒杀活动，商品只有100件，但预计有10万人抢，你怎么设计这个系统？

🟢 第一轮：基础架构与流量削峰

面试官：如果所有请求直接打到数据库扣减库存，会发生什么？

谢飞机：那肯定崩啊！数据库连接池被打满，CPU飙升，响应超时，最后可能还超卖了！ 面试官：不错，知道问题所在。那你打算怎么解决？
面试官：你会用什么技术来做“流量削峰”？为什么？

谢飞机：我用……Redis！先把库存预加载进去，用原子操作DECR扣减，还能防止超卖！ 面试官：很好，Redis确实适合做高并发库存计数。那如果Redis挂了呢？
面试官：你会怎么保证Redis的数据安全和可用性？

谢飞机：呃……我配个主从？嗯……再加个哨兵？应该就稳了吧…… 面试官：基本思路对，但还不够。生产环境建议用Redis Cluster，结合持久化策略和限流降级。
面试官：用户抢到资格后，你是同步创建订单，还是异步？为什么？

谢飞机：当然是同步啊！抢到了马上给我生成订单，用户体验才好！ 面试官：错了。高并发下同步写订单会导致DB压力剧增。应该用消息队列异步处理。
面试官：你会选哪个消息队列？Kafka 还是 RabbitMQ？为什么？

谢飞机：我选……RabbitMQ！因为它界面好看，管理方便！ 面试官：……我们是电商，追求高吞吐、高可靠。Kafka 更适合日志和订单类大数据量场景。

面试官：第一轮不错，基础知识还行，但深度不够。继续。

🟡 第二轮：系统解耦与数据一致性

面试官：用户抢购成功后，订单服务要调用库存、优惠券、积分、物流等多个服务，你怎么保证最终一致性？

谢飞机：我一个一个调！先扣库存，再发优惠券，再加积分…… 面试官：这是同步串行调用，性能差，还容易卡住。有没有更好的方式？
面试官：你会不会用事件驱动架构？比如用户下单后发个事件出去？

谢飞机：事件？哦！我知道！就是……广播嘛！大家都能听！ 面试官：接近了。这就是发布/订阅模式。你可以用 Kafka 发一个 OrderCreatedEvent，其他服务订阅处理。
面试官：如果优惠券服务消费失败了怎么办？

谢飞机：那……重试呗！不行就人工补发！ 面试官：可以，但要有机制。Kafka 支持重试、死信队列，结合监控告警才是完整方案。
面试官：订单状态变更频繁，比如“已支付”、“已发货”，你怎么通知前端或用户？

谢飞机：我每隔两秒查一次数据库！ 面试官：这是轮询，效率极低。你应该用 WebSocket 或 Server-Sent Events (SSE) 主动推送。
面试官：如果要用 Spring 技术栈实现 WebSocket，你会怎么集成？

谢飞机：我……我在 controller 里写个 socket 注解？好像是 @WebSocket？ 面试官：是 @ServerEndpoint 或 Spring 的 @MessageMapping。建议结合 STOMP 协议使用。

面试官：第二轮有点吃力啊，概念模糊。最后一轮，挑战点。

🔴 第三轮：容错、监控与高可用

面试官：如果订单服务调用库存服务超时了，你是直接失败，还是重试？

谢飞机：我当然重试！多试几次总能成功！ 面试官：盲目重试可能加剧雪崩。你应该用熔断器，比如 Resilience4j 或 Hystrix。
面试官：说说什么是熔断？它和降级有什么区别？

谢飞机：熔断……就是断了嘛！降级……就是降一级……比如不发短信了…… 面试官：……熔断是自动切断故障依赖，降级是主动关闭非核心功能，两者常配合使用。
面试官：系统上线后，你怎么知道订单服务有没有异常？靠用户反馈吗？

谢飞机：我打开日志文件 tail -f 看着！ 面试官：这不行。你应该接入 ELK 做日志收集，Prometheus + Grafana 做指标监控。
面试官：如果发现某个接口响应时间突然变长，你怎么排查？

谢飞机：我……重启一下服务？ 面试官：重启治标不治本。要用 APM 工具如 SkyWalking 或 Jaeger 查链路追踪，定位瓶颈。
面试官：最后一个问题：你的代码怎么保证质量？只靠测试吗？

谢飞机：我写了……两个单元测试！JUnit 写的！ 面试官：太少。应该有单元测试、集成测试、CI/CD 自动化构建，结合 SonarQube 做代码扫描。

面试官（合上笔记本）：今天就到这里。你的基础还可以，但分布式系统的理解还需要加强。回去好好看看 Spring Cloud、Kafka 原理、Redis 高可用这些知识点。

谢飞机：好的好的！我回去一定学！

面试官：嗯，回家等通知吧。

✅ 技术解析：电商秒杀系统的核心设计要点

🌐 业务场景：电商秒杀系统

核心矛盾：极短时间内的超高并发请求 vs 数据库有限的处理能力
目标：防超卖、高可用、低延迟、最终一致性

🧩 关键技术点详解

1. Redis 预减库存 + 原子操作

将商品库存提前加载到 Redis，使用 INCRBY / DECR 原子操作扣减
利用 Lua 脚本保证多命令的原子性，防止超卖

示例 Lua 脚本：

local stock = redis.call('GET', KEYS[1])
if tonumber(stock) <= 0 then
  return 0
else
  redis.call('DECR', KEYS[1])
  return 1
end

2. Kafka 实现异步解耦

用户抢购成功后，发送 SeckillSuccessEvent 到 Kafka Topic
订单、库存、优惠券、积分等服务作为消费者异步处理
优势：削峰填谷、系统解耦、提高吞吐量

3. Spring Boot + Spring Kafka 集成

@KafkaListener(topics = "seckill-success")
public void handleSeckillSuccess(SeckillEvent event) {
    orderService.createOrder(event.getUserId(), event.getProductId());
}

4. 熔断与降级（Resilience4j）

当下游服务（如库存）响应慢或失败时，触发熔断，返回默认值或友好提示
避免连锁故障（雪崩）

5. 监控体系搭建

日志：Logback + ELK（Elasticsearch, Logstash, Kibana）
指标：Micrometer + Prometheus + Grafana
链路追踪：Spring Cloud Sleuth + Zipkin/Jaeger

6. 高可用保障

Redis：Cluster 模式 + 哨兵 + RDB/AOF 持久化
Kafka：多副本 + ISR 机制 + ZooKeeper 管理
服务部署：Kubernetes 集群 + HPA 自动扩缩容

7. CI/CD 流程

Git → GitHub Actions/Jenkins → Docker 构建 → Kubernetes 部署
自动化测试 + 代码质量扫描（SonarQube）

📚 总结

本文通过模拟面试形式，带你深入理解电商系统中 Spring Boot、Redis、Kafka 的实际应用。重点掌握：

高并发下的流量控制
异步解耦与事件驱动
系统容错与监控
全链路可观测性

这些不仅是面试高频考点，更是大厂核心系统的必备能力。建议动手搭建一个简易秒杀Demo，实践出真知！

标签

#Java面试 #Spring Boot #Kafka #Redis #电商架构