Java 大厂面试实录：基于 Spring Boot、Kafka、Redis、Spring AI 的电商智能推荐与支付风控三轮深挖
场景：互联网大厂电商与 AI 服务平台 Java 面试
面试官：我们今天聊一个电商平台的核心链路，包含商品推荐、下单支付、风控审核、消息通知和 AI 助手。请你结合自己的理解，从系统设计和 Java 技术栈说起。
燕双非：好的老师，我虽然写代码比较快，但是思路也很快。这个场景我熟，用户一进来先推荐，买了之后就支付，支付完再发消息，最后再让 AI 帮他挑货。
第一轮：基础链路与核心架构
1. 你会如何用 Spring Boot 搭建一个电商推荐服务？
燕双非：Spring Boot 最方便了，直接 starter 一把梭，内嵌 Tomcat，配置少，启动快。推荐服务我会拆成 controller、service、repository 三层，再加一个定时任务同步商品特征。
面试官：基础思路是对的，至少说明你知道分层和自动配置。那如果推荐接口要同时查用户画像和商品信息，你怎么控制响应时间？
2. 数据层你会优先考虑 JPA 还是 MyBatis？为什么？
燕双非：如果查询比较固定，我可能会用 MyBatis，SQL 可控；如果是简单 CRUD，我会用 JPA，省事一些。电商推荐这种读多写少的场景，读模型可以单独优化。
面试官：回答得还可以，至少知道按场景选型。那如果商品表特别大，你会怎么做索引和分页？
3. 推荐结果需要缓存，你会选 Redis 还是 Caffeine？怎么组合？
燕双非：Redis 适合分布式缓存，多个实例都能共享；Caffeine 适合本地热点缓存，性能更高。我会先用 Caffeine 扛热点，再用 Redis 做二级缓存。
面试官：不错，说明你知道多级缓存。那缓存一致性怎么保证？
4. 你如何设计商品下架后缓存失效和推荐降级？
燕双非：下架后发一个消息通知所有节点删缓存，推荐服务拿不到最新数据就走兜底策略，比如返回相似商品或者热门榜单。
面试官：这个方向是对的。消息通知、缓存失效和降级，已经开始有大厂味道了。
第二轮：支付风控、消息链路与安全
1. 支付下单后如何保证消息不丢？你会用 Kafka 还是 RabbitMQ？
燕双非：如果是高吞吐的订单流，我可能偏 Kafka，因为它适合日志和事件流。支付成功后发订单事件，库存、积分、通知各自消费。
面试官：至少你知道事件驱动了。那重复消费怎么办？
2. 订单消息重复投递，如何做幂等？
燕双非：可以用业务唯一键，比如订单号加状态，消费前先查数据库或者 Redis，处理过就直接返回。也可以在表里加唯一约束，防止重复写入。
面试官：很好，幂等是消息系统的基本功。那如果支付回调乱序了呢？
3. 支付风控里，JWT 和 Spring Security 怎么配合？
燕双非：JWT 里放用户身份和权限信息，Spring Security 负责鉴权拦截。支付接口可以加更严格的权限控制，比如二次验证、设备指纹和风险等级判断。
面试官：说得不错，至少知道认证和授权的边界。那你怎么处理令牌失效和踢下线？
4. 如果要接入风控规则引擎，你会怎么设计？
燕双非：嗯……我会先把规则写成配置，像金额阈值、频次限制、IP 黑名单这些，放到数据库或者配置中心。具体怎么动态加载……这个我需要回去再想一下。
面试官：方向没错，但表达还不够完整。风控系统最关键的是规则可配置、可审计、可回溯，后面我们会继续看你的设计能力。
5. 你会如何监控支付链路的延迟和错误率？
燕双非：我会接 Prometheus 和 Grafana，再配 Micrometer 打点。出了问题还能看日志和链路追踪，比如 Jaeger 或 Zipkin。
面试官：这个回答明显比前面成熟，能把监控、指标和链路追踪串起来，很好。
第三轮：AI 推荐、企业文档问答与复杂工作流
1. 如果要做“AI 导购助手”，你会怎么理解 Spring AI、RAG 和 Agent？
燕双非：Spring AI 可以帮 Java 项目接大模型，RAG 是先检索再生成，避免模型瞎编。Agent 就是让模型能调用工具，比如查库存、查订单、查优惠券。
面试官：这几个关键词你分得还算清楚。那为什么企业场景里不能只靠纯大模型问答？
2. 企业商品知识、活动规则、售后政策如何做语义检索？
燕双非：要先把文档切分，再做 embedding 向量化，存到向量数据库里，比如 Milvus、Chroma 或 Redis 向量能力。用户提问后先做语义检索，再把相关片段拼进提示词。
面试官：很好，已经接近实际方案了。那如果检索到了错误内容怎么办？
3. 你如何降低 AI 幻觉在客服场景里的影响？
燕双非：嗯……我觉得可以让模型少自由发挥，多引用知识库；另外把回答限定在业务规则里，不确定就让它转人工。还可以加工具调用标准化，所有关键结果都走系统接口。
面试官：这个回答方向正确，虽然不够细，但至少知道“控答复、控来源、控流程”。
4. 如果 AI 助手需要处理“查订单-改地址-验证身份-通知仓库”这种复杂工作流，你怎么设计？
燕双非：我会把它拆成多个步骤，前面用 Agent 做意图识别和工具调度，后面用工作流编排。比如先查订单，再走权限验证，再调用订单服务和仓储服务，最后发消息通知。
面试官：这个思路开始像做过项目了。大厂很看重这种端到端闭环能力。
5. 你会如何让 Java 服务和 AI 服务一起具备可扩展性？
燕双非：我会把模型服务和业务服务解耦，业务侧通过 HTTP 或 RPC 调用模型能力，必要时加异步队列和缓存。工具调用标准化后，后面换模型或者换供应商，改动会更小。
面试官：不错，已经能说到架构演进了。那今天先到这里吧，你回去等通知。
所有面试问题详细解答
1. 如何用 Spring Boot 搭建电商推荐服务
Spring Boot 的核心价值是快速构建、约定优于配置和统一的依赖管理。在电商推荐场景中，推荐服务通常是高并发读服务，可以采用 Controller + Service + Repository 的经典分层结构，同时把推荐逻辑与用户行为采集、特征加工、召回排序解耦。
业务上，用户进入首页时，服务需要快速返回推荐商品列表。此时可以把推荐结果提前预计算，或者对热点用户做缓存。对于复杂推荐策略，可以在 Service 层组合多个召回源，例如协同过滤、热门榜单、类目偏好和活动商品。
2. JPA 与 MyBatis 的选型
JPA 更适合标准 CRUD 和领域模型清晰的系统，能减少样板代码。MyBatis 更适合复杂 SQL、强控制需求和需要精细调优的场景。电商推荐系统往往既有简单查询，也有复杂报表、统计和排序查询，因此常见做法是两者并存：写模型用 ORM，复杂查询用 MyBatis。
业务中，如果推荐结果查询依赖多表聚合、窗口函数或复杂排序，MyBatis 更灵活；如果订单、用户基础信息维护比较标准，JPA 能显著提高开发效率。
3. Redis 与 Caffeine 的多级缓存
Caffeine 适合单机热点缓存，命中延迟更低；Redis 适合分布式共享缓存，适合多实例部署。电商推荐中常见组合是本地缓存扛热点、Redis 扛共享数据，数据库作为最终可信来源。
一致性方面，可以采用“先更新数据库，再删除缓存”或基于消息队列广播失效的方式。对于商品下架、价格变动等强一致性更敏感的场景，可以缩短缓存 TTL，并在变更后主动失效所有相关缓存键。
4. Kafka 在订单事件中的作用
Kafka 非常适合订单创建、支付完成、库存扣减、积分发放等事件流场景。其高吞吐、可扩展和分区特性适合大厂电商链路。支付成功后，业务系统可发布订单事件，多个下游系统各自消费，实现解耦。
为了避免消息丢失，通常需要配合本地事务、消息落库、重试和补偿机制。消费者侧要做幂等处理，避免重复消费导致库存多扣、积分重复发放等问题。
5. 消息幂等的实现
幂等是消息系统的核心能力。常见方案包括：使用业务唯一键、数据库唯一约束、Redis 去重、消费日志表、状态机校验等。对于订单事件，可以通过订单号+事件类型作为唯一标识，消费前先检查是否已处理。
如果业务状态允许，状态机本身也是很好的幂等保障。例如已支付状态再次收到支付成功消息，系统应识别为重复事件并直接忽略。
6. JWT 与 Spring Security 的配合
JWT 负责携带身份信息和声明，Spring Security 负责过滤请求、解析 token、完成认证和授权。支付场景中，除了基础登录态，还应加入更严格的二次验证、设备风控和行为校验。
对于踢下线和失效控制，通常需要结合 token 黑名单、短有效期 token + refresh token，或者在服务端维护会话状态。单靠无状态 JWT 在强踢下线场景里并不够灵活。
7. 风控规则引擎设计
风控系统要强调规则可配置、可审计、可解释。可以把规则抽象为金额阈值、频次限制、IP 黑名单、设备异常、地理位置异常等，并支持动态加载和灰度发布。
业务上，风控规则不能只给出“拒绝/通过”，还应该告诉运营和审核人员命中的规则是什么、命中原因是什么、证据链是什么。这样才能支持事后追溯和人工复核。
8. Prometheus、Grafana、Micrometer 与链路追踪
Micrometer 负责在 Java 应用里统一暴露指标，Prometheus 负责拉取和存储指标，Grafana 用于可视化展示。对于支付链路，需要重点监控接口耗时、错误率、Kafka 堆积、数据库连接池使用率和外部调用成功率。
Jaeger 或 Zipkin 用于链路追踪，能帮助定位一次支付请求在多个服务间的耗时分布。大厂场景里，指标、日志和链路追踪要联合使用，才能快速排障。
9. Spring AI、RAG、Agent 的区别
Spring AI 是在 Java 生态中对接大模型的基础框架，便于调用模型、管理提示词、接入工具和处理会话。RAG 是检索增强生成，通过“先检索知识，再生成答案”降低幻觉。Agent 则更进一步，强调模型可以根据目标自主规划并调用工具完成任务。
电商导购助手中，RAG 适合回答商品规格、活动规则、售后政策；Agent 更适合执行“帮我查订单并改地址”这类多步骤任务。
10. 向量化、语义检索与向量数据库
企业文档问答的第一步是文档加载与切分，然后使用 embedding 模型把文本转为向量，存入向量数据库。用户提问时，把问题向量化后做最近邻检索，召回相似片段，再交给大模型生成答案。
向量数据库可以选 Milvus、Chroma 或 Redis 向量能力。关键不只是“能搜到”，更要控制切分粒度、召回质量、重排策略和权限过滤，避免把不该给用户看的内容返回出来。
11. 如何降低 AI 幻觉
降低幻觉的关键在于限制模型自由发挥：一是尽量让回答基于检索到的企业知识；二是设置置信度阈值，低置信度时转人工；三是把高风险操作改成工具调用，由系统返回事实结果；四是对回答内容做规则校验。
在客服和售后场景里，宁可保守回答，也不要编造政策。幻觉一旦落到真实业务里，可能直接造成投诉或损失。
12. 复杂工作流与工具调用标准化
复杂工作流通常包含意图识别、权限验证、数据查询、状态变更和通知多个步骤。最佳实践是把模型放在“决策层”，把业务系统放在“执行层”。模型负责理解用户意图和选择工具，真正的写操作由确定性的业务接口完成。
工具调用标准化的好处是，模型切换、供应商切换、接口扩展时，业务影响较小。对于企业协同、物流、金融等场景，这种架构特别重要。
感谢阅读，希望这篇文章能帮助大家更好地理解 Java 大厂面试中的技术深挖方式，也希望能对正在准备面试的你有所帮助，祝大家面试顺利，拿到理想 offer！
