Java 大厂面试实录：Spring Boot + Kafka + Redis + RAG 场景下的 3 轮高频追问

场景：互联网大厂 Java 求职面试。

面试官严肃，候选人是外号“燕双非”的搞笑水货程序员。

第一轮：电商大促的下单与库存链路

面试官：我们先从一个电商场景开始。大促活动里，下单接口峰值很高，你会怎么设计 Spring Boot 接口的整体链路？

燕双非：嗯……先用 Spring Boot 起个服务，然后做个限流，前面再挂个 Nginx，后面接数据库，应该就能扛住了。

面试官：方向对，但还不够完整。那如果库存扣减要避免超卖，你会怎么结合 Redis 和数据库来做？

燕双非：可以先把库存放 Redis，用户下单先扣 Redis，成功了再异步落库……大概就是这个意思。反正 Redis 很快嘛。

面试官：不错，至少知道先快后慢。但异步落库会带来一致性问题，你打算怎么处理消息重复、丢失和回滚？

燕双非：这个……可以加个消息队列，失败重试，或者做个幂等吧。具体怎么幂等我再想想。

面试官：好，至少方向上没跑偏。那订单创建成功后，需要通知库存、积分、优惠券三个服务，你会选 Kafka 还是 RabbitMQ？为什么？

燕双非：我觉得都行，Kafka 听起来更适合“高并发”，RabbitMQ 听起来更适合“兔子”……

面试官：……先别讲段子。大促链路里更关键的是吞吐、削峰、可追溯和顺序性。你要能讲清楚为什么选 Kafka，以及如何保证消费者幂等。

第二轮：微服务治理、接口安全与可观测性

面试官：继续。现在订单服务要拆成多个微服务，你会如何做服务治理？比如服务发现、限流、熔断、降级。

燕双非：服务发现可以用 Spring Cloud，限流和熔断也能配一些组件，反正大家都这么做。

面试官：那如果你用 OpenFeign 调用远程服务，怎么设计超时、重试和 fallback，避免雪崩？

燕双非：我会把超时设短一点，失败了就重试，重试不行就降级返回一个默认值。

面试官：思路还可以，但重试不是越多越好。你需要考虑幂等、线程池隔离，以及 Resilience4j 这种治理能力。那接口暴露给 App 和小程序，认证你怎么做？

燕双非：Spring Security 加 JWT 吧，登录后发个 token，后面都带着。

面试官：继续说，JWT 放在 Header 里有什么优缺点？如果要接入第三方登录或统一身份中心呢？

燕双非：优点是无状态，缺点是不好主动失效。第三方登录……应该可以接 OAuth2 或 Keycloak 之类的吧。

面试官：可以。最后一个问题：你如何监控这条链路的性能瓶颈？

燕双非：上 Prometheus 和 Grafana 看指标，Spring Boot 里加 Micrometer，再配日志和链路追踪……比如 Zipkin、Jaeger。

面试官：这次回答比前面稳一点。那你说说，如果是线上慢请求，你怎么定位到底是 DB、缓存、MQ 还是远程调用的问题？

燕双非：先看链路追踪，再看日志，再看数据库慢查询，缓存命中率和 MQ 堆积情况……大概这么排查。

第三轮：AI 检索增强与智能客服系统

面试官：现在公司要做一个智能客服系统，接入企业文档问答。你会怎么设计一个 RAG 架构？

燕双非：RAG 就是先把文档切块，再向量化，存到向量数据库里，用户提问时做语义检索，取相关内容给大模型生成答案。

面试官：不错，概念基本正确。那如果企业文档很多，怎么处理文档加载、切分、Embedding 选择和召回质量？

燕双非：文档加载可以分批做，切分得考虑段落语义，Embedding 模型可以选 OpenAI 或 Ollama 的，召回不好就调切块大小和检索策略。

面试官：继续。智能客服里会出现 AI 幻觉，你怎么降低它？

燕双非：嗯……可以让它别瞎说。技术上应该是尽量让它只基于检索到的内容回答，必要时加提示词约束和答案引用。

面试官：最后一个问题：如果这个系统要支持工具调用、复杂工作流和多轮会话记忆，你会怎么做？

燕双非：可以用 Agent 方案，把工具调用标准化，保存会话内存，必要时让模型调用工单系统、订单系统、知识库系统。复杂工作流就拆成多个步骤，让它一步一步来。

面试官：回答到这里为止吧。整体来看，你对基础概念有一些了解，但系统设计深度和落地细节还不够。你先回家等通知吧。

问题详解：逐题拆解业务场景与技术要点

1. Spring Boot 下单链路怎么设计？

