Java 面试实录Spring Boot Kafka Redis RAG 在电商大厂场景中的 3 轮攻防面试场景互联网大厂电商业务线候选人燕双非。面试官神情严肃手里翻着简历。面试官我们从电商高并发场景开始先聊基础再聊业务落地最后聊你对 AI 能力的理解。第一轮电商下单链路与基础架构问题 1如果让你设计一个秒杀下单接口Spring Boot 里你会怎么做限流和幂等燕双非限流我会先用网关做像基于令牌桶或者漏桶的思路幂等的话前端提交一次订单后后端可以通过唯一请求号配合 Redis 去重防止重复提交。面试官这个方向是对的。你至少知道限流前置和幂等控制的位置。问题 2库存扣减你会放在 MySQL 里直接扣还是先走 Redis为什么燕双非我会先用 Redis 预扣库存避免数据库扛不住真正落库时再做校验。数据库直接扣也行但高峰期可能压力很大。面试官回答还算稳知道把热点压力从数据库前移。问题 3订单创建后要发消息通知库存、营销、物流你会怎么选消息队列燕双非Kafka 比较适合这种高吞吐异步解耦场景。订单服务发出事件库存、营销各自消费彼此不阻塞。面试官不错已经开始考虑事件驱动了。第二轮支付、风控与可观测性问题 1如果支付回调重复到达如何保证只处理一次燕双非可以用数据库唯一键约束加状态机回调接口先查订单状态已处理就直接返回成功另外也可以结合 Redis 做短期幂等锁。面试官比刚才更完整了既考虑了数据库约束也考虑了缓存层。问题 2支付链路出问题后怎么快速定位是接口慢、MQ 堆积还是数据库抖动燕双非我会看 Prometheus 和 Grafana 的指标比如接口耗时、QPS、错误率再看 Kafka 积压、Redis 命中率、数据库连接池情况。日志用 ELK 或 Logback 配合 traceId 串起来。面试官很好已经具备基本的可观测性意识了。问题 3你知道 Spring Security 在支付系统里怎么做权限控制吗燕双非嗯……就是登录后校验角色吧敏感接口加个权限注解JWT 里放用户信息网关统一验签。面试官思路可以但细节还不够扎实后面要继续补。问题 4如果风控系统要在下单时实时拦截异常用户你会怎么接入燕双非可以在订单服务里同步调用风控服务或者先做一些本地规则预判再把结果发给风控中心复杂一点的话就走微服务链路和降级策略。面试官好至少知道同步拦截和异步画像可以结合使用。第三轮AI 推荐与智能客服问题 1现在业务想做一个“订单助手”支持自然语言查订单、查退款你会怎么设计燕双非我会考虑 Spring AI 之类的能力把用户问题做意图识别再去调用订单查询、退款查询这些工具接口如果是知识类问题可以接 RAG从文档库里检索答案。面试官这回答就比较像样了已经能把工具调用和检索增强结合起来。问题 2RAG 为什么比直接把所有文档喂给大模型更适合企业场景燕双非因为文档太多太大直接塞进去成本高、上下文也放不下。RAG 先做向量化和语义检索只把相关片段拿出来给模型效率更高也更容易控制幻觉。面试官说得不错方向对已经知道召回和上下文控制的价值。问题 3如果客服要支持多轮对话还要记住用户刚才问过什么你怎么做燕双非会给每个会话维护聊天记忆保存历史问题和关键状态如果要复杂一点还可以把工具执行结果和中间状态一起存起来避免每轮都重新计算。面试官可以知道会话内存和状态保持的重要性。问题 4最后一个问题AI 幻觉怎么处理燕双非呃……我觉得可以多让模型“认真一点”然后把提示词写清楚必要时加人工审核再配合检索和规则校验应该就能好很多。面试官行先到这儿吧。你的基础有一些但对复杂链路和 AI 落地细节还需要继续加强。你先回去等通知吧。问题详解与业务场景剖析1. 秒杀接口的限流与幂等在电商秒杀中流量会在短时间内集中爆发。限流通常放在网关层或接口入口层常见方式包括令牌桶、漏桶、滑动窗口。Spring Boot 应用中可以结合 Gateway、Resilience4j 或自定义拦截器实现。幂等的核心是“同一请求只处理一次”。实践中通常使用唯一请求号 Redis 去重数据库唯一索引约束状态机控制订单流转这样能防止重复点击、重试、网络抖动带来的重复下单。2. 库存预扣与最终落库高并发下直接操作数据库容易成为瓶颈因此常见方案是 Redis 预扣库存先在缓存层快速判断是否可卖再异步或同步落库。这种方式的关键在于一致性控制Redis 和数据库之间不能只靠“感觉一致”要有补偿、对账、消息重试等机制。库存扣减往往配合消息队列保证订单、库存、营销之间松耦合。3. Kafka 在订单链路中的作用 Java 面试实录：Spring Boot + Kafka + Redis + RAG 在电商大厂场景中的 3 轮攻防
Java 面试实录Spring Boot Kafka Redis RAG 在电商大厂场景中的 3 轮攻防面试场景互联网大厂电商业务线候选人燕双非。面试官神情严肃手里翻着简历。面试官我们从电商高并发场景开始先聊基础再聊业务落地最后聊你对 AI 能力的理解。第一轮电商下单链路与基础架构问题 1如果让你设计一个秒杀下单接口Spring Boot 里你会怎么做限流和幂等燕双非限流我会先用网关做像基于令牌桶或者漏桶的思路幂等的话前端提交一次订单后后端可以通过唯一请求号配合 Redis 去重防止重复提交。面试官这个方向是对的。你至少知道限流前置和幂等控制的位置。问题 2库存扣减你会放在 MySQL 里直接扣还是先走 Redis为什么燕双非我会先用 Redis 预扣库存避免数据库扛不住真正落库时再做校验。数据库直接扣也行但高峰期可能压力很大。面试官回答还算稳知道把热点压力从数据库前移。问题 3订单创建后要发消息通知库存、营销、物流你会怎么选消息队列燕双非Kafka 比较适合这种高吞吐异步解耦场景。订单服务发出事件库存、营销各自消费彼此不阻塞。面试官不错已经开始考虑事件驱动了。第二轮支付、风控与可观测性问题 1如果支付回调重复到达如何保证只处理一次燕双非可以用数据库唯一键约束加状态机回调接口先查订单状态已处理就直接返回成功另外也可以结合 Redis 做短期幂等锁。面试官比刚才更完整了既考虑了数据库约束也考虑了缓存层。问题 2支付链路出问题后怎么快速定位是接口慢、MQ 堆积还是数据库抖动燕双非我会看 Prometheus 和 Grafana 的指标比如接口耗时、QPS、错误率再看 Kafka 积压、Redis 命中率、数据库连接池情况。日志用 ELK 或 Logback 配合 traceId 串起来。面试官很好已经具备基本的可观测性意识了。问题 3你知道 Spring Security 在支付系统里怎么做权限控制吗燕双非嗯……就是登录后校验角色吧敏感接口加个权限注解JWT 里放用户信息网关统一验签。面试官思路可以但细节还不够扎实后面要继续补。问题 4如果风控系统要在下单时实时拦截异常用户你会怎么接入燕双非可以在订单服务里同步调用风控服务或者先做一些本地规则预判再把结果发给风控中心复杂一点的话就走微服务链路和降级策略。面试官好至少知道同步拦截和异步画像可以结合使用。第三轮AI 推荐与智能客服问题 1现在业务想做一个“订单助手”支持自然语言查订单、查退款你会怎么设计燕双非我会考虑 Spring AI 之类的能力把用户问题做意图识别再去调用订单查询、退款查询这些工具接口如果是知识类问题可以接 RAG从文档库里检索答案。面试官这回答就比较像样了已经能把工具调用和检索增强结合起来。问题 2RAG 为什么比直接把所有文档喂给大模型更适合企业场景燕双非因为文档太多太大直接塞进去成本高、上下文也放不下。RAG 先做向量化和语义检索只把相关片段拿出来给模型效率更高也更容易控制幻觉。面试官说得不错方向对已经知道召回和上下文控制的价值。问题 3如果客服要支持多轮对话还要记住用户刚才问过什么你怎么做燕双非会给每个会话维护聊天记忆保存历史问题和关键状态如果要复杂一点还可以把工具执行结果和中间状态一起存起来避免每轮都重新计算。面试官可以知道会话内存和状态保持的重要性。问题 4最后一个问题AI 幻觉怎么处理燕双非呃……我觉得可以多让模型“认真一点”然后把提示词写清楚必要时加人工审核再配合检索和规则校验应该就能好很多。面试官行先到这儿吧。你的基础有一些但对复杂链路和 AI 落地细节还需要继续加强。你先回去等通知吧。问题详解与业务场景剖析1. 秒杀接口的限流与幂等在电商秒杀中流量会在短时间内集中爆发。限流通常放在网关层或接口入口层常见方式包括令牌桶、漏桶、滑动窗口。Spring Boot 应用中可以结合 Gateway、Resilience4j 或自定义拦截器实现。幂等的核心是“同一请求只处理一次”。实践中通常使用唯一请求号 Redis 去重数据库唯一索引约束状态机控制订单流转这样能防止重复点击、重试、网络抖动带来的重复下单。2. 库存预扣与最终落库高并发下直接操作数据库容易成为瓶颈因此常见方案是 Redis 预扣库存先在缓存层快速判断是否可卖再异步或同步落库。这种方式的关键在于一致性控制Redis 和数据库之间不能只靠“感觉一致”要有补偿、对账、消息重试等机制。库存扣减往往配合消息队列保证订单、库存、营销之间松耦合。3. Kafka 在订单链路中的作用