Java 面试实录：Spring Boot + Kafka + Redis + RAG，在电商 AIGC 场景下的三轮进阶追问
场景：互联网大厂 Java 面试现场，业务方向为电商 AIGC 推荐与客服协同系统。
角色：严肃面试官、搞笑水货程序员燕双非。
第一轮：基础能力与业务落地
面试官：如果让你为一个电商 AIGC 系统搭建 Java 服务端，你会优先选什么技术栈？为什么？
燕双非：我一般会先用 Spring Boot 快速搭骨架，配上 MyBatis 或 JPA 做数据访问，Redis 做缓存，Kafka 做异步消息。这样能先把下单、推荐、客服工单这些核心链路跑起来。
面试官：回答得还可以，说明你至少知道先保证主链路可用。那如果 AIGC 推荐结果需要和用户会话实时联动，怎么设计接口？
燕双非：可以把会话状态放 Redis，接口层用 Spring MVC 提供 REST API，前端每次带会话 ID，请求到达后先取历史上下文，再调用模型服务生成结果。
面试官：嗯，有状态和无状态分层思路是对的。那你怎么保证推荐请求别把主线程拖死？
燕双非：我会把耗时操作扔到 Kafka 后台处理，接口先返回受理结果，或者通过 WebSocket 轮询/推送最终结果。
面试官：可以，至少知道异步化。继续。
面试官：Redis 里会话数据和推荐结果，如何设计 key 才比较合理？
燕双非：嗯……通常会带业务前缀、用户 ID、场景名，设置过期时间，避免脏数据无限堆积。比如 chat:session:{userId} 这种。
面试官：还不错，命名规范和 TTL 意识都有了。
第二轮：中间件、稳定性与安全
面试官：电商 AIGC 系统高峰期流量很大，Kafka 消费堆积了，你怎么排查？
燕双非：先看消费者实例数、分区数和处理耗时；如果是模型调用太慢，就加消费者，或者把消息按业务拆分到不同 topic，减少互相影响。
面试官：这个思路是对的。那如果同一条用户请求被重复消费了，怎么避免重复生成推荐结果？
燕双非：可以做幂等，比如用 requestId 去 Redis 或数据库查一下有没有处理过；如果处理过就直接返回之前结果。
面试官：很好，幂等是消息系统里非常关键的一环。Spring Security 在这个系统里怎么用？
燕双非：用户端和运营端分权限，用户只能看自己的会话和推荐结果，运营人员才能看模型配置和召回策略。登录后可以用 JWT 传递身份信息，再配合 Spring Security 做鉴权。
面试官：回答得比较完整。那你会把鉴权放在网关还是业务服务里？
燕双非：我……我觉得都可以吧，网关先做一次统一校验，业务服务再做细粒度权限判断，这样比较稳。
面试官：对，分层防御的意识还算不错。
面试官：这个系统如果要上线监控，你会关注哪些指标？
燕双非：接口延迟、错误率、Kafka 积压、Redis 命中率、模型调用成功率，还要看 JVM 的 GC 和线程池队列长度。可以用 Micrometer 接 Prometheus，再用 Grafana 展示。
面试官：这部分比刚才像样，说明你不是只会拍脑袋。
第三轮：架构、演进与 AI 深水区
面试官：现在让你做一个企业级智能客服系统，既要支持 FAQ 检索，也要支持 RAG，你怎么设计？
燕双非：我会把文档先做加载和切分，再向量化，存到向量数据库里，比如 Milvus。用户提问后先做语义检索，召回相关文档，再拼接提示词交给大模型生成答案。
面试官：不错，已经不是纯“调接口”思路了。那如果答案出现幻觉，怎么处理？
燕双非：额……可以加强检索质量，限制模型只根据检索内容回答，还可以加答案置信度判断，低置信度就转人工。
面试官：很好，说明你知道幻觉不能只靠“祈祷”。继续。
面试官：如果智能客服要接入多个工具，比如查订单、查物流、发优惠券，你会怎么做工具调用标准化？
燕双非：可以把工具封装成统一的接口，通过 Spring AI 或者类似 Agent 框架管理工具调用，让模型决定何时调用哪个工具；同时把参数校验、超时和重试统一起来。
面试官：很好，这已经有 Agentic RAG 的味道了。
面试官：最后一个问题，如果系统从单体演进到微服务，你会优先拆哪些模块？
燕双非：我会先拆用户会话、推荐生成、订单/工单、权限认证和通知模块。高并发、强隔离的模块优先拆，数据库也尽量按领域分库分表。
面试官：思路是对的，但你在服务边界和数据一致性上还要再补课。今天就先到这里，你回家等通知吧。
问题详解与知识点总结
1. Spring Boot 在电商 AIGC 系统中的作用
Spring Boot 适合快速构建服务端骨架，自动配置、约定优于配置，能够快速落地接口、任务调度、异常处理与配置管理。在电商 AIGC 场景中，它通常承载用户请求入口、推荐编排、客服会话管理等核心服务。
2. Redis 会话与结果缓存设计
会话类数据适合放在 Redis 中，原因是读写快、支持 TTL、适合短生命周期状态。Key 命名应包含业务前缀和场景标识，例如chat:session:{userId}。需要注意过期策略、防止热点 key、以及大对象拆分。
3. Kafka 异步削峰与幂等消费
在 AIGC 推荐或客服系统中，大模型调用通常是耗时操作，使用 Kafka 做异步化可以削峰填谷。消费端必须考虑幂等，常见做法是基于 requestId、业务唯一键、Redis SETNX 或数据库唯一索引去重，避免重复生成结果。
4. Spring Security + JWT 的鉴权模式
用户登录后由认证中心签发 JWT，网关完成统一校验，业务服务再做细粒度权限控制。这样既能降低重复验证成本，也能防止越权访问。对于运营后台和普通用户端，权限模型应明显隔离。
5. Micrometer、Prometheus、Grafana 的监控闭环
线上系统应重点关注接口延迟、错误率、QPS、Kafka lag、Redis 命中率、JVM GC、线程池队列长度、模型调用成功率等指标。Micrometer 负责埋点，Prometheus 负责采集，Grafana 负责展示与告警。
6. RAG 的核心流程
RAG 包含文档加载、切分、向量化、向量检索、提示词构造和大模型生成。其关键在于“先检索、后生成”，让模型回答尽量基于企业知识库，从而提升准确率、降低幻觉风险，适合企业客服、知识问答、政策解读等业务。
7. 幻觉治理与人工兜底
AI 幻觉无法彻底消除，只能降低。常用手段包括：提高检索质量、使用领域知识库、限定回答范围、增加引用依据、低置信度转人工、结构化输出校验等。
8. Agent 与工具调用标准化
在复杂客服或运营系统中，模型不仅要回答问题，还要调用订单、物流、优惠券等工具。此时可通过 Agent 框架统一管理工具注册、参数校验、重试、超时、审计和权限控制，逐步演进为 Agentic RAG。
9. 微服务拆分原则
从单体向微服务演进时，应优先拆高并发、强隔离、边界清晰的模块，例如会话、推荐、通知、权限。拆分时要同步考虑数据一致性、事务边界、服务间通信和容错机制。
结语
以上就是本次电商 AIGC 场景下的 Java 面试实录，希望通过这种“故事化 + 追问式”的方式，帮助大家更直观地理解大厂面试中常见的技术考点与业务落地思路。感谢阅读，希望这篇文章能真正帮到正在求职和备战面试的你。
