Java 大厂面试实录：Spring Boot + Kafka + Redis + Spring Cloud + RAG 的一场“燕双非”翻车现场

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

人物：严肃面试官、搞笑但时常水货的程序员燕双非

第一轮：电商大促与订单链路

面试官：我们先从电商大促聊起。一个下单接口，Spring Boot 里你会怎么设计它的分层？

燕双非：嗯，Controller 接收参数，Service 做业务，Repository 负责数据访问，最好再加一个 DTO 转换层，避免实体直接暴露。

面试官：不错，至少结构是对的。那如果你要做参数校验和统一异常处理呢？

燕双非：参数校验用 JSR-380，哦不对现在应该叫 Jakarta Validation 吧；统一异常处理用 @ControllerAdvice，失败时返回统一的错误码和提示信息。

面试官：可以，说明基础还在。那下单后要发消息扣库存、发券、写日志，你会怎么保证可靠性？

燕双非：这个我熟，先本地事务提交，再发 Kafka 消息。为了防止重复消费，消费者要做幂等，通常可以用业务唯一键或 Redis 去重。

面试官：对，继续说说 Kafka 适合这个场景的原因。

燕双非：吞吐高、可扩展，适合大促这种峰值流量。并且可以通过分区提升并发处理能力，不过我经常把分区和副本搞混……

面试官：副本是高可用，分区是并行度，别混。那库存扣减如果要避免超卖，你会怎么做？

燕双非：嗯……数据库乐观锁？或者 Redis 预扣库存，再异步落库？

面试官：思路没问题，先这样。大促系统里，缓存和消息队列的组合要是能想清楚，已经比很多人强了。

第二轮：用户画像与推荐系统联动

面试官：接下来假设你在做内容社区，用户浏览、点赞、收藏后要做画像沉淀。Redis 在这里能怎么用？

燕双非：可以做热点内容缓存、用户最近行为缓存，还能用 Sorted Set 记录热度榜。用户标签也可以先存在 Redis 里，定时批量入库。

面试官：不错。那如果你要同时支持实时推荐和离线推荐，Spring Cloud 体系里怎么拆服务？

燕双非：可以拆成用户服务、内容服务、推荐服务、行为采集服务。服务之间用 OpenFeign 调用，注册发现可以用 Eureka 或者 Consul。

面试官：很好。那推荐服务不稳定时，怎么避免拖垮整个系统？

燕双非：用 Resilience4j 做限流、熔断、隔离。这样推荐挂了也不至于影响主链路，最多降级成热门列表。

面试官：降级思路对。再往下，行为数据如果量很大，要做流式处理，你会怎么选？

燕双非：如果是实时统计，可以用 Flink；如果是离线批处理，可以用 Spark。对了，Kafka 也可以作为数据管道。

面试官：可以。那这里的推荐结果，你如何解释“为什么给用户推这个内容”？

燕双非：呃……因为模型觉得他会喜欢？如果要技术上解释，应该结合用户画像标签、相似用户行为、内容向量召回这些。

面试官：这就开始像样了。推荐系统不是只会“推”，还要能解释、能回溯、能调参。

第三轮：AIGC 助手与企业文档问答

面试官：最后我们看一个 AIGC 场景。公司要做一个企业知识库问答助手，基于 Spring AI，你会怎么设计？

燕双非：先做文档加载，把 PDF、Word、Wiki 文档统一切分成文本块，再做向量化，存进向量数据库，比如 Milvus 或 Redis 向量能力。用户提问时先语义检索，再把召回结果拼进提示词给大模型。

面试官：不错，已经到 RAG 了。那如果企业文档很杂，答案需要引用来源，你怎么控制幻觉？

燕双非：要做检索增强生成，限制模型只能基于召回上下文回答；同时输出引用片段和文档来源。如果检索不到，就明确说不知道，而不是瞎编。

