Java 大厂面试实录：Spring Cloud + Kafka + Redis + Spring Security + AI 的电商增长系统深挖

场景：某互联网大厂电商增长团队 Java 岗位面试。

面试官严肃克制，候选人燕双非一脸“我懂一点但不多”的轻松表情。

---

第一轮：订单与库存链路

面试官：如果你来设计一个秒杀活动下单链路，为什么很多团队会优先选 Spring Boot + Spring MVC，而不是一上来就上 WebFlux？

燕双非：因为 Spring Boot 上手快，MVC 也是同步模型，业务同学容易理解。秒杀场景虽然并发高，但大部分逻辑还是校验、扣库存、发消息，MVC 能先把流程跑通。WebFlux 更适合大量 I/O 阻塞少、链路异步化明确的场景。

面试官：不错，至少没把“高并发”四个字直接贴在 WebFlux 上。那你说说，订单创建后为什么常常要发 Kafka，而不是直接同步调用库存服务？

燕双非：同步调用会让下单接口依赖库存服务可用性，容易级联失败。Kafka 可以把“创建订单”和“扣减库存”解耦，先保证主链路快速返回，再由异步消费者处理后续动作。这样还能削峰填谷。

面试官：那 Kafka 消费失败了怎么办？你会怎么设计重试和幂等？

燕双非：嗯……我会先重试几次，如果还不行就进死信队列。幂等的话一般靠业务唯一键，比如订单号，消费者先查库判断是否处理过，避免重复扣减。还有就是消息体里最好带上操作类型和版本号，防止乱序。

面试官：回答还算完整，继续。

面试官：库存扣减既要快又要防超卖，你会怎么用 Redis 设计？

燕双非：可以把库存预热到 Redis，用 Lua 脚本原子扣减，避免并发下超卖。扣减成功后再发 MQ 异步落库。若要防止重复请求，还可以做用户维度的幂等键，比如用户+活动+商品维度。

面试官：可以，至少知道 Lua 原子性。那如果 Redis 挂了，你怎么兜底？

燕双非：可以有降级策略，比如直接返回活动繁忙，或者切到数据库限流方案。不过数据库会比较重，所以通常只作为兜底。生产上还要加监控和告警，不然你会很忙。

---

第二轮：安全、链路治理与可观测性

面试官：用户下单前要做登录鉴权，你在 Spring Security 里一般怎么结合 JWT 和 OAuth2？

燕双非：如果是内部系统，JWT 可以做无状态鉴权，网关或者后端解析 token 里的用户身份和权限。OAuth2 更像授权框架，适合对接统一认证中心，第三方登录或者多系统单点登录。Spring Security 负责把认证授权流程串起来。

面试官：那 JWT 这么方便，有什么风险？

燕双非：主要是无法天然撤销，token 一旦签发在有效期内都能用。所以一般要控制过期时间，配合刷新 token、黑名单或者版本号机制。另外密钥管理也很重要，别把私钥写在代码里。

面试官：说得像个见过事故的人。那你如何监控下单链路的性能？

燕双非：我会接入 Micrometer，把接口耗时、Kafka 消费延迟、Redis 命中率、数据库慢查询都打到 Prometheus，再用 Grafana 看图。链路追踪可以接 Zipkin 或 Jaeger，这样能看出一次请求经过了哪些服务，哪里慢一眼能发现。

面试官：如果你发现下单接口 RT 飙高，但 CPU 并不高，你会先怀疑什么？

燕双非：我会先怀疑 I/O 阻塞，比如数据库慢、Redis 超时、远程调用堆积，或者线程池饱和。CPU 不高不代表没问题，可能大家都在等锁、等网络、等下游返回。

面试官：很好。那你的接口文档怎么对外提供？

燕双非：一般会用 Swagger/OpenAPI 自动生成接口文档，配合统一返回体和错误码，前后端联调比较省事。如果对外提供更强的契约能力，也可以结合 OpenAPI 生成客户端代码。

---

第三轮：AI 营销推荐与企业智能助手

面试官：我们现在想做一个“AI 商品导购助手”，能基于用户历史行为和商品知识回答问题。你会怎么设计，为什么不是把所有文档直接丢给大模型？

燕双非：直接全丢进去一是上下文有限，二是成本高，三是容易幻觉。更合理的是做 RAG，把商品文档、活动规则、FAQ 做向量化，存到向量数据库里，用户提问时先语义检索，再把相关片段喂给模型生成答案。

面试官：那你如何判断模型回答得靠谱不靠谱？

燕双非：可以做检索结果置信度控制，如果召回内容太少或者相似度太低，就转人工或者返回“我没查到”。另外对关键业务问题，比如价格、库存、退款政策，最好优先走结构化系统接口，而不是让模型自由发挥，防止幻觉。

面试官：如果要做一个企业内部的智能客服系统，除了 RAG 你还会考虑什么？

