Java 面试实战：Spring Cloud + Kafka + Redis + AI RAG 在电商大厂的三轮攻防

场景：互联网大厂电商平台 Java 面试。

人物：严肃的面试官，和有点水但很会插科打诨的候选人燕双非。

---

第一轮：基础与业务建模

面试官：你先说说，电商下单链路里，为什么通常会把“创建订单”和“扣减库存”拆成两个服务？

燕双非：因为这样更符合微服务拆分嘛，订单管订单，库存管库存，职责清晰，出了问题也方便定位。比如高峰期秒杀，库存服务可以单独扩容，不会把订单系统拖垮。

面试官：回答得还可以。那你说说，订单创建后如何通知库存服务？

燕双非：可以用 Kafka 发消息。订单服务先落库，再发一条“订单已创建”的事件，库存服务订阅后扣减库存。这样解耦，吞吐也高。

面试官：消息重复消费怎么办？

燕双非：嗯……可以做幂等。比如用订单号做唯一键，库存表里加处理记录，重复消息来了就直接跳过。

面试官：不错，至少知道要“防重复”。那用户下单前需要登录态，你会怎么做认证？

燕双非：可以用 JWT。登录成功后给前端一个 token，后续请求带上，服务端验签和过期时间就行。这样不依赖 session，适合多实例部署。

---

第二轮：中间件与稳定性

面试官：电商大促时，订单查询接口突然变慢了，你会先看什么？

燕双非：先看监控，Prometheus 和 Grafana 看 QPS、RT、错误率，还有数据库慢查询。再看链路追踪，比如 Jaeger 或 Zipkin，判断卡在哪一段。

面试官：如果是 Redis 缓存击穿了呢？

燕双非：那就热点 key 失效导致大量请求打到数据库。可以用互斥锁、逻辑过期，或者提前预热缓存。热点数据也可以本地加 Caffeine 做一层兜底。

面试官：那库存扣减时，Redis 和 MySQL 数据一致性怎么保证？

燕双非：这个……一般会用最终一致性。先在 Redis 做预扣，再通过消息队列异步落库。失败的话就补偿，或者用事务消息，不过要看业务容忍度。

面试官：你知道 Spring Cloud 里常见的熔断限流组件吗？

燕双非：Resilience4j，配合 Spring Cloud Gateway 可以做限流、熔断、重试。比如库存服务抖动时，快速失败，别把线程池打满。

面试官：你说到网关了，如果要给开放 API 提供文档和调试能力呢？

燕双非：Swagger/OpenAPI。前后端联调和第三方接入会方便很多，还能生成接口说明。

---

第三轮：AI 化与复杂业务扩展

面试官：现在电商接入 AI 智能客服，用户问“我的订单什么时候到”，你怎么设计？

燕双非：可以做一个基于 Spring AI 的智能客服系统，先走自然语言语义搜索，从向量数据库里找订单物流、售后规则、商品说明等文档，再结合工具调用去查订单状态。

面试官：你提到了 RAG，具体怎么避免模型胡说八道？

燕双非：嗯……先做文档加载和切分，生成 embedding 存到 Milvus 或 Redis 向量结构里，问题来了先检索相关片段，再把上下文喂给大模型。并且给模型加约束，只允许基于检索结果回答；如果没命中，就转人工。这样能减少幻觉。

面试官：如果客服需要调用多个系统，比如订单、物流、退款，怎么编排？

燕双非：可以用 Agent，或者复杂工作流。让 AI 先规划步骤，再通过工具调用标准化去访问不同服务。比如先查订单，再查物流，再判断是否满足退款条件。

面试官：最后一个问题，整套系统上线到 Kubernetes 上，你会重点关注什么？

燕双非：资源请求和限制、探针、滚动发布、HPA、配置中心、日志和监控，还有 Kafka、Redis 这些依赖的连接数与超时设置。容器里别把 JVM 堆配太满，不然 OOM 了就很尴尬。

面试官：行了，今天先到这里，你回去等通知吧。

---

面试问题详解

1. 为什么订单和库存拆分成两个服务？