在电商大促中，Spring Boot 常用于快速构建订单服务。核心思路是把链路拆成：网关层限流、接口层校验、业务层创建订单、消息层异步通知、存储层持久化。接口设计要关注幂等、超时和降级。

业务上可以把“创建订单”和“扣减库存”解耦：订单主流程快速返回，后续通过消息驱动库存、优惠券、积分等系统异步处理。这样既能提高吞吐，也能降低用户等待时间。

2. Redis 扣库存如何避免超卖？

常见做法是先在 Redis 中预扣库存，再通过消息队列异步落库。关键点有三个：

• Redis 预扣必须原子化，通常用 Lua 脚本保证检查与扣减一体完成；
• 数据库最终扣减要做乐观锁或版本号控制；
• 消息消费必须幂等，避免重复扣减。

如果消息失败，需要有补偿机制，例如定时对账、失败重试、事务消息或本地消息表。

3. Kafka 适合什么场景？

Kafka 更适合高吞吐、可回放、日志型事件分发场景。在订单成功后通知库存、营销、积分等多个下游服务时，Kafka 的分区、消费者组和顺序性控制更有优势。

面试中要讲清楚：为什么不是所有场景都用 RabbitMQ。Kafka 强在吞吐和流式处理，RabbitMQ 在灵活路由、低延迟和复杂确认机制上更常见。选型要基于业务特征，而不是“谁更火”。

4. 消费者如何保证幂等？

幂等可以通过业务唯一键、去重表、Redis SETNX、数据库唯一索引等方式实现。比如订单事件消息中携带订单号，消费者先查询是否已处理，未处理才执行库存扣减并记录处理结果。

对于高并发场景，优先考虑数据库唯一约束和分布式缓存结合，以避免并发重复消费。

5. 微服务治理怎么做？

典型方案包括服务发现、配置中心、负载均衡、熔断、限流、降级、重试和隔离。Spring Cloud 可快速集成这些能力，OpenFeign 负责声明式调用，Resilience4j 可实现熔断、限流和舱壁隔离。

重点不是“堆组件”，而是知道每个机制解决什么问题：熔断防止故障扩散，限流保护下游，降级保证核心链路可用，重试处理瞬时抖动，但要谨慎使用，避免放大压力。

6. JWT、OAuth2、Keycloak 怎么理解？

JWT 是一种令牌格式，适合无状态认证；OAuth2 是授权框架，适合第三方接入和统一授权；Keycloak 是开源身份认证与授权平台，可作为统一登录中心。

大厂场景中，常见做法是：用户登录后由统一身份中心签发 token，业务系统只负责校验和鉴权。JWT 适合前后端分离，但要注意过期、刷新、吊销和密钥轮换。

7. 如何定位慢请求？

排查路径建议从上到下：网关、应用日志、链路追踪、缓存命中率、MQ 堆积、数据库慢查询、外部依赖超时。Prometheus 采集指标，Grafana 可视化展示，Micrometer 统一埋点，Zipkin/Jaeger 用于链路追踪。

真正面试时要体现“可观测性思维”：不是只会看日志，而是知道指标、日志、链路三件套如何配合。

8. RAG 架构是什么？

RAG 即检索增强生成。流程通常是：文档加载、清洗、切分、Embedding 向量化、存入向量数据库、用户提问时做语义检索、拼接上下文、交给大模型生成答案。

在企业文档问答里，RAG 的优势是答案更贴近企业知识库，能减少模型凭空编造。向量数据库可以选 Milvus、Chroma 或 Redis 向量能力，Embedding 模型可使用 OpenAI 或本地 Ollama 生态。

9. 如何降低 AI 幻觉？

核心方法是减少模型自由发挥空间：只允许基于检索内容回答、增加引用来源、设置拒答策略、限定输出格式、引入人工审核或置信度阈值。

如果是智能客服，建议把“无知识答案”转换成“转人工”或“工单创建”，而不是让模型瞎编。

10. Agent、工具调用、复杂工作流怎么落地？

Agent 强调模型具备规划和调用工具的能力。企业里常把订单查询、工单创建、知识检索、客户画像等封装成标准工具，通过统一协议暴露给模型。

复杂工作流建议拆分为：意图识别、工具选择、执行、结果校验、结果生成五个环节。会话内存用于保留上下文，但要控制长度，避免带入无关历史。

结语

以上就是本次 Java 大厂面试实录的完整内容。希望这篇文章能帮助你在准备 Spring Boot、Kafka、Redis、微服务治理、RAG 与智能客服等高频面试题时，既能理解概念，也能结合真实业务场景讲出深度。

感谢阅读，希望真的能帮助到你，祝大家面试顺利，早日拿到满意的 offer！