Java 面试实战Spring Boot Kafka Redis Spring Security RAG 场景下的 3 轮深挖问答场景互联网大厂电商与大数据 AI 服务平台正在招聘 Java 开发工程师。角色严肃的面试官和一位“经验丰富但总差一点”的水货程序员燕双非。第一轮订单与库存的基础链路面试官先聊一个基础场景。我们现在做一个秒杀商品下单接口服务端用 Spring Boot数据库用 MyBatis缓存用 Redis。你会怎么设计接口流程燕双非这个简单先查 Redis 有没有库存有就直接扣减然后落库最后返回成功。Spring Boot 写个 Controller 就行MyBatis 负责 SQLRedis 负责快。面试官思路方向对先走缓存再落库确实能减轻数据库压力。那如果 Redis 扣减成功了数据库更新失败怎么办燕双非那就……重试一下不行就补偿一下反正我们可以加个 try-catch。面试官补偿是对的但你得说清楚补偿链路。比如用消息队列异步补偿或者通过事务消息、最终一致性来处理。继续说为什么秒杀场景里会特别强调防重复提交和幂等燕双非因为用户手抖会点很多次或者网络卡了会重发请求。幂等就是让他点十次也只能成功一次。面试官这句话说得还行。那你会用什么方式做幂等燕双非可以用 token或者订单号唯一索引或者 Redis setnx。具体看老板喜欢哪个。第二轮消息驱动与权限控制面试官现在我们把下单链路升级一下。订单创建后要发 Kafka 消息通知库存服务、积分服务、优惠券服务分别处理。你会怎么保证消息不丢、不重并且消费者能水平扩展燕双非Kafka 本身挺稳的应该不会丢吧。消费者多开几个实例谁抢到算谁的。面试官“应该不会丢”不是面试答案。你至少要讲 producer 端 acks、重试、幂等生产者consumer 端 offset 提交时机以及业务幂等。那如果库存服务处理很慢怎么避免把自己压垮燕双非那就限流或者把线程池调大一点实在不行让 Kafka 多分几个 partition。面试官分区能提升并发但不是无限加线程。这里还要考虑消费速率、背压、失败重试和死信队列。继续订单系统涉及用户登录Spring Security JWT 你会怎么做权限校验燕双非登录后发一个 JWT后面请求带着 token 就行。Spring Security 配个过滤器解析一下用户名和角色放到上下文里。面试官可以至少主流程对。那 JWT 过期了怎么办如果要踢下线、黑名单控制、刷新令牌你怎么设计燕双非这个……可以把 token 存 Redis过期就删掉。踢下线的话也存 Redis黑名单也存 Redis。反正 Redis 很万能。面试官思路接近实战但要区分短 token、refresh token、黑名单、设备维度会话管理。不要把所有东西都混成一个 Redis key。下一轮我们讲点更贴近线上故障的。第三轮AI 检索、链路追踪与容灾面试官我们现在给电商客服接入一个 AI 智能助手要求支持企业文档问答、订单知识库检索和客服推荐回复。你会怎么结合 Spring AI、RAG、向量数据库来做燕双非就是把文档丢进去做 embedding存到 Milvus 里。用户问问题时先做语义检索再把结果塞给大模型应该就能回答了。Spring AI 负责调用模型挺方便的。面试官方向正确。那如果检索出来的文档有旧版本、答案冲突或者模型开始胡说八道怎么控制幻觉燕双非那就多喂点资料或者提示词写得严格一点。实在不行让模型少说话。面试官提示词、检索质量、重排、置信度阈值、答案引用来源这些都要结合。最后一个问题线上客服系统调用链很长Web 层、订单服务、库存服务、AI 服务、消息队列、缓存、数据库。你会怎么做链路追踪和指标监控燕双非可以上 Prometheus 看指标Grafana 画图Jaeger 看链路。日志用 SLF4J 配 Logback出问题就查 traceId。要是还不行就……重启试试。面试官前半段回答不错后半段有点水但至少方向清楚。今天先到这你回去等通知吧。问题详解从业务到技术的完整拆解1. 秒杀下单链路为什么要先查 Redis 再落库秒杀场景的核心矛盾是高并发和资源稀缺。Redis 适合做库存预扣因为它吞吐高、延迟低能在流量峰值时快速挡住大部分请求。常见做法是请求先校验参数和登录态用 Redis 预扣库存必要时配合 Lua 保证原子性扣减成功后写入订单表落库失败时触发补偿逻辑避免缓存和数据库不一致。需要注意的是Redis 只是“前置削峰”最终仍要回到数据库做真实持久化。2. 为什么要做幂等常见幂等方案有哪些在网络重试、用户重复点击、消息重复投递等情况下同一业务请求可能被执行多次。幂等的目标是“同一个业务动作无论执行多少次结果都一样”。常见方案包括唯一业务键 数据库唯一索引例如订单号唯一重复写入直接失败Redis setnx/token先拿到一次性令牌才允许提交状态机控制例如订单只能从待支付流转到已支付一次消息消费幂等消费记录表、去重表、业务唯一约束等。在电商系统里幂等通常要覆盖接口层、消息层和任务层。3. Kafka 在订单链路中如何保证“尽量不丢、不重”Kafka 是电商异步解耦的常见选择。设计时要同时关注生产者、Broker 和消费者三端生产者端开启幂等生产者合理设置 acks必要时做重试Broker 端分区数决定并发度副本决定可靠性消费者端处理成功后再提交 offset失败时重试或进入死信队列业务层无论消息是否重复都要保证业务幂等。注意Kafka 能降低丢消息概率但“绝对不丢”通常意味着要结合事务、补偿和业务容错一起设计。4. Spring Security JWT 在大厂项目里怎么落地典型流程是用户登录成功后签发 JWT客户端在后续请求中携带 JWT服务端过滤器解析 JWT构造认证对象写入 SecurityContext基于角色、权限或资源标识做鉴权。进一步完善时常会加入Access Token Refresh Token双令牌机制Redis 会话管理用于踢下线、设备管理、黑名单控制过期与刷新策略避免长期 token 泄露带来的风险。在高安全场景下还会结合设备指纹、异地登录告警、风控规则等能力。5. RAG 为什么比“直接问大模型”更适合企业客服企业客服问答的关键是准确性和可追溯性。直接问大模型容易出现幻觉尤其在订单政策、售后规则、促销说明这类强业务约束场景里风险很大。RAG 的核心思路是先把企业文档、FAQ、知识库切分并做向量化用户提问后先做语义检索将召回内容作为上下文交给大模型生成答案必要时附带引用来源、文档版本和置信度。这样能显著降低幻觉同时让答案更贴近企业真实规则。6. 如何提升 RAG 的效果并控制幻觉实战中通常从以下几个方向优化文档清洗与切分按语义段落切块避免碎片化Embedding 模型选择让向量更贴近业务语义向量库召回Milvus、Chroma、Redis Vector 等重排模型对初筛结果做精排提高相关性提示词约束要求模型仅基于检索内容回答答案引用输出来源增强可解释性兜底策略检索不到时明确说“不知道”而不是瞎编。企业客服里“少答错”往往比“答得像”更重要。7. Prometheus、Grafana、Jaeger、日志系统分别解决什么问题当系统拆成 Web、订单、库存、AI、消息队列多个服务后排障必须依赖可观测性体系Prometheus采集指标例如 QPS、错误率、延迟、队列堆积Grafana把指标做成看板便于观察趋势Jaeger/Zipkin链路追踪定位一次请求经过了哪些服务SLF4J Logback/Log4j2记录业务日志结合 traceId 串联请求上下文。线上排障时一般是“指标发现异常、链路定位位置、日志看具体原因”三步配合。8. 这个场景里为什么要让“燕双非”式回答也能成立一半因为很多面试并不是背概念而是看候选人能否把基础知识和业务串起来。像“Redis 先挡流量”“JWT 放在请求头”“Prometheus 看指标”这些回答说明候选人有基本经验而“补偿、幂等、重试、链路追踪、幻觉控制”这些内容则体现出候选人是否经历过真实线上环境。真正的大厂面试往往不是要你一句话背出标准答案而是希望你能沿着业务链路把系统讲清楚。感谢阅读希望这篇文章能帮助你在 Java 面试中更有思路也希望你能把这些知识真正用到项目里顺利拿到心仪的 offer。