在电商业务中，订单与库存天然属于不同职责域。订单服务关注交易、价格、优惠、收货信息；库存服务关注可售库存、锁库存、扣库存、释放库存。拆分后可以独立扩容、独立演进，降低耦合。典型链路是：订单创建成功后，通过 Kafka 发送事件，库存服务异步消费并执行扣减或预留库存。这样可以提升系统吞吐并削峰填谷。

2. 消息队列在订单链路中的作用是什么？

Kafka 适合高吞吐事件流场景。订单创建后发出领域事件，库存、积分、风控、营销等下游服务订阅处理。它的价值在于解耦、异步化、削峰、广播。需要重点关注消息幂等、重试、死信、顺序性和消息堆积。实际业务里，消费端必须以业务唯一键做去重，避免重复扣库存、重复发券。

3. JWT 适合什么场景？

JWT 适用于无状态认证，特别是前后端分离、多实例部署、网关统一鉴权的场景。服务端签发 token 后，客户端后续请求携带 token 即可。优点是不依赖 session 存储，扩展方便；缺点是 token 一旦签发，在过期前难以主动失效，因此通常需要配合黑名单、短有效期和刷新机制。

4. 如何排查接口慢？

首先看指标：QPS、RT、错误率、CPU、内存、GC、数据库连接池、线程池。其次看分布式链路追踪，确认慢在网关、服务、缓存还是数据库。再看 SQL 是否命中索引、是否存在 N+1 查询、是否有缓存穿透/击穿。Prometheus + Grafana 负责指标，Jaeger/Zipkin 负责链路，日志则用 ELK 辅助定位异常堆栈。

5. Redis 缓存击穿怎么解决？

热点 key 失效瞬间，大量请求打到数据库，容易压垮后端。常见解决方案包括：互斥锁重建缓存、逻辑过期、热点预热、本地缓存 Caffeine 兜底、设置合理过期时间并加随机抖动。电商详情页、秒杀库存、活动配置都常见这个问题。

6. 如何处理 Redis 与 MySQL 一致性？

严格一致性成本高，电商中常采用最终一致性。常见模式是“先写数据库，再删缓存”或“先预扣缓存，再异步落库”，配合消息队列与补偿机制。核心原则是明确一致性边界，避免业务写路径过慢，同时通过补偿任务保证最终状态收敛。

7. Resilience4j 为什么常用于微服务治理？

它提供限流、熔断、重试、隔离等能力，能在下游依赖不稳定时保护系统。比如库存服务响应慢时，网关可直接限流，服务间调用可快速失败，避免线程堆积导致雪崩。与 Spring Cloud 结合时配置较灵活，适合现代 Java 微服务体系。

8. Swagger/OpenAPI 在团队中的价值是什么？

它能统一接口定义、生成在线文档、支持调试和代码生成。对于电商平台开放 API、前后端并行开发、第三方商家接入都非常重要。文档即契约，能显著减少沟通成本。

9. Spring AI + RAG 如何做智能客服？

典型流程是：文档加载、清洗切分、向量化、存入向量数据库；用户提问后做语义检索，召回相关片段，再将上下文交给大模型生成答案。若要回答订单物流等动态信息，还需要通过工具调用访问业务系统。这样既能利用大模型的语言能力，又能通过检索和工具把答案约束在事实范围内。

10. 如何降低 AI 幻觉？

要点包括：限定回答范围、增加检索证据、低温度生成、设置兜底策略、对高风险答案转人工、在提示词中要求“仅依据检索内容回答”。对于企业客服、医疗、金融等场景，不能把模型当成唯一事实来源。

11. Agent 适合什么复杂场景？

当任务需要多步决策和多工具协同时，Agent 很有价值。例如“查询订单-判断物流-核对退款规则-发起售后”这类链式流程，可以让 Agent 规划并调用不同服务。复杂工作流通常还会结合状态机、审批流和人工介入。

12. Kubernetes 部署 Java 服务要注意什么？

需要关注资源 requests/limits、健康检查探针、滚动升级策略、服务发现、配置管理、日志采集以及 JVM 参数。尤其要避免内存配置与容器限制冲突，关注 GC 与 CPU 竞争，保证在弹性扩缩容时服务稳定。

---

感谢阅读，希望这篇文章能帮助大家更好地准备 Java 面试，梳理电商场景下的微服务、缓存、消息队列与 AI 应用知识。祝你面试顺利，拿到心仪的 offer！