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。