Java 面试实战Spring Boot Kafka Redis AI RAG 在电商推荐与智能客服场景下的 3 轮高频追问场景互联网大厂 Java 求职面试业务方向为电商场景围绕推荐、库存、订单与智能客服展开。第一轮基础架构与高并发入口面试官我们先从电商首页推荐链路聊起。假设你负责一个 Spring Boot 微服务首页请求量突增时你会怎么设计接口避免把数据库打穿燕双非嗯……先加缓存吧Redis 先顶上热点数据放本地缓存接口做限流必要时降级返回默认推荐。面试官思路基本对。那缓存穿透、击穿、雪崩你怎么区分燕双非穿透就是缓存里没有数据库也没有击穿是某个热点 key 突然失效雪崩就是一批 key 一起过期……我一般会设随机过期时间穿透的话可以加布隆过滤器。面试官不错能区分清楚说明你不是只会背概念。那如果推荐接口依赖 Kafka 异步刷新画像你怎么保证消息至少被处理一次后业务不重复扣减积分燕双非这个……可以先消费消息然后写数据库前加个唯一标识避免重复插入。或者用幂等表记录消费状态重复消息直接忽略。面试官可以幂等是关键。继续说Spring Boot 里你会怎么配合 Actuator、Micrometer、Prometheus 做这条链路的监控燕双非就……打点指标呗QPS、RT、错误率、Kafka 积压、Redis 命中率都采集Prometheus 拉取Grafana 看板展示。面试官还行至少知道业务链路要看什么指标。那你平时有没有给接口做过线程池隔离燕双非有……好像就是把不同业务放不同线程池防止一个慢接口拖垮整个服务。面试官这个方向是对的但要记得结合队列长度、拒绝策略、上下游超时一起设计。第二轮订单、支付与一致性面试官电商下单后要走支付、库存扣减、优惠券核销、订单状态更新。你如何设计事务边界燕双非嗯……我会把最核心的订单创建放在本地事务里后面的库存和券核销尽量走异步。因为跨服务全局事务太重容易把系统搞慢。面试官很好能说出本地事务优先和异步化。那如果支付成功了但订单状态没更新怎么补偿燕双非可以用消息队列做最终一致性支付回调成功后发一条事件订单服务消费更新状态。如果失败了就重试重试也失败就进死信队列人工兜底。面试官回答比较完整。再问细一点MyBatis 和 JPA 在订单系统里你会怎么选燕双非嗯……如果是复杂 SQL、强控制性能我倾向 MyBatis如果是简单 CRUD、开发效率优先JPA 也可以。电商订单这种查询比较复杂的场景MyBatis 用得更多。面试官这个判断是合理的。那数据库连接池为什么通常用 HikariCP而不是随便一个都行燕双非因为 HikariCP 性能好轻量获取连接快适合高并发场景。面试官对。那你解释一下如果 Redis 作为库存缓存如何避免超卖燕双非可以在 Redis 里先做原子扣减比如 Lua 脚本保证检查库存和扣减是一个原子操作然后再异步落库。落库前还要有消息幂等不然数据会乱。面试官这就对了缓存原子性和最终一致性要一起考虑。面试官最后一个问题这条链路里如果我们引入 Spring Security 和 JWT 做用户鉴权你觉得 token 放哪里更合适燕双非一般放请求头里服务端做签名校验和过期校验尽量别把敏感信息直接塞进去。面试官行至少你没把 JWT 当数据库。第三轮AI 智能客服与搜索增强面试官现在电商要做一个 AI 智能客服能够回答“我的订单到哪了”“怎么退货”“商品规格怎么选”这类问题。你会怎么设计一个基于 Spring AI RAG 的方案燕双非先把客服文档、订单规则、退换货政策这些内容做文档加载然后切分成片段做向量化存到向量数据库里比如 Milvus。用户提问时先做语义检索再把检索结果和问题一起喂给大模型生成回答。面试官不错链路说清楚了。那你知道为什么不能直接把所有文档一次性塞给大模型吗燕双非因为上下文长度有限而且会增加成本和噪声。RAG 是先检索再生成能降低幻觉。面试官回答得很好。那如果用户问“我昨天买的蓝色款和今天买的蓝色款是不是同一个链接”这种有上下文的追问你怎么让系统记住聊天状态燕双非要有聊天会话内存保存用户上下文、历史问题和关键实体。这样后续问题能接着理解不然模型会像失忆一样。面试官形容得挺形象。再深入一点Agent 和普通 RAG 的区别是什么燕双非普通 RAG 主要是检索增强生成Agent 还会根据目标调用工具比如查订单、查物流、拉取退款状态属于能执行多步任务的智能代理。面试官对Agent 更像“会干活”。那如果客服系统要对接订单服务、物流服务、售后服务你怎么防止工具调用失控燕双非可以做工具白名单、参数校验、超时控制和审计日志必要时对高风险动作二次确认。面试官很好。最后问一个当大模型答错了出现幻觉时你怎么兜