面试官：对，这就是抑制 AI 幻觉的关键。那如果要做复杂工作流，比如“先查制度、再查审批人、再发起通知”，你会怎么组织？

燕双非：可以把它拆成 Agent 或工具调用流程。模型负责决定调用哪个工具，工具执行框架负责调用内部系统，比如审批服务、消息通知、WebSocket 实时推送。

面试官：很好。那如果要把这个系统做成可扩展的企业级方案，你觉得 MCP 这种标准有什么价值？

燕双非：嗯……它像是把模型和工具之间的接口标准化，方便不同模型接不同工具，减少重复集成。这样以后换模型或者加新工具会更稳。

面试官：回答得还行，虽然有点飘，但方向没错。今天先到这里，你回家等通知吧。

问题详解：结合业务场景深入理解

1. Spring Boot 分层与统一异常处理

在电商下单场景中，Controller 负责接入请求，Service 处理业务规则，Repository 负责数据持久化，DTO/VO 负责数据隔离。统一异常处理通过@ControllerAdvice和@ExceptionHandler实现，能够让接口返回统一格式，便于前端和调用方处理。

2. Kafka 在大促链路中的作用

Kafka 适用于高吞吐、削峰填谷和异步解耦。下单成功后发送订单事件，库存、积分、营销等下游服务异步消费，避免同步链路过长。需要关注消息幂等、重试、死信队列、消息顺序和重复消费等问题。

3. 库存防超卖

常见方案包括数据库乐观锁、悲观锁、Redis 预扣库存、消息最终一致性等。高并发下通常先用 Redis 或本地缓存拦截流量，再异步落库，核心是让库存扣减具备原子性，并配合幂等和补偿机制。

4. Redis 在内容社区与画像场景中的使用

Redis 可用于热点内容缓存、用户行为计数、排行榜、会话存储等。对于用户画像，可通过 Hash、Set、ZSet 等结构保存标签和热度数据，再通过定时任务或流式任务落库。关键在于缓存一致性、过期策略和热点 Key 保护。

5. Spring Cloud、OpenFeign 与 Resilience4j

在微服务中，OpenFeign 便于声明式调用远程服务；Eureka/Consul 提供注册发现；Resilience4j 提供限流、熔断、重试和隔离。推荐服务挂了不应影响主流程，因此要设计降级策略，例如返回热门内容或默认推荐。

6. Flink 与 Spark 的区别

Flink 更偏实时流处理，适合事件驱动、低延迟统计、实时画像；Spark 更适合批处理和离线分析。内容社区中可用 Kafka 收集行为日志，再通过 Flink 实时计算热度和用户兴趣，离线画像则由 Spark 生成更完整的特征。

7. RAG 企业知识库问答

RAG 的核心是“先检索，再生成”。先把企业文档切分、Embedding、向量化并存入向量库，用户提问时做语义检索，召回相关片段后再交给大模型回答。这样可显著降低幻觉，提高答案与企业知识的一致性。

8. 如何抑制 AI 幻觉

要通过检索约束、引用来源、回答边界控制、置信度判断和失败兜底来降低幻觉。对于无法从知识库检索到的内容，要明确告知用户无法确认，而不是生成看似合理但错误的答案。

9. Agent、工具调用与 MCP

Agent 负责智能决策，决定下一步调用哪个工具；工具执行框架负责真正执行系统操作；MCP 则是将模型与工具之间的交互标准化，让工具接入更统一、更可扩展。适用于复杂企业工作流，如审批、检索、通知、工单流转等。

10. WebSocket 在企业助手中的作用

WebSocket 可用于实时推送问答进度、审批状态、任务执行结果等。对于长耗时任务，前端无需轮询，体验更好，也更适合协同办公、智能客服等场景。

感谢阅读，希望这篇文章能帮助大家更好地准备 Java 面试，在真实业务场景中理解技术、掌握技术、讲清技术。祝大家面试顺利，早日拿到满意的 offer！