互联网大厂 Java 面试实录Spring Boot、Kafka、Redis、JWT 与 Spring AI 场景深挖场景某互联网大厂电商与广告中台团队 Java 面试。面试官严肃克制候选人是外号“水货程序员”的燕双非嘴上常飘但偶尔真能答上来。第一轮订单下单链路与缓存设计面试官我们做的是电商秒杀活动用户下单后要快速响应。你先说说为什么这里更适合用Spring Boot而不是传统的 Spring MVC 组合配置燕双非Spring Boot 开箱即用嘛少写很多 XML 配置内嵌 Tomcat启动快适合快速搭建秒杀接口。面试官嗯基础还可以。那如果下单接口要防止重复提交你会怎么设计燕双非我会先在前端按钮置灰再在后端加个幂等校验比如用 Redis 存一个请求唯一标识处理成功后删掉或者设置短 TTL。面试官思路对。那幂等 token 放 Redis 时如何保证高并发下的原子性燕双非可以用 Lua 脚本做校验和删除保证“查和删”在一个原子操作里完成不然并发下容易重复下单。面试官可以说明你知道 Redis 的原子性边界。那库存扣减如果也走 Redis你会怎么避免超卖燕双非嗯……可以先预减库存然后异步落库。超卖的话……应该可以用分布式锁吧不过具体锁粒度要看场景。面试官分布式锁不是不能用但秒杀场景更要关注吞吐。这个你回去再细化一下。第二轮消息驱动、链路追踪与风控面试官如果下单成功后要同步发放优惠券、积分、短信通知你怎么做燕双非我会把下单结果发到Kafka然后优惠券、积分、短信各自订阅不同 topic 或同一个 topic 的不同消费者组解耦嘛。面试官不错知道用消息队列解耦。那你怎么处理“订单已成功但消息没发出去”或者“消息重复投递”的问题燕双非这个……可以用本地事务加消息表或者事务消息。消费端再做幂等比如订单号去重。面试官答到点子上了。那如果我们还要把下单接口暴露给外部合作方鉴权你会怎么做燕双非可以用JWT做无状态认证网关验签后把用户身份透传给下游如果是企业内部统一登录也可以接OAuth2或 Keycloak。面试官嗯方向对。那 JWT 里放太多信息有什么问题燕双非token 会变大传输成本高而且一旦签发后不好撤销所以一般只放必要的用户标识和权限摘要。面试官可以。最后问你一个链路治理问题怎么观察这条下单链路的耗时分布燕双非用Micrometer打点再接 Prometheus 和 Grafana 看指标链路追踪可以配 Jaeger 或 Zipkin。面试官很好已经不是完全水货了。第三轮营销推荐、AI 运营助手与系统扩展面试官现在我们做广告与营销场景运营希望自动生成商品文案并结合用户画像做推荐。你会怎么设计一个 AI 辅助系统燕双非可以基于Spring AI接大模型配合 RAG把商品详情、活动规则、用户问答文档做向量化后放到向量数据库里比如 Milvus 或 Redis Vector。面试官继续讲为什么要做 RAG而不是直接让模型回答燕双非因为直接问模型容易幻觉也就是瞎编。RAG 可以先检索企业知识再把相关内容喂给模型减少胡说八道。面试官不错。那如果要让 AI 助手还能调用“查库存”“查订单”“创建工单”这些能力你怎么设计工具调用燕双非要做工具调用标准化让模型通过统一协议去调用外部 API。嗯……像 MCP 这种模型上下文协议就挺适合把工具、资源、提示词能力都抽象出来。面试官那 Agent 和普通问答有什么区别燕双非Agent 更像一个会规划步骤的执行体不只是回答问题它会自己决定先检索、再调用工具、再总结结果。比如智能客服里先判断用户意图再查订单再生成回复。面试官如果你要保证这个 AI 客服既能回答又不乱说怎么控制燕双非一方面限制工具范围另一方面做提示词约束和上下文记忆控制对高风险问题必须转人工避免幻觉引发误导。面试官行今天先到这里。你回家等通知吧。问题详解与知识梳理1. 为什么电商秒杀场景常用 Spring BootSpring Boot 的优势在于快速集成、自动配置和嵌入式容器适合高频迭代的业务系统。电商秒杀通常需要快速上线、灵活扩展和简单部署Boot 能显著降低配置成本。配合 Spring MVC 可以方便实现 REST 接口、参数校验、统一异常处理等能力。2. Redis 幂等与原子性秒杀、支付、下单等场景都要求接口幂等。常见做法是为每次请求生成 token存入 Redis并设置过期时间。请求到达后用 Lua 脚本完成“校验 token 是否存在 删除 token”的原子操作避免并发重复提交。若只是先查再删会有竞态条件。3. 库存扣减与超卖控制高并发秒杀中库存扣减通常采用“Redis 预扣减 异步落库”的模式。Redis 负责快速拦截超卖数据库负责最终一致性。若使用数据库直接扣减虽然一致性更强但性能容易成为瓶颈。分布式锁可以用但需要谨慎评估吞吐与热点问题。4. Kafka 在订单链路中的作用Kafka 适合高吞吐、可扩展的消息场景。订单创建后系统可以将事件写入 Kafka由优惠券、积分、短信、风控等下游系统异步消费实现服务解耦和削峰填谷。面试中常追问消息重复、消息丢失、顺序性与最终一致性这些都要结合业务做设计。5. 消息可靠性与幂等消费“本地事务 消息表”“事务消息”“Outbox 模式”都是常见可靠消息方案。消费端幂等则通常依赖业务唯一键如订单号、流水号、消息 ID 去重避免重复消费导致重复发券、重复加积分。6. JWT、OAuth2 与 KeycloakJWT 常用于无状态认证适合网关鉴权和微服务间身份透传。它的优点是无需服务端存储会话但缺点是难以主动撤销且 token 过大时会增加传输开销。OAuth2 更偏授权框架适合第三方登录和统一认证Keycloak 则是成熟的身份认证与授权平台。7. Micrometer、Prometheus、Grafana、JaegerMicrometer 是 Java 生态的指标采集门面便于向 Prometheus 导出计数器、计时器、分布式摘要等指标。Prometheus 负责抓取和存储指标Grafana 负责可视化。Jaeger 或 Zipkin 则用于链路追踪帮助定位下单慢、远程调用慢、数据库慢等问题。8. Spring AI、RAG 与向量数据库在营销文案生成、智能客服、企业知识问答中直接让大模型回答容易出现幻觉。RAG 的核心是“先检索再生成”将企业知识切分、向量化后写入向量数据库在用户提问时先做语义检索再把检索结果作为上下文输入模型从而提升回答准确度。Milvus、Chroma、Redis 向量能力都可作为存储选择。9. Agent、工具调用与 MCPAgent 不只是聊天它具备规划、调用工具、迭代执行的能力。比如智能客服 Agent 可能先判断意图再调用订单查询、物流查询、工单创建接口最后整合结果输出。MCP 这类协议的价值在于统一工具、资源和上下文的接入方式让模型具备更强的扩展能力与可治理性。10. 如何控制 AI 幻觉可以通过检索增强、提示词约束、工具白名单、权限控制、置信度阈值和人工兜底来降低幻觉风险。对于电商售后、支付风控等高风险场景AI 只能做辅助关键结论必须经过规则或人工确认。以上就是本次 Java 面试实录的完整内容。希望这篇文章能帮助你在大厂面试中更好地串联业务场景与技术方案把知识点真正讲清楚、讲透彻。感谢阅读也希望能实实在在帮到大家。 互联网大厂 Java 面试实录：Spring Boot、Kafka、Redis、JWT 与 Spring AI 场景深挖
互联网大厂 Java 面试实录Spring Boot、Kafka、Redis、JWT 与 Spring AI 场景深挖场景某互联网大厂电商与广告中台团队 Java 面试。面试官严肃克制候选人是外号“水货程序员”的燕双非嘴上常飘但偶尔真能答上来。第一轮订单下单链路与缓存设计面试官我们做的是电商秒杀活动用户下单后要快速响应。你先说说为什么这里更适合用Spring Boot而不是传统的 Spring MVC 组合配置燕双非Spring Boot 开箱即用嘛少写很多 XML 配置内嵌 Tomcat启动快适合快速搭建秒杀接口。面试官嗯基础还可以。那如果下单接口要防止重复提交你会怎么设计燕双非我会先在前端按钮置灰再在后端加个幂等校验比如用 Redis 存一个请求唯一标识处理成功后删掉或者设置短 TTL。面试官思路对。那幂等 token 放 Redis 时如何保证高并发下的原子性燕双非可以用 Lua 脚本做校验和删除保证“查和删”在一个原子操作里完成不然并发下容易重复下单。面试官可以说明你知道 Redis 的原子性边界。那库存扣减如果也走 Redis你会怎么避免超卖燕双非嗯……可以先预减库存然后异步落库。超卖的话……应该可以用分布式锁吧不过具体锁粒度要看场景。面试官分布式锁不是不能用但秒杀场景更要关注吞吐。这个你回去再细化一下。第二轮消息驱动、链路追踪与风控面试官如果下单成功后要同步发放优惠券、积分、短信通知你怎么做燕双非我会把下单结果发到Kafka然后优惠券、积分、短信各自订阅不同 topic 或同一个 topic 的不同消费者组解耦嘛。面试官不错知道用消息队列解耦。那你怎么处理“订单已成功但消息没发出去”或者“消息重复投递”的问题燕双非这个……可以用本地事务加消息表或者事务消息。消费端再做幂等比如订单号去重。面试官答到点子上了。那如果我们还要把下单接口暴露给外部合作方鉴权你会怎么做燕双非可以用JWT做无状态认证网关验签后把用户身份透传给下游如果是企业内部统一登录也可以接OAuth2或 Keycloak。面试官嗯方向对。那 JWT 里放太多信息有什么问题燕双非token 会变大传输成本高而且一旦签发后不好撤销所以一般只放必要的用户标识和权限摘要。面试官可以。最后问你一个链路治理问题怎么观察这条下单链路的耗时分布燕双非用Micrometer打点再接 Prometheus 和 Grafana 看指标链路追踪可以配 Jaeger 或 Zipkin。面试官很好已经不是完全水货了。第三轮营销推荐、AI 运营助手与系统扩展面试官现在我们做广告与营销场景运营希望自动生成商品文案并结合用户画像做推荐。你会怎么设计一个 AI 辅助系统燕双非可以基于Spring AI接大模型配合 RAG把商品详情、活动规则、用户问答文档做向量化后放到向量数据库里比如 Milvus 或 Redis Vector。面试官继续讲为什么要做 RAG而不是直接让模型回答燕双非因为直接问模型容易幻觉也就是瞎编。RAG 可以先检索企业知识再把相关内容喂给模型减少胡说八道。面试官不错。那如果要让 AI 助手还能调用“查库存”“查订单”“创建工单”这些能力你怎么设计工具调用燕双非要做工具调用标准化让模型通过统一协议去调用外部 API。嗯……像 MCP 这种模型上下文协议就挺适合把工具、资源、提示词能力都抽象出来。面试官那 Agent 和普通问答有什么区别燕双非Agent 更像一个会规划步骤的执行体不只是回答问题它会自己决定先检索、再调用工具、再总结结果。比如智能客服里先判断用户意图再查订单再生成回复。面试官如果你要保证这个 AI 客服既能回答又不乱说怎么控制燕双非一方面限制工具范围另一方面做提示词约束和上下文记忆控制对高风险问题必须转人工避免幻觉引发误导。面试官行今天先到这里。你回家等通知吧。问题详解与知识梳理1. 为什么电商秒杀场景常用 Spring BootSpring Boot 的优势在于快速集成、自动配置和嵌入式容器适合高频迭代的业务系统。电商秒杀通常需要快速上线、灵活扩展和简单部署Boot 能显著降低配置成本。配合 Spring MVC 可以方便实现 REST 接口、参数校验、统一异常处理等能力。2. Redis 幂等与原子性秒杀、支付、下单等场景都要求接口幂等。常见做法是为每次请求生成 token存入 Redis并设置过期时间。请求到达后用 Lua 脚本完成“校验 token 是否存在 删除 token”的原子操作避免并发重复提交。若只是先查再删会有竞态条件。3. 库存扣减与超卖控制高并发秒杀中库存扣减通常采用“Redis 预扣减 异步落库”的模式。Redis 负责快速拦截超卖数据库负责最终一致性。若使用数据库直接扣减虽然一致性更强但性能容易成为瓶颈。分布式锁可以用但需要谨慎评估吞吐与热点问题。4. Kafka 在订单链路中的作用Kafka 适合高吞吐、可扩展的消息场景。订单创建后系统可以将事件写入 Kafka由优惠券、积分、短信、风控等下游系统异步消费实现服务解耦和削峰填谷。面试中常追问消息重复、消息丢失、顺序性与最终一致性这些都要结合业务做设计。5. 消息可靠性与幂等消费“本地事务 消息表”“事务消息”“Outbox 模式”都是常见可靠消息方案。消费端幂等则通常依赖业务唯一键如订单号、流水号、消息 ID 去重避免重复消费导致重复发券、重复加积分。6. JWT、OAuth2 与 KeycloakJWT 常用于无状态认证适合网关鉴权和微服务间身份透传。它的优点是无需服务端存储会话但缺点是难以主动撤销且 token 过大时会增加传输开销。OAuth2 更偏授权框架适合第三方登录和统一认证Keycloak 则是成熟的身份认证与授权平台。7. Micrometer、Prometheus、Grafana、JaegerMicrometer 是 Java 生态的指标采集门面便于向 Prometheus 导出计数器、计时器、分布式摘要等指标。Prometheus 负责抓取和存储指标Grafana 负责可视化。Jaeger 或 Zipkin 则用于链路追踪帮助定位下单慢、远程调用慢、数据库慢等问题。8. Spring AI、RAG 与向量数据库在营销文案生成、智能客服、企业知识问答中直接让大模型回答容易出现幻觉。RAG 的核心是“先检索再生成”将企业知识切分、向量化后写入向量数据库在用户提问时先做语义检索再把检索结果作为上下文输入模型从而提升回答准确度。Milvus、Chroma、Redis 向量能力都可作为存储选择。9. Agent、工具调用与 MCPAgent 不只是聊天它具备规划、调用工具、迭代执行的能力。比如智能客服 Agent 可能先判断意图再调用订单查询、物流查询、工单创建接口最后整合结果输出。MCP 这类协议的价值在于统一工具、资源和上下文的接入方式让模型具备更强的扩展能力与可治理性。10. 如何控制 AI 幻觉可以通过检索增强、提示词约束、工具白名单、权限控制、置信度阈值和人工兜底来降低幻觉风险。对于电商售后、支付风控等高风险场景AI 只能做辅助关键结论必须经过规则或人工确认。以上就是本次 Java 面试实录的完整内容。希望这篇文章能帮助你在大厂面试中更好地串联业务场景与技术方案把知识点真正讲清楚、讲透彻。感谢阅读也希望能实实在在帮到大家。