企业官网建设流程全解析

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，从文档库里检索答案。

面试官：这回答就比较像样了，已经能把工具调用和检索增强结合起来。

问题 2：RAG 为什么比直接把所有文档喂给大模型更适合企业场景？

燕双非：因为文档太多太大，直接塞进去成本高、上下文也放不下。RAG 先做向量化和语义检索，只把相关片段拿出来给模型，效率更高，也更容易控制幻觉。

面试官：说得不错，方向对，已经知道召回和上下文控制的价值。

问题 3：如果客服要支持多轮对话，还要记住用户刚才问过什么，你怎么做？

燕双非：会给每个会话维护聊天记忆，保存历史问题和关键状态；如果要复杂一点，还可以把工具执行结果和中间状态一起存起来，避免每轮都重新计算。

面试官：可以，知道会话内存和状态保持的重要性。

问题 4：最后一个问题，AI 幻觉怎么处理？

燕双非：呃……我觉得可以多让模型“认真一点”，然后把提示词写清楚，必要时加人工审核；再配合检索和规则校验，应该就能好很多。

面试官：行，先到这儿吧。你的基础有一些，但对复杂链路和 AI 落地细节还需要继续加强。你先回去等通知吧。

问题详解与业务场景剖析

1. 秒杀接口的限流与幂等

在电商秒杀中，流量会在短时间内集中爆发。限流通常放在网关层或接口入口层，常见方式包括令牌桶、漏桶、滑动窗口。Spring Boot 应用中可以结合 Gateway、Resilience4j 或自定义拦截器实现。

幂等的核心是“同一请求只处理一次”。实践中通常使用：

• 唯一请求号 + Redis 去重
• 数据库唯一索引约束
• 状态机控制订单流转

这样能防止重复点击、重试、网络抖动带来的重复下单。

2. 库存预扣与最终落库

高并发下直接操作数据库容易成为瓶颈，因此常见方案是 Redis 预扣库存，先在缓存层快速判断是否可卖，再异步或同步落库。

这种方式的关键在于一致性控制：Redis 和数据库之间不能只靠“感觉一致”，要有补偿、对账、消息重试等机制。库存扣减往往配合消息队列，保证订单、库存、营销之间松耦合。

3. Kafka 在订单链路中的作用