Java 面试实战Spring Boot Kafka Redis AI/RAG 的互联网大厂求职过关指南题目背景互联网大厂电商平台正在做“搜索推荐 智能客服 订单异步处理”一体化升级。面试官严肃、挑剔候选人是外号“水货程序员”的燕双非平时嘴上很会真到难题就开始含糊其辞。下面是三轮递进式面试实录。第一轮基础架构与业务入口面试官你们这个电商系统用 Spring Boot 做服务入口为什么不用老式的 Spring MVC XML燕双非因为 Spring Boot 比较省事自动配置多启动也快。对我们这种快速迭代的项目能少写很多配置文件挺适合。面试官说得不错能快速落地。那你再说说订单创建接口为什么要加幂等控制燕双非嗯……因为用户可能重复点击下单请求也可能因为网络重试重复发送。如果不做幂等库存和订单都会多扣一次容易出事故。面试官这个方向对继续说你们一般怎么做燕双非可以给每次请求带一个唯一 token服务端校验后消费一次就作废或者用业务唯一键比如订单号、支付流水号再结合数据库唯一索引防重复。面试官还行说明不是完全没干过活。那 Redis 在这里能做什么燕双非Redis 可以做幂等 token 的缓存也可以做购物车、热点商品详情缓存。请求到来时先查 Redis减少数据库压力。第二轮异步解耦与安全治理面试官用户下单后为什么不直接同步发短信、发券、写积分而是引入 Kafka燕双非因为同步做太慢了主流程会被拖住。Kafka 可以把这些后置任务拆成消息订单服务只负责发消息短信、优惠券、积分各自消费。面试官很好说明你懂解耦。那如果 Kafka 消息重复投递了怎么办燕双非这个……消费者那边要做去重通常可以按消息 id 或订单 id 做消费记录处理过就直接忽略。反正 MQ 这东西尽量按“至少一次”去设计。面试官回答得不错。再说说登录鉴权为什么你们接口统一用 JWT燕双非JWT 可以把用户身份和权限信息放到 token 里服务端不一定非要存 session适合微服务和移动端。请求来了直接校验签名和过期时间就行。面试官那 JWT 就一定安全吗燕双非也不是。它本身只是签名令牌泄露了就可能被冒用所以要配合 HTTPS、短过期、刷新机制、黑名单机制。高风险接口还要加二次校验。面试官说得有点像样了。那你们用 Micrometer 和 Prometheus 主要看什么指标燕双非看接口响应时间、QPS、错误率、JVM 堆内存、GC 次数还有 Kafka 消费堆积量。Prometheus 拉指标Grafana 画图方便定位哪里慢了。第三轮AI 升级与复杂链路面试官现在公司要给电商接一个智能客服支持“订单查询、物流解释、退款政策问答”。如果直接让大模型回答会有什么问题燕双非会有幻觉模型可能瞎编政策或者编造物流信息。尤其是涉及订单和售后不能让它乱说。面试官那你会怎么做燕双非可以做 RAG。先把企业知识库、售后规则、物流文档做文档加载和向量化存到向量数据库比如 Milvus 或 Redis然后用户提问时做语义检索把相关内容拼到提示词里让模型基于真实资料回答。面试官如果是“查询我自己的订单物流”只靠 RAG 够吗燕双非不够这种要走工具调用。模型先识别意图再调用订单查询接口、物流查询接口把结果返回后再组织自然语言回复。RAG 负责知识问答工具调用负责实时业务数据。面试官很好。那如果客服场景要支持多轮追问比如“这个退款能不能加急”“那我换货怎么办”你怎么维持上下文燕双非需要聊天会话内存记录用户当前订单、售后状态、上轮提到的实体信息。这样后续追问时不用每次都从头解释一遍。面试官最后一个问题Spring AI 在这里能帮什么燕双非它可以把模型、向量检索、工具调用这些能力统一起来简化接入。比如把大模型、Embedding 模型、RAG 流程、Agent 工作流串起来做成一个可扩展的智能客服系统。面试官嗯今天就到这里。你先回去等通知吧。问题详解与知识点总结1. Spring Boot 为什么适合电商业务快速迭代Spring Boot 的核心价值是约定优于配置。对于电商这种高频变化的业务自动配置、starter 依赖、内嵌容器可以显著降低接入成本。它适合快速搭建订单、商品、营销等服务同时也便于微服务拆分。2. 订单接口幂等控制的必要性与实现在支付、下单、退款等场景中网络重试、超时重发、用户重复点击都可能造成重复请求。常见方案包括前端生成一次性 token服务端消费后作废业务唯一键 数据库唯一索引Redis 原子校验与删除状态机控制订单流转。实际中通常会组合使用保证接口在高并发下也能稳定。3. Redis 在电商链路中的典型作用Redis 常用于缓存商品详情、购物车、会话信息、幂等 token、热点配置等。它能显著减轻数据库压力但也要注意缓存一致性、穿透、击穿、雪崩等问题。电商常采用缓存预热、随机过期时间、布隆过滤器等手段优化。4. 为什么 Kafka