Java 面试实战：Spring Boot + Kafka + Redis + RAG 场景下的大厂求职问答
场景：互联网大厂电商与 AIGC 融合业务面试
角色：严肃面试官 / 搞笑水货程序员燕双非
第一轮：基础能力与业务理解
面试官：我们先从基础开始。你们团队做的是电商商品详情页，QPS 很高。你会怎么用 Spring Boot 快速搭一个高可用服务？
燕双非：Spring Boot 最大的好处就是开箱即用。我一般先把 Starter 配齐，再把 Controller、Service、Repository 分层，配好 Actuator 监控，最后再加配置中心和限流。高可用的话，至少要做好无状态、水平扩展和超时控制。
面试官：回答得还不错，说明你不是只会“Hello World”。那如果商品详情页要兼顾推荐文案和实时库存，你会怎么设计接口返回？
燕双非：我会把商品基础信息、库存信息、推荐文案拆成多个子模块，聚合到一个 DTO 里返回。库存这种强时效数据可以单独查，推荐文案可以走缓存或者异步生成，减少主链路耗时。
面试官：思路是对的，说明你知道“快”和“准”要分开处理。
面试官：你提到缓存，那 Redis 在这个场景里主要承担什么角色？
燕双非：Redis 我一般拿来做热点商品缓存、秒杀库存、分布式锁，还有消息通知。比如商品详情页可以缓存 30 秒，防止数据库被打爆。
面试官：可以，热点缓存和秒杀库存是 Redis 的典型用法。那缓存失效怎么办？
燕双非：嗯……一般就是删缓存再更新数据库，或者更新数据库后再删缓存。反正别让用户看到脏数据就行。
面试官：你说到了方向，但还需要考虑双写一致性、延迟双删和失败补偿。
第二轮：消息驱动与 AI 场景融合
面试官：现在业务升级了。用户在商品页可以直接问 AI：“这款手机适合拍夜景吗？”系统要结合商品参数、用户画像和知识库回答。你会怎么设计？
燕双非：这个就是 RAG。先把商品说明书、评论、FAQ 做文档加载和向量化，存到向量数据库里；用户提问时先做语义检索，再把检索结果拼到提示词里交给大模型生成答案。
面试官：很好，已经开始像个正经工程师了。那如果检索结果不准，或者模型开始“胡说八道”，你怎么处理 AI 幻觉？
燕双非：我会做几个事：一是召回内容加置信度，二是回答里尽量让模型引用检索证据，三是对高风险问题走规则兜底，比如参数类问题直接查结构化数据库，不完全依赖大模型。
面试官：这就对了。企业里最怕的不是“不会答”，而是“瞎答”。
面试官：假设这个 AI 问答服务前面还有一个 Kafka 事件流，用户提问要先记录日志，再异步做埋点和画像更新。你会怎么保证链路不乱？
燕双非：我会把提问请求先同步落库一条请求记录，然后发送 Kafka 事件，消费端做埋点、画像更新和离线分析。消息要带 traceId，方便串联日志。消费幂等也很重要，不然重复消费会把用户画像刷爆。
面试官：不错，已经想到幂等和链路追踪了。那 Kafka 和 RabbitMQ 相比，你怎么选？
燕双非：Kafka 更适合高吞吐、日志流、事件驱动；RabbitMQ 更适合复杂路由和业务确认。这个场景我更偏向 Kafka，因为提问埋点和行为流量大，适合流式处理。
面试官：回答清楚了，方向正确。
第三轮：性能、架构与落地细节
面试官：如果这个系统要支撑大促期间千万级访问量，Spring Boot 服务本身你会从 JVM 层面怎么优化？
燕双非：嗯……JVM 这块主要是控制堆大小、选择合适的 GC、减少频繁创建对象。比如排查是不是有大对象、内存泄漏，另外线程池也要限流，不然 Full GC 一来就凉了。
面试官：有这个意识就很好。那如果你发现接口 RT 偶尔抖动，你会优先看哪里？
燕双非：我会先看链路上是数据库慢、Redis 慢、还是远程调用慢，再看线程池队列、GC 日志和慢查询。先定位瓶颈，再考虑优化，比如索引、批量查询、缓存预热。
面试官：很好，排查路径清晰。
面试官：最后一个问题：如果你的 AI 问答服务需要支持在线客服、消息回复和订单查询，你会怎么做服务拆分？
燕双非：我会把用户会话、知识检索、订单查询、客服工单拆成独立服务，通过 API 网关统一入口。会话状态可以放 Redis，长文本和审计记录落库，复杂检索走 RAG，订单查询直接调业务服务。高峰期客服消息可以异步排队，避免把实时链路打挂。
面试官：整体思路已经比较完整了，不过有些细节还需要继续打磨。今天先到这里，你回家等通知吧。
所有面试题详细解析
1. Spring Boot 如何支撑高可用商品详情服务
在电商商品详情页这种高并发场景下，Spring Boot 的核心价值是快速构建标准化服务。通常会结合以下思路：
- 使用分层架构：Controller 负责接入，Service 负责业务，Repository/Mapper 负责数据访问。
- 引入 Actuator 监控健康状态、指标和线程信息。
- 服务尽量无状态，便于横向扩容。
- 合理设置超时、重试和熔断，避免局部故障扩大。
- 配合配置中心、注册发现和网关实现统一治理。
业务上，商品详情往往包括基础信息、价格、库存、营销、推荐等多个域，建议拆成多个下游来源后统一聚合返回。
2. Redis 在商品详情与秒杀中的作用
Redis 常用于：
- 热点数据缓存：商品标题、主图、价格等
