互联网大厂 Java 面试实录:Spring Boot、MyBatis、Kafka、Redis、Spring Security、Spring AI

📅 2026/8/24 2:12:59
互联网大厂 Java 面试实录:Spring Boot、MyBatis、Kafka、Redis、Spring Security、Spring AI
互联网大厂 Java 面试实录Spring Boot、MyBatis、Kafka、Redis、Spring Security、Micrometer、K8s、Spring AI场景某互联网大厂面试现场业务方向为智能本地生活服务 AI 客服 订单履约。面试官风格严肃候选人是外号“水货程序员燕双非”的社招 Java 求职者。下面是 3 轮递进式提问。第一轮基础架构与业务落地面试官我们先从你熟悉的技术说起。一个本地生活平台用户下单后需要经过商家接单、骑手接单、配送完成。你会怎么设计一个 Spring Boot 服务来支撑这个订单状态流转燕双非嗯这个我一般会先拆成订单服务、商家服务、配送服务。Spring Boot 起服务接口先做出来订单状态存在数据库里然后每个状态更新一下就行。面试官思路对继续说怎么保证并发下状态不会乱燕双非可以加个乐观锁吧version 字段。比如商家接单和骑手接单不会同时改同一条记录更新失败就重试。面试官不错至少你知道要防止脏写。那如果订单创建后还要发消息通知商家并且要做延迟取消怎么做燕双非可以用 Kafka 发订单创建消息延迟取消我记得可以用死信队列或者 Redis 过期 key 搭配定时任务。面试官回答还算靠谱。那你说说 MyBatis 和 JPA 在这种场景里怎么选燕双非MyBatis 更适合我这种喜欢手写 SQL 的订单这种业务表字段多、查询复杂MyBatis 可控一些。JPA 适合简单 CRUD但复杂查询有时候不好调。面试官可以至少知道边界。第一轮先到这里。第二轮中间件、可观测性与高可用面试官订单服务上线后活动一来流量暴涨。你怎么用 Redis 做缓存哪些数据适合缓存哪些不适合燕双非商家信息、商品详情、配置类数据适合缓存。订单详情也能缓存但要注意一致性。像支付结果这种强一致的我觉得不能随便缓存。面试官说到一致性缓存和数据库双写你怎么处理燕双非一般我会先更新数据库再删缓存。这样下次读会回源。要是高并发场景可能还得加消息队列做异步失效。面试官那如果你们用了 Spring Security JWT 做商家后台登录如何控制商家只能查看自己店铺的数据燕双非JWT 里带商家身份和角色Spring Security 里做鉴权。接口层再校验 shopId 是否和 token 里的主体一致。也可以用方法级权限控制。面试官那你知道 OAuth2 和 JWT 的区别吗燕双非OAuth2 更像授权协议JWT 是一种 token 格式。OAuth2 可以用 JWT 当 access token但它俩不是一回事。面试官行。现在说监控。你怎么判断订单服务是不是出现了“假死”或者接口抖动燕双非我会接 Prometheus 和 Grafana看 QPS、延迟、错误率。再用 Micrometer 打自定义埋点比如下单耗时、MQ 消费耗时。要是链路长的话再接 Zipkin 或 Jaeger 看调用链。面试官不错至少知道指标和链路要一起看。那如果某个下游配送服务很慢你会怎么做降级燕双非用 Resilience4j 做熔断和限流吧比如超时后直接返回“正在派单中”先保住主流程。面试官好第二轮比第一轮更像样了。第三轮云原生、AI 能力与系统演进面试官现在公司要做 AI 客服自动回答用户“为什么订单还没送到”。你会怎么把 Spring AI、RAG 和企业知识库结合进来燕双非呃……我理解是先把规则、FAQ、订单政策这些文档做向量化放到向量数据库里。用户提问后先做语义检索再把检索结果喂给大模型生成回答。Spring AI 负责把模型、向量库、工具调用这些串起来。面试官继续说为什么不能直接让大模型自由回答燕双非因为会有幻觉AI 可能瞎编。尤其客服场景不能乱说所以要让它基于企业文档问答必要时做 Agentic RAG让它按工具执行标准化流程去查订单状态。面试官那工具调用标准化怎么理解燕双非就是把查订单、查物流、查退款这些能力封装成统一工具接口模型只负责决定用哪个工具不直接碰数据库。这样扩展能力会更强也方便做复杂工作流。面试官如果这个 AI 客服服务要部署到 Kubernetes 上你会怎么做弹性和配置管理燕双非我会把服务做成无状态多副本部署用 ConfigMap 和 Secret 管配置。结合 HPA 根据 CPU、QPS 或自定义指标扩缩容。日志输出到标准输出统一进 ELK。面试官最后一个问题如果这套系统后面要支持 WebSocket 实时推送“骑手已接单”“预计 5 分钟送达”你怎么设计燕双非WebSocket 建长连接服务端收到配送状态变更后推给前端。消息源还是可以来自 Kafka前端订阅订单房间。要是横向扩容就得考虑会话共享或者用 Redis 做连接状态协调。面试官嗯今天就到这里吧。你先回去等通知。面试问题详细解答1. Spring Boot 订单状态流转如何设计在本地生活订单场景中订单状态通常包括已创建、商家已接单、骑手已接单、配送中、已完成、已取消。核心设计要点是状态机思维每个状态只能向允许的下游状态流转避免越级更新。实现上通常采用 Spring Boot 作为基础服务框架接口层接收下单、接单、取消等请求持久层使用 MyBatis 或 JPA 管理订单表。为了防止并发下状态覆盖可以增加乐观锁 version 字段更新时带上 version 条件更新失败则提示重试或进入补偿流程。业务上要结合消息队列。例如订单创建后发送 Kafka 消息给商家通知系统订单超时未接单时通过延迟消息、死信队列或 Redis 过期机制触发自动取消。这样可以把同步主流程和异步通知解耦。2. MyBatis 与 JPA 怎么选订单、履约、结算这类业务往往查询复杂、报表多、联表多MyBatis 更容易精准控制 SQL性能和可维护性更可控。JPA 更适合标准 CRUD、领域对象风格较强的场景但复杂 SQL 可读性和调优成本往往更高。实际项目中常见策略是核心交易链路使用 MyBatis简单配置表、字典表使用 JPA 或 Spring Data JDBC。3. Redis 缓存如何使用怎样处理一致性适合缓存的通常是商家信息、商品详情、活动配置、热点城市配送规则等读多写少的数据。不适合随意缓存的是支付状态、库存扣减、退款结果等强一致数据。数据库与缓存双写时最常见方案是先更新数据库再删除缓存。这样即使缓存短暂失效下次读取也会回源数据库。对于高并发热点数据还需要考虑缓存击穿、穿透、雪崩问题可通过空值缓存、互斥锁、随机过期时间等方式缓解。4. Spring Security、JWT、OAuth2 的关系是什么OAuth2 是授权协议JWT 是一种 token 表示格式。OAuth2 可以使用 JWT 作为 access token但二者不是同一个概念。在商家后台中Spring Security 负责认证和授权JWT 负责携带用户身份、角色、店铺 ID 等信息。接口处理时需要校验 token 的有效性并结合资源维度做二次鉴权例如确认 token 中的 shopId 与请求参数中的 shopId 一致防止越权访问。5. 如何做可观测性一个成熟的 Java 服务应同时具备指标、日志、链路三类观测能力。Prometheus 负责采集指标Grafana 负责展示Micrometer 负责在应用中埋点采集 QPS、耗时、错误率、MQ 消费堆积等指标Zipkin 或 Jaeger 负责分布式链路追踪帮助定位慢调用或超时问题。日志方面可用 SLF4J 统一门面底层结合 Logback 或 Log4j2输出结构化日志便于进入 ELK 做检索与分析。6. 如何使用 Resilience4j 做限流、熔断和降级在本地生活平台中配送、支付、地图等下游服务都可能出现抖动。Resilience4j 可用于超时控制避免线程长时间等待。熔断当失败率过高时快速失败保护主服务。限流在活动高峰时保护系统不过载。降级下游不可用时返回兜底结果例如“订单已受理请稍后查看”。其核心目的是让系统在局部故障下保持整体可用。7. AI 客服为什么要用 RAG而不是直接问大模型直接问大模型容易产生幻觉也就是模型基于统计规律“编”答案无法保证与企业真实规则一致。RAG 的思路是先检索再生成先把企业文档、订单规则、退款政策、物流说明等内容向量化存入 Milvus、Chroma 或 Redis 向量索引用户提问时先做语义检索再把相关文档片段作为上下文交给大模型生成答案。这样可以显著提升回答的准确性和可追溯性尤其适用于企业文档问答、智能客服、知识库检索。8. 什么是 Agentic RAG什么是工具调用标准化Agentic RAG 不只是“检索 生成”而是让 Agent 根据任务目标主动决定是否检索、是否调用工具、是否多轮推理。例如用户问“我的订单为什么没到”系统可以先查订单状态再查配送轨迹再结合知识库解释原因。工具调用标准化则是把查订单、查物流、查退款、查会员权益等能力封装成统一接口让模型以统一协议调用。这样便于扩展、审计和权限控制也能避免模型直接访问底层数据库。9. Kubernetes 上如何部署无状态 Java 服务常见做法是把服务容器化配置多副本部署尽量无状态。配置通过 ConfigMap 和 Secret 注入日志写到 stdout/stderr由采集系统统一收集。弹性扩缩容通常结合 HPA根据 CPU、内存、QPS 或自定义指标自动扩容。若服务有 WebSocket 连接可进一步考虑会话粘性、共享连接状态或消息总线协调。10. WebSocket 在实时配送通知中怎么用WebSocket 适合建立前后端的长连接用于实时推送订单状态变化。后端可从 Kafka 订阅配送状态事件处理后推送给前端。横向扩展时如果连接分散在多个实例上需要借助 Redis、消息总线或网关层来协调会话和广播避免消息丢失或重复推送。感谢阅读希望这篇文章能帮助大家在 Java 面试中更好地理解业务场景与技术选型少背题多建立系统化思维祝大家都能顺利拿到心仪的 offer。