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