互联网大厂 Java 面试实录Spring Boot Kafka Redis RAG 的三轮连环追问场景某互联网大厂的 Java 岗位面试现场候选人是号称“做过很多项目”的水货程序员燕双非。面试官表情严肃问题层层递进从基础架构、业务落地到云原生与 AI 方案一路把“会一点”和“懂很多”区分开来。第一轮用户增长与内容推荐系统面试官我们做的是一个内容社区 App首页要支持高并发 feed 流。你先说说为什么这个场景通常会用 Spring Boot而不是传统的 Spring MVC 配一堆 XML燕双非Spring Boot 启动快少配点 XML大家都比较开心开发效率会高一点。面试官回答得还行。那如果首页接口需要按用户维度动态推荐你会怎么设计缓存和数据库访问燕双非我会先用 Redis 缓存热点用户的推荐结果数据库层面再用 MyBatis 查一下不行就再查一遍应该就差不多了。面试官你说到了 Redis 和 MyBatis但“再查一遍”不是设计。那如果缓存击穿、雪崩同时发生呢燕双非呃……可以加锁、设过期时间随机一点再做个降级别让接口一下子全挂了。面试官至少知道方向。最后一个问题这种 feed 流更新如果要做异步通知你会考虑 Kafka 还是 RabbitMQ为什么燕双非我会优先 Kafka因为消息吞吐高适合用户行为流、埋点和推荐数据同步。RabbitMQ 更像适合一些需要复杂路由、低吞吐但业务控制精细的场景。面试官这个判断比较靠谱继续保持。第二轮交易链路与风控校验面试官现在切换到电商下单场景。用户提交订单后要做库存扣减、优惠券校验、支付预创建。你会怎么保证接口的幂等性燕双非可以用订单号做唯一键再加个 Redis 标记重复请求直接拦住。面试官可以说明你至少知道幂等入口控制。那如果要把订单写库、扣库存、发 MQ 消息串起来怎么避免部分成功部分失败燕双非嗯……我觉得可以先都成功再返回失败就重试不行就人工处理。面试官这回答不太能上线。你再考虑一下事务边界、消息最终一致性和补偿机制。燕双非哦我可能会用本地事务配合消息表先落库再投递消息或者用 Outbox 思路保证消息不丢。库存和支付这类链路还要考虑幂等消费、重试和补偿。面试官这就像个做过事的人了。那如果支付链路要接 Spring Security JWT你怎么设计登录态和 token 刷新燕双非前端拿 access token 调接口refresh token 放得更安全一些access token 短一点过期后通过 refresh token 换新。后端要校验签名、过期时间和黑名单。面试官不错。最后一个追问风控规则如果要实时更新你会怎么让系统不重启就生效燕双非可以把规则放配置中心或者数据库配合定时刷新更实时一点可以接消息通知规则变更后推送到各个服务实例。面试官思路清晰继续。第三轮云原生、AI 与企业级协同面试官现在我们做企业协同 SaaS客户希望接入智能客服和知识问答。你如何把 Spring AI、RAG 和企业文档结合起来燕双非先把文档切块做向量化存到向量数据库里。用户提问时先语义检索再把检索到的内容拼到提示词里让大模型基于上下文回答。面试官不错你提到了检索增强生成。那如果企业文档经常更新怎么保证回答不过时燕双非要做增量索引更新文档加载流程要能识别新增、修改和删除。向量库里的旧内容要及时清理不然就会答错。面试官好。那如果系统接了多个工具比如查工单、查订单、创建审批单你如何理解 MCP 或工具调用标准化燕双非我理解它就是把工具能力统一成标准接口让模型知道什么时候调用什么工具返回格式也统一这样扩展起来更方便。面试官对能把“会调用”提升到“可治理”就不错了。最后一个问题服务端要做高并发长连接通知比如 WebSocket 推送你会关注什么燕双非我会关注连接数、心跳、消息堆积、断线重连还有多实例部署时会不会把消息发错机器。必要时可以结合 Redis Pub/Sub 或 MQ 做消息广播。面试官说得不错。今天就到这里吧你回去等通知。问题详解1. 为什么内容社区首页常用 Spring Boot在内容社区、UGC、推荐流场景中业务迭代快、接口多、微服务多。Spring Boot 的优势是自动配置、约定优于配置、内嵌容器和成熟生态可以快速搭建服务并减少样板代码。相比传统 Spring MVC 大量 XML 配置Boot 更适合快速交付和持续演进。2. Redis 缓存、MyBatis 与高并发推荐流推荐结果通常具有明显热点适合使用 Redis 缓存用户维度数据。数据库层面可用 MyBatis 处理复杂 SQL。实际设计中要考虑缓存击穿、雪崩、穿透热点 Key 可加互斥锁或逻辑过期缓存过期时间加随机值空值缓存或布隆过滤器可减少穿透风险。3. Kafka 与 RabbitMQ 的选择Kafka 更适合大吞吐、顺序日志、埋点、行为流和异步解耦RabbitMQ 更适合复杂路由、延迟任务和业务控制精细的场景。内容社区的行为流、推荐特征更新、日志采集通常更偏 Kafka。4. 订单幂等、事务与最终一致性电商下单链路中用户可能重复点击、网络重试、消息重复投递因此幂等是核心。常见做法包括业务唯一键、Redis 去重、数据库唯一约束、幂等表。跨服务协作时不能依赖单体事务通常采用本地事务 消息表、Outbox、可靠消息最终一致性、补偿任务等方案。5. Spring Security JWT 的登录态设计access token 用于短期访问接口refresh token 用于续期二者职责不同。access token 过期时间短可降低泄漏风险refresh token 可放在更安全的位置并支持黑名单失效。服务端要校验签名、过期时间、issuer、audience并处理踢下线与注销场景。6. 风控规则动态生效风控规则不应依赖重启。常见方案是配置中心 本地缓存刷新或者数据库存储规则后通过消息通知各节点更新。更复杂场景可使用规则引擎支持灰度发布、版本管理和回滚。7. Spring AI、RAG 与企业文档问答RAG 的核心是“先检索再生成”。企业文档先进行加载、清洗、切块、Embedding 向量化存入向量数据库。查询时进行语义检索把最相关的内容拼进上下文再让大模型生成答案。这样可以减少幻觉提高答案可追溯性。8. 文档更新与索引维护企业知识库不是静态的。必须支持增量更新、删除和版本控制否则检索到旧文档会造成错误回答。实际系统中需要文档同步任务、变更事件、索引重建策略以及检索结果时间戳或版本控制。9. MCP 与工具调用标准化MCP 可以理解为让模型与外部工具之间拥有统一协议。它的价值不只是“能调工具”更在于可治理、可扩展、可审计。企业里常见的工单、审批、订单、知识库查询都可以通过标准化工具接口接入 Agent 流程。10. WebSocket 与实时推送WebSocket 适合长连接和低延迟通知但要关注连接管理、心跳保活、断线重连、消息顺序、多实例广播和背压问题。若部署多个实例通常需要借助 Redis Pub/Sub、Kafka 或网关层做消息分发避免只推到本机连接。感谢阅读希望这篇文章能帮助大家更好地准备 Java 面试理解真实业务场景中的技术选择与落地方式祝大家面试顺利早日拿到心仪 offer。 
长河君 · 2026/8/22 8:59:17 · 阅读 1.2k 互联网大厂 Java 面试实录：Spring Boot + Kafka + Redis + RAG 的三轮连环追问
互联网大厂 Java 面试实录Spring Boot Kafka Redis RAG 的三轮连环追问场景某互联网大厂的 Java 岗位面试现场候选人是号称“做过很多项目”的水货程序员燕双非。面试官表情严肃问题层层递进从基础架构、业务落地到云原生与 AI 方案一路把“会一点”和“懂很多”区分开来。第一轮用户增长与内容推荐系统面试官我们做的是一个内容社区 App首页要支持高并发 feed 流。你先说说为什么这个场景通常会用 Spring Boot而不是传统的 Spring MVC 配一堆 XML燕双非Spring Boot 启动快少配点 XML大家都比较开心开发效率会高一点。面试官回答得还行。那如果首页接口需要按用户维度动态推荐你会怎么设计缓存和数据库访问燕双非我会先用 Redis 缓存热点用户的推荐结果数据库层面再用 MyBatis 查一下不行就再查一遍应该就差不多了。面试官你说到了 Redis 和 MyBatis但“再查一遍”不是设计。那如果缓存击穿、雪崩同时发生呢燕双非呃……可以加锁、设过期时间随机一点再做个降级别让接口一下子全挂了。面试官至少知道方向。最后一个问题这种 feed 流更新如果要做异步通知你会考虑 Kafka 还是 RabbitMQ为什么燕双非我会优先 Kafka因为消息吞吐高适合用户行为流、埋点和推荐数据同步。RabbitMQ 更像适合一些需要复杂路由、低吞吐但业务控制精细的场景。面试官这个判断比较靠谱继续保持。第二轮交易链路与风控校验面试官现在切换到电商下单场景。用户提交订单后要做库存扣减、优惠券校验、支付预创建。你会怎么保证接口的幂等性燕双非可以用订单号做唯一键再加个 Redis 标记重复请求直接拦住。面试官可以说明你至少知道幂等入口控制。那如果要把订单写库、扣库存、发 MQ 消息串起来怎么避免部分成功部分失败燕双非嗯……我觉得可以先都成功再返回失败就重试不行就人工处理。面试官这回答不太能上线。你再考虑一下事务边界、消息最终一致性和补偿机制。燕双非哦我可能会用本地事务配合消息表先落库再投递消息或者用 Outbox 思路保证消息不丢。库存和支付这类链路还要考虑幂等消费、重试和补偿。面试官这就像个做过事的人了。那如果支付链路要接 Spring Security JWT你怎么设计登录态和 token 刷新燕双非前端拿 access token 调接口refresh token 放得更安全一些access token 短一点过期后通过 refresh token 换新。后端要校验签名、过期时间和黑名单。面试官不错。最后一个追问风控规则如果要实时更新你会怎么让系统不重启就生效燕双非可以把规则放配置中心或者数据库配合定时刷新更实时一点可以接消息通知规则变更后推送到各个服务实例。面试官思路清晰继续。第三轮云原生、AI 与企业级协同面试官现在我们做企业协同 SaaS客户希望接入智能客服和知识问答。你如何把 Spring AI、RAG 和企业文档结合起来燕双非先把文档切块做向量化存到向量数据库里。用户提问时先语义检索再把检索到的内容拼到提示词里让大模型基于上下文回答。面试官不错你提到了检索增强生成。那如果企业文档经常更新怎么保证回答不过时燕双非要做增量索引更新文档加载流程要能识别新增、修改和删除。向量库里的旧内容要及时清理不然就会答错。面试官好。那如果系统接了多个工具比如查工单、查订单、创建审批单你如何理解 MCP 或工具调用标准化燕双非我理解它就是把工具能力统一成标准接口让模型知道什么时候调用什么工具返回格式也统一这样扩展起来更方便。面试官对能把“会调用”提升到“可治理”就不错了。最后一个问题服务端要做高并发长连接通知比如 WebSocket 推送你会关注什么燕双非我会关注连接数、心跳、消息堆积、断线重连还有多实例部署时会不会把消息发错机器。必要时可以结合 Redis Pub/Sub 或 MQ 做消息广播。面试官说得不错。今天就到这里吧你回去等通知。问题详解1. 为什么内容社区首页常用 Spring Boot在内容社区、UGC、推荐流场景中业务迭代快、接口多、微服务多。Spring Boot 的优势是自动配置、约定优于配置、内嵌容器和成熟生态可以快速搭建服务并减少样板代码。相比传统 Spring MVC 大量 XML 配置Boot 更适合快速交付和持续演进。2. Redis 缓存、MyBatis 与高并发推荐流推荐结果通常具有明显热点适合使用 Redis 缓存用户维度数据。数据库层面可用 MyBatis 处理复杂 SQL。实际设计中要考虑缓存击穿、雪崩、穿透热点 Key 可加互斥锁或逻辑过期缓存过期时间加随机值空值缓存或布隆过滤器可减少穿透风险。3. Kafka 与 RabbitMQ 的选择Kafka 更适合大吞吐、顺序日志、埋点、行为流和异步解耦RabbitMQ 更适合复杂路由、延迟任务和业务控制精细的场景。内容社区的行为流、推荐特征更新、日志采集通常更偏 Kafka。4. 订单幂等、事务与最终一致性电商下单链路中用户可能重复点击、网络重试、消息重复投递因此幂等是核心。常见做法包括业务唯一键、Redis 去重、数据库唯一约束、幂等表。跨服务协作时不能依赖单体事务通常采用本地事务 消息表、Outbox、可靠消息最终一致性、补偿任务等方案。5. Spring Security JWT 的登录态设计access token 用于短期访问接口refresh token 用于续期二者职责不同。access token 过期时间短可降低泄漏风险refresh token 可放在更安全的位置并支持黑名单失效。服务端要校验签名、过期时间、issuer、audience并处理踢下线与注销场景。6. 风控规则动态生效风控规则不应依赖重启。常见方案是配置中心 本地缓存刷新或者数据库存储规则后通过消息通知各节点更新。更复杂场景可使用规则引擎支持灰度发布、版本管理和回滚。7. Spring AI、RAG 与企业文档问答RAG 的核心是“先检索再生成”。企业文档先进行加载、清洗、切块、Embedding 向量化存入向量数据库。查询时进行语义检索把最相关的内容拼进上下文再让大模型生成答案。这样可以减少幻觉提高答案可追溯性。8. 文档更新与索引维护企业知识库不是静态的。必须支持增量更新、删除和版本控制否则检索到旧文档会造成错误回答。实际系统中需要文档同步任务、变更事件、索引重建策略以及检索结果时间戳或版本控制。9. MCP 与工具调用标准化MCP 可以理解为让模型与外部工具之间拥有统一协议。它的价值不只是“能调工具”更在于可治理、可扩展、可审计。企业里常见的工单、审批、订单、知识库查询都可以通过标准化工具接口接入 Agent 流程。10. WebSocket 与实时推送WebSocket 适合长连接和低延迟通知但要关注连接管理、心跳保活、断线重连、消息顺序、多实例广播和背压问题。若部署多个实例通常需要借助 Redis Pub/Sub、Kafka 或网关层做消息分发避免只推到本机连接。感谢阅读希望这篇文章能帮助大家更好地准备 Java 面试理解真实业务场景中的技术选择与落地方式祝大家面试顺利早日拿到心仪 offer。