Java 求职面试实录：Spring Boot + Kafka + Redis + RAG 场景下的互联网大厂三轮攻防
场景设定：电商与 AIGC 结合的增长型业务
面试官：我们今天聊的是一个互联网大厂的核心业务场景：电商平台接入 AIGC 能力后，用户可以通过自然语言搜索商品、生成购物清单、查看智能客服回答，还能在大促期间承受高并发流量。你来扮演负责后端的 Java 候选人。
候选人：我先声明一下，我是燕双非，双非不双飞，能飞的只有我上线前的心。
第一轮：基础能力与服务启动
问题 1：你先说说 Spring Boot 相比 Spring MVC 手工配置项目，最大的价值是什么？
燕双非：最明显就是省事，少写很多 XML 和配置类。Spring Boot 能自动装配，Starter 也方便，起项目快，适合微服务和快速迭代。
面试官：回答得还行，至少知道“省事”背后是自动装配和约定大于配置。那你继续说，自动装配是怎么生效的？
问题 2：Spring Boot 启动时，自动装配和条件化 Bean 的核心机制是什么？
燕双非：大概是通过一些注解和配置文件来判断哪些类要加载，像是根据类路径里有没有某个依赖，再决定要不要创建 Bean。具体细节我有点模糊，但感觉就是“有条件地懒加载”。
面试官：嗯，方向对了，但“懒加载”不是核心关键词。继续。
问题 3：在这个电商场景里，如果首页推荐接口 200ms 内要返回，而你担心数据库压力太大，你会先怎么设计？
燕双非：我会先加缓存，比如 Redis，把热门商品、首页 Banner、推荐位数据先缓存起来。再加本地缓存，减少重复查库。如果是读多写少的场景，这样很划算。
面试官：这个回答就比较像样了，知道先从缓存和读写模式入手。那如果缓存和数据库不一致怎么办？
问题 4：你怎么处理 Redis 缓存与 MySQL 数据一致性问题？
燕双非：我一般会先考虑先更新数据库再删除缓存，或者延迟双删。因为直接先删缓存再更新数据库，可能有并发读写导致脏数据回填。
面试官：不错，至少知道“先写库再删缓存”和延迟双删的思路。这个问题过关。
第二轮：消息驱动、风控与高并发
问题 1：大促期间，用户下单后要同步发券、发短信、推荐系统埋点、库存扣减，你会怎么拆分这条链路？
燕双非：我会把主链路和异步链路分开。下单成功先返回给用户，再通过 Kafka 发事件，券、短信、埋点这些消费端各自处理，这样解耦，也能削峰。
面试官：很好，这就是事件驱动架构的基本思路。那你说说为什么更偏向 Kafka，而不是直接同步调用？
问题 2：Kafka 在订单场景里，如何保证消息不丢、不过度重复消费？
燕双非：不丢的话我知道生产端要确认，消费端要手动提交 offset。重复消费嘛……一般做幂等，像订单号做唯一键，或者消费表做去重。消息“至少一次”我听过，但细节我讲不太清。
面试官：能说到幂等已经不错了，不过“至少一次”是 Kafka 里非常关键的语义。继续看风控。
问题 3：如果你的支付链路要接 JWT 和 Spring Security，怎么做登录态和接口权限控制？
燕双非：用户登录后签发 JWT，前端带着 token 请求接口，后端通过过滤器解析 token，再把用户信息放到上下文里。Spring Security 主要负责权限拦截，像角色、资源权限这些都能配置。
面试官：这题答得挺标准。那如果 token 失效、被盗，怎么处理？
问题 4：JWT 一旦签发出去，如何做退出登录和黑名单控制？
燕双非：因为 JWT 天生无状态，所以一般会配合 Redis 存 token 黑名单，或者给 token 设置较短过期时间，再配刷新 token 机制。退出登录时把 jti 加入黑名单，校验时额外判断。
面试官：可以，知道无状态的代价，也知道补救方案。
第三轮：AIGC、RAG 与系统扩展
问题 1：现在业务要求“智能客服”支持商品知识、售后政策和活动规则问答，你会如何设计一个企业文档问答系统？
燕双非：我会做 RAG。先把文档加载进来，切分后向量化，存到向量数据库，比如 Milvus。用户提问后先做语义检索，找到相关片段，再把上下文拼给大模型生成答案。
面试官：很好，这已经不是背概念了，基本碰到业务了。那你说说为什么不能直接把所有文档都塞进 prompt？
问题 2：RAG 相比纯 Prompt 方案，主要解决了什么问题？
燕双非：主要是上下文长度不够，还有知识更新慢。把知识放到检索层里，能降低成本，也能让答案更贴近企业内部资料。否则模型容易胡说八道，幻觉比较严重。
面试官：不错，知道幻觉问题。那如果业务要求“回答必须可追溯”，你会怎么做？
问题 3：如何降低 AI 幻觉并增强答案可信度？
燕双非：我会加检索结果引用、答案置信度阈值、敏感问题转人工，还会做提示填充约束模型只能基于资料回答。对于高风险问答，可以引入工具调用标准化，先查内部系统再生成。
面试官：这题回答得不错，能把 RAG、工具调用和风控串起来。最后一个问题。
问题 4：如果这个智能客服要支持会话记忆、多轮追问、以及复杂工作流，比如“查订单—查物流—给出补偿建议”，你会怎么演进架构？
燕双非：我会把聊天会话内存、工具执行框架和 Agent 结合起来。短期记忆记录上下文，Agent 根据用户意图决定调用订单服务、物流服务、客服工单服务。复杂工作流可以拆成多步编排，必要时人机协同。
面试官：回答到这里，思路已经有了，虽然有些地方还不够细，但方向是对的。
面试官总结
面试官：今天聊得差不多了。你对 Spring Boot、Redis、Kafka、JWT、RAG 这些核心点有一定理解，也能在业务场景里说出大致方案。不过有些地方还不够深入，尤其是自动装配细节、消息一致性、RAG 工程化落地方面还需要继续加强。你先回家等通知吧。
问题详解与业务场景拆解
1. Spring Boot 的价值与自动装配
在电商或内容平台中，系统通常由多个服务组成，启动效率和统一配置非常重要。Spring Boot 的核心价值是通过 Starter、自动装配和约定大于配置，显著降低项目搭建成本。自动装配本质上依赖条件化装配机制，结合类路径、属性、Bean 是否存在等条件决定是否创建 Bean。业务上，这让你可以快速接入 Redis、Kafka、Security、MyBatis 等组件。
2. 缓存与一致性
首页推荐、商品详情、活动配置、客服知识库等都很适合缓存。常见策略是先更新数据库，再删除缓存，必要时使用延迟双删缓解并发读写问题。对于极热数据，可以结合本地缓存和 Redis 多级缓存，减少数据库压力。业务中要特别注意缓存穿透、击穿和雪崩。
3. Kafka 在订单与事件驱动中的作用
Kafka 适合高吞吐、可扩展、可削峰的消息场景。订单下单后触发发券、积分、埋点、风控等动作时，主链路只负责核心交易，其余动作通过事件异步完成。为了保证消息处理稳定，生产端要关注确认机制，消费端要做好幂等、重试和死信处理。幂等通常可通过业务唯一键、去重表、状态机控制实现。
4. JWT 与 Spring Security
在登录态管理中，JWT 适合前后端分离和多端访问场景。Spring Security 负责认证与授权，JWT 负责承载身份信息。退出登录、强制下线、token 失效补救等问题，需要通过黑名单、短过期时间、刷新 token 机制来配合解决。对金融、支付类接口，还应叠加细粒度权限校验和二次验证。
5. RAG 与企业文档问答
企业文档问答系统常见于智能客服、知识助手、售后支持和内部问答。RAG 的关键流程是文档加载、切分、向量化、向量检索、上下文拼接、生成回答。向量数据库可以选择 Milvus、Chroma 或 Redis 向量能力。相比直接把文档塞进 Prompt，RAG 更能控制成本、提高可更新性，并降低幻觉风险。进一步可以加入引用来源、置信度判断、人工兜底和工具调用，使答案更可靠。
6. Agent 与复杂工作流
当业务不只是“问答”，而是“查订单、查物流、生成工单、给补偿建议”时，单纯的检索已经不够，需要 Agent 进行任务规划和工具调用。会话内存用于记录上下文，工具执行框架用于统一调用内部服务，提示填充用于约束模型行为。复杂工作流最好采用可观测、可回放、可人工介入的设计，避免大模型直接越权执行。
7. 面试回答建议
在大厂面试中，回答技术问题时尽量遵循“先概念、再机制、后场景、最后风险”的结构。比如讲 Kafka，不要只说“消息队列”，而要说订单链路如何异步化、如何保证幂等、如何处理堆积和重试。讲 RAG，不要只说“向量检索”，而要结合文档加载、切分策略、召回与重排、提示填充和引用输出。这样更容易体现你的工程思维。
感谢阅读
感谢阅读这篇面试实录，希望它能帮助你更好地理解 Java 面试中的高频技术点，并在真实面试中答得更稳、更清晰、更像一个真正能落地的工程师。希望对你有所帮助，祝你面试顺利，早日拿到满意的 offer。
