Spring Boot + Kafka + Redis + RAG：互联网大厂 Java 面试故事集

文章简述：本文以互联网大厂 Java 面试为背景，围绕电商与 AI 服务场景，串联 Spring Boot、MyBatis、Kafka、Redis、Spring Security、OpenAPI、RAG 等技术栈，采用“严肃面试官 vs 水货程序员燕双非”的故事化问答形式，覆盖 3 轮循序渐进提问，并在文末逐题详解，帮助读者理解真实业务中的技术落地与面试表达。

第一轮：电商秒杀与接口设计

面试官：我们先从一个电商秒杀场景开始。你来设计下商品详情页和下单链路，Java 后端你会怎么选技术栈？

燕双非：这个我熟。前台接口我一般用Spring Boot起服务，配Spring MVC做 REST 接口，商品信息查库的话用MyBatis，简单一点还能配合HikariCP提升连接池性能。秒杀接口我会加Redis做库存预热和热点数据缓存，减少数据库压力。

面试官：嗯，基础思路对。那如果用户并发很高，缓存穿透和击穿你怎么处理？

燕双非：缓存穿透我会……那个，先加一个“防穿透机制”，比如空值缓存。击穿的话就是热点 key 失效时，嗯，搞一个互斥锁或者“单飞”模式，让一个线程回源，别的等着。

面试官：不错，能说出空值缓存和互斥锁，说明不是完全空白。那订单创建成功后，怎么异步通知库存、积分、营销系统？

燕双非：这个可以用Kafka发消息，订单服务提交成功后发一个订单创建事件，库存、积分、营销各自订阅。这样解耦，吞吐也高。

面试官：很好，至少知道事件驱动思路。那你如何保证消息不丢、不错发、少重复？

燕双非：这个我知道一点点，通常要保证生产端确认、消费端幂等，还有消息落库吧。至于具体细节……我回去再补补。

面试官：行，先到这里，我们继续下一轮。

第二轮：支付风控与安全治理

面试官：电商下单后就是支付。支付接口如果要做登录态和权限控制，你会怎么做？

燕双非：我会用Spring Security做认证授权，登录后签一个JWT，接口层统一校验 token。管理后台的话可以做角色权限控制，避免谁都能点“退款”。

面试官：可以。那如果要和第三方支付平台对接，签名验签、证书管理你会怎么考虑？

燕双非：这个一般是用RSA或者SM2做签名，证书放安全配置中心，或者密钥不直接进代码。验签失败就拒绝处理，避免被伪造回调。

面试官：思路对。支付回调会重复通知，你怎么处理幂等？

燕双非：我会给每个支付单号加唯一业务键，回调处理前先查状态，已成功就直接返回；或者用数据库唯一索引防重复插入。必要时也可以把回调事件放进消息队列，后面统一消费。

面试官：嗯，能结合数据库唯一约束和状态机思考，挺好。那支付链路里如果引入Resilience4j，你会用在哪？

燕双非：可以给第三方支付查询、风控校验这些外部依赖加熔断、限流、重试。比如支付网关抖了，不要把整个下单链路拖死。

面试官：对，这就是高可用思维。最后一个问题，支付系统的日志和链路追踪你怎么做？

燕双非：日志我会用SLF4J + Logback，再结合Micrometer打指标，链路追踪可以接Zipkin或Jaeger。这样出问题能快速定位在哪一环卡住了。

面试官：回答还算完整，我们进入第三轮，聊点更前沿的。

第三轮：AI 客服与企业知识问答

面试官：现在很多电商都在做 AI 客服。如果要做一个“订单查询 + 售后政策问答”的智能客服，你怎么设计？

燕双非：我会用Spring AI接大模型，再做一个RAG。客服问题先做语义检索，从知识库里找相关文档，再把检索结果拼到提示词里，让模型结合业务回答。

面试官：不错。那知识库怎么构建？

燕双非：先做文档加载，比如 FAQ、售后规则、商品说明书这些；再做切分、向量化，存到向量数据库，比如Milvus或Redis向量能力。用户提问后，先检索相似片段，再让大模型生成答案。

面试官：如果问答内容涉及实时订单状态，纯 RAG 能解决吗？

燕双非：不能完全靠 RAG。这个要引入工具调用，让 Agent 去调用订单查询接口、物流接口、售后系统。也就是把大模型当调度员，它需要知道什么时候查数据库，什么时候查知识库。

面试官：你提到了 Agent，那你理解的 Agent 和普通聊天机器人有什么区别？

燕双非：普通机器人一般是固定问答，Agent 更像会“想一想再行动”，它能做复杂工作流，还可以记住上下文，进行聊天会话内存管理，按步骤调用工具完成任务。