燕双非：还要考虑 Agent 和工具调用。比如客服不仅要回答问题，还要查订单、查物流、发起工单，这些都可以封装成工具，让 Agent 选择调用。还可以设计会话内存，保留用户上下文，减少重复提问。

面试官：那 Spring AI 在这里能做什么？

燕双非：Spring AI 可以把模型调用、提示词模板、向量检索、工具调用这些能力统一起来，方便在 Java 里做编排。比如接 OpenAI 或 Ollama 的 Embedding 模型，把文档切片后做向量化，再结合 Redis 或 Milvus 存储向量，最后通过一个标准化的接口服务化。

面试官：好，最后一个问题：如果业务要求这个 AI 助手既能查文档，又能查订单，还能自动生成工单，你怎么保证流程可控？

燕双非：我会把复杂工作流拆成多步，限定 Agent 的工具权限，关键动作加审批或二次确认。比如先识别意图，再走检索，再查订单，最后生成工单。每一步都要打日志、可追踪、可回放，避免 Agent 随便乱点按钮。

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

---

问题详解：从业务到技术的落地思路

1. Spring Boot / Spring MVC 与 WebFlux 的选择

在电商秒杀、订单创建、营销活动等典型场景里，核心不是盲目追求“最潮”，而是看业务链路是否适合同步模型。Spring MVC 适合大多数以数据库、缓存、消息队列为核心的业务系统，团队协作成本低，排查问题也更直观。WebFlux 适合高吞吐、I/O 密集、端到端异步链路较完整的系统，但引入后对编程模型、上下游依赖、线程与背压理解要求更高。

2. Kafka 在订单链路中的作用

Kafka 常用于削峰填谷、异步解耦和事件驱动。订单创建后同步返回，库存扣减、积分发放、营销埋点、通知发送都可以异步处理。这样做能提高系统可用性和响应速度，但必须配套幂等、重试、死信、监控和补偿机制。常见幂等方案包括业务唯一键、去重表、状态机校验、版本号控制等。

3. Redis 原子扣减与防超卖

Redis 适合做热点库存、限流计数、请求去重、会话缓存。秒杀里通常会把库存预热到 Redis，借助 Lua 脚本完成原子判断和扣减，确保并发下不会超卖。扣减成功后再通过 MQ 异步落库，这样能把高并发压力从数据库转移出去。兜底方案一般是熔断、降级、限流和库存回源校验。

4. Spring Security、JWT 与 OAuth2 的关系

Spring Security 负责认证、授权和安全过滤链。JWT 更偏向无状态令牌，适合微服务内部鉴权和前后端分离场景；OAuth2 更偏向授权协议和统一身份接入，适合 SSO、第三方授权和认证中心。生产中通常会结合 token 过期控制、刷新机制、黑名单、签名密钥轮换来提升安全性。

5. Micrometer、Prometheus、Grafana 与链路追踪

高质量的 Java 系统一定离不开可观测性。Micrometer 可以把 JVM、接口、业务指标统一暴露出去，Prometheus 负责采集，Grafana 负责展示。链路追踪工具如 Zipkin 或 Jaeger 能定位跨服务调用的瓶颈，尤其适合排查“CPU 不高但 RT 很高”的问题，因为这类问题往往是数据库、网络、锁竞争或线程池饱和导致。

6. Swagger/OpenAPI 的价值

接口文档不是“附属品”，而是前后端协作和对外集成的重要契约。Swagger/OpenAPI 能自动生成接口说明、请求响应模型、错误码约定，甚至生成客户端 SDK。对于电商增长、营销平台、开放 API 场景，统一的契约能显著减少沟通成本和联调成本。

7. RAG、向量检索与 AI 幻觉控制

在企业 AI 场景中，直接把所有资料丢给大模型既不经济，也不可靠。RAG 的核心是先检索后生成：将文档切片、向量化、存入向量数据库，再根据用户问题召回相关知识片段，最后交给大模型生成答案。这样可以提升回答的可控性和可解释性。对于价格、库存、退款政策等关键问题，最好优先查询业务系统，而不是完全依赖模型推理，以降低幻觉风险。

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

当 AI 从“回答问题”升级为“执行任务”，就需要 Agent、工具调用和工作流编排。工具可以是查订单、查物流、建工单、发邮件等标准化能力。为了控制风险，通常要限制工具权限、设置审批节点、记录执行轨迹，并对关键动作引入人工确认。这是企业级 AI 应用和玩具型聊天机器人最大的区别。

感谢阅读

希望这篇 Java 面试实录能帮助你把电商高并发、消息解耦、缓存设计、安全认证、可观测性和 AI 落地这些知识串起来，真正做到“会答题，更会落地”。感谢阅读，愿你在面试和实战中都能稳稳发挥，顺利拿到心仪的 offer。