面试官：很好。那这种系统最怕什么问题？

燕双非：最怕AI 幻觉，比如明明没查到订单，模型自己编一个物流状态。所以要加事实约束、检索增强、工具优先、回答置信度控制，避免胡说八道。

面试官：行，今天先到这。你回去等通知吧，我们后续有消息再联系你。

问题详解：结合业务场景讲透核心知识点

1. Spring Boot + Spring MVC + MyBatis + HikariCP 在电商详情页中的作用

在商品详情和下单链路中，Spring Boot 负责快速搭建服务与自动装配，Spring MVC 提供 REST 接口层，MyBatis 负责高可控 SQL 访问商品、库存、订单等核心表，HikariCP 则提供高性能数据库连接池。对于高并发场景，接口层应尽量轻量，数据库访问要避免多次无谓查询，并配合缓存降低压力。

2. Redis 在秒杀和热点数据场景中的应用

Redis 常用于商品详情、库存预热、限购标记、用户购买资格判断等。热点 key 失效时可用互斥锁或逻辑过期方式避免击穿；对于不存在的数据，可用空值缓存或布隆过滤器降低缓存穿透风险。实际业务中，Redis 不是数据库替代品，而是高并发场景下的前置加速层。

3. Kafka 在订单异步链路中的价值

订单创建后，将“订单已创建”事件发送到 Kafka，可以解耦库存、积分、营销、通知等下游系统。Kafka 的关键不是“能发消息”，而是如何结合业务设计消息幂等、重试、死信、补偿和事务一致性。生产端确认、消费端幂等、业务唯一键和状态机设计，都是减少事故的重要手段。

4. Spring Security + JWT 在支付与后台管理中的实践

支付系统与管理后台通常需要严格的身份认证和授权控制。Spring Security 负责统一的安全过滤链，JWT 适合无状态认证，便于分布式部署。实际中要关注 token 过期、刷新机制、权限粒度、接口签名、防重放攻击等问题。对于资金类接口，不能只依赖前端传参，必须结合后端状态校验。

5. 第三方支付回调的幂等设计

第三方支付平台常见“多次回调”或“延迟回调”问题。推荐方案是：业务表中使用唯一订单号，回调处理前先读取订单状态；如果已处理成功则直接返回；如果未处理，则更新状态并写入流水。数据库唯一约束、状态机流转、分布式锁并不是互斥关系，通常会组合使用，以保证系统健壮。

6. Resilience4j 在外部依赖治理中的作用

支付网关、风控服务、物流服务等外部依赖不稳定时，Resilience4j 可提供熔断、限流、重试、隔离等能力。它的核心目标不是“让失败消失”，而是让失败快速暴露并阻断级联扩散，避免小故障演变为全链路雪崩。

7. Micrometer、Zipkin、Jaeger 与日志体系

日志、指标、链路追踪三者缺一不可。SLF4J + Logback 负责业务日志输出；Micrometer 负责采集接口耗时、错误率、队列堆积等指标；Zipkin 或 Jaeger 负责跨服务链路追踪。排障时，先看指标发现异常，再通过 Trace 定位调用链，最后借助日志还原上下文。

8. Spring AI + RAG 在智能客服中的落地

企业知识问答不应直接把所有问题交给大模型。正确方式是先做文档加载与切分，再通过 Embedding 模型把文本向量化，存入 Milvus、Redis 等向量数据库，用户提问后进行语义检索，把最相关的内容作为上下文喂给模型。这样可以显著降低 AI 幻觉，提高回答的可控性与准确性。

9. Agent、工具调用与复杂工作流

如果用户问的是“帮我查订单并改签物流”，模型必须具备调用订单系统、物流系统、规则引擎等工具的能力。这就是 Agent 的价值：它不仅生成答案，还能编排动作。企业级 Agent 往往需要管理会话内存、工具路由、权限边界、结果校验与异常补偿，避免模型越权操作或错误执行。

10. 面试表达建议

回答面试题时，最重要的是“先给结论，再讲方案，再补风险”。例如谈缓存，不要只背概念，要说“在商品详情页中，Redis 可以承接高频查询；库存热点 key 要防击穿；空值缓存和互斥锁用于防穿透和回源风暴”。这样更贴近真实业务，也更容易获得面试官认可。

结语

以上就是本次围绕电商支付与 AI 客服场景展开的 Java 面试故事与答案详解。希望这篇文章能帮助大家在准备大厂面试时，把技术点放到真实业务里去理解、去表达、去落地。感谢阅读，也希望真的能帮助到你，祝你面试顺利，早日拿到满意的 offer！