电商场景下的Java面试实战从 Spring Boot 微服务到 Kafka、Redis、AI RAG一、故事开场互联网大厂 Java 面试现场场景某互联网大厂电商事业部招聘 Java 后端工程师主做「商品与交易中台 AI 推荐」方向。人物面试官老周——架构师技术严谨问题循序渐进兼顾业务和工程实践。候选人小Y——号称“全栈高级工程师”实则有点水但基础还可以回答时经常东一榔头西一棒槌。时间下午三点会议室门缓缓打开——老周小Y是吧坐。我们今天就围绕电商场景聊聊 Java 技术栈三轮提问轻松一点但尽量说清楚好吗小Y没问题我在简历上写的都很熟心里希望别问得太细……二、第一轮商品服务化与基础微服务设计4 问场景背景电商平台要建设「商品中台」统一管理商品、类目、库存为多个前台业务商城 App、营销活动、渠道分销提供服务。问题 1如何用 Spring Boot 设计一个基础的商品服务老周假设你负责一个商品服务product-service对外提供商品查询接口。请你从技术选型和基本设计说说用什么框架、怎么划分模块、典型的接口怎么定义小Y这个简单我就用 Spring Boot随便建几个 Controller、Service、DAO 就完了嘛然后用 MyBatis 查数据库就好……老周嗯方向是对的但“随便”不太行细一点你会怎么拆小Y呃……就一个商品 Controller然后查商品表……然后呃返回 JSON……老周点点头好至少知道要用 Spring Boot MyBatis REST 接口我们待会儿帮你补完细节。问题 2商品服务与类目服务如何在 Spring Cloud 微服务体系中协同老周商品不仅要查自身信息还要查类目、品牌、标签等。假设你有商品服务和类目服务两套微服务基于 Spring Cloud你会怎么做服务发现与调用小Y微服务嘛用 Spring Cloud 就上了。可以用 Eureka 做注册中心然后商品服务去调用类目服务……用 RestTemplate 或者 OpenFeign反正就是一个服务调另一个服务。老周听起来有实践过。那如果 Eureka 下线了或者我们用 Kubernetes 呢小Y呃……那就用 K8s 的 service 发现我知道有 Spring Cloud Kubernetes……具体就嗯我还得再看下文档。老周好至少知道几个关键词我们后面系统梳理一下服务发现方案和演进。问题 3商品查询如何设计缓存策略Redis 与本地缓存老周商品查询是高频接口。我们一般会用Redis 本地缓存比如 Caffeine做多级缓存。你能说说为什么要多级缓存在 Spring Boot 中你会如何实现小Y多级缓存是为了更快……本地缓存比 Redis 快嘛。实现的话可以用 Spring Cache配 Redis 做底层缓存Caffeine 做本地缓存。读的时候先查本地没有就查 Redis再没有就查数据库。老周不错思路是对的。如果要考虑缓存一致性和热点商品防击穿呢小Y一致性就加个过期时间热点商品可以预热具体方案我大概知道有什么缓存穿透、雪崩、击穿但细节有点模糊……老周好的基础认知可以细节我们后面讲给你听。问题 4如何设计商品服务的 API 规范与文档Swagger/OpenAPI老周我们有多个前端和 B 端系统要接商品服务。你会怎么用Swagger/OpenAPI来设计和维护接口规范小YSpringfox 现在不太用了我看很多项目用 springdoc-openapi可以自动生成 Swagger 文档。只要在 Controller 上写好注解就能在 /swagger-ui.html 或者 /doc 接口那里看到文档。老周那如果要对接外部合作方需要导出 OpenAPI 规范 JSON、自动生成客户端你会怎么做小Y呃……我知道可以生成 OpenAPI 的规范文件然后……可能用一些代码生成工具去生成 Java 客户端我以前没深用过。老周行知道 OpenAPI 的作用算及格细节稍微欠一点。三、第二轮订单、支付与消息队列5 问场景背景用户在 App 下单涉及订单服务、库存服务、支付服务以及异步消息Kafka/RabbitMQ。要求支持大促高并发且要保证数据一致性。问题 5下单流程中如何设计订单服务的领域模型与持久层老周用户下单一般会产生订单主表、订单明细、优惠记录等。你用JPA / MyBatis / Spring Data怎么设计这些表和持久层简要说说你的方案。小Y呃……我一般直接 MyBatis写几个 mapper 和 XML。订单主表一个表明细一个表。Spring Data JPA 我知道但不太常用。领域模型嘛就搞几个 Java 对象对应这些表……老周那比如订单状态有很多待支付、已支付、已取消、部分退款、全额退款……你会怎么组织枚举与状态机小Y就一个 enum……状态多就再加几个常量呗。状态机这个我还没在项目里做过。老周好的说明你更多停留在表结构与 CRUD 层面领域建模这块我们后面详细讲。问题 6订单与支付服务之间的调用与幂等设计老周用户支付过程中会涉及订单服务创建订单支付服务创建支付单支付网关回调订单状态更新在这个流程中如何通过幂等性设计避免多次回调、重复支付问题小Y幂等就是同一个请求多次调用结果一样嘛。支付回调一般带一个订单号或支付号我们可以在数据库里加个字段记录是否处理过如果处理过就直接返回成功。还可以用 Redis 做一个去重键比如pay:callback:{orderId}之前处理过就不再处理。老周不错那如果订单服务和支付服务之间通过 Kafka 做异步通知呢如何保证不重复消费小YKafka 我知道有 consumer group可以用消息的 key 或者 offset 做控制具体怎么做……我大概知道可以在业务层做幂等校验但没系统总结过。老周好我们后面详细讲 Kafka 的消费幂等实践。问题 7秒杀场景下如何用 Redis Kafka 保护数据库老周假设我们有一个秒杀场景几万人抢几百件商品。说说你会如何用Redis Kafka构建一个保护数据库的高并发架构小Y这个我看过很多文章用 Redis 预扣库存用户下单先写 Redis不直接写数据库然后把订单请求写入 Kafka后端有一个消费者慢慢读 Kafka 消息再写数据库这样数据库压力就低了。具体细节……比如防止超卖、保证最终一致性我知道有一些 Lua 脚本之类的但没实际实现过。老周可以至少理解到“读写分层、削峰填谷”的思想。问题 8使用分布式事务时如何权衡性能与一致性老周订单与库存、优惠券之间经常会有跨服务事务。有的团队用Seata / TCC / Saga有的则采用最终一致性。你觉得在大促高并发场景下怎么在性能与一致性之间做权衡小Y呃……我知道分布式事务会很影响性能所以很多公司不用强一致。像 TCC 比较重可以用本地事务加消息做最终一致性。具体怎么权衡一般看业务是不是特别敏感比如金额类要更严一点……老周嗯理解得比较抽象但方向没错。问题 9订单日志与监控如何落地ELK、Prometheus、Grafana老周大促期间订单量巨大出问题要迅速排查。你会如何使用Logback/SLF4J ELK采集日志又如何利用Micrometer Prometheus Grafana做监控和告警小Y我一般用 Logback 配日志格式然后发到 ELK。监控的话用 Micrometer 自动暴露 /actuator/prometheus然后 Prometheus 拉取时间序列数据Grafana 配可视化和告警。细节上比如哪些指标要监控我知道要看 QPS、错误率、延迟……但没搭过很复杂的图。老周不错这个回答算比较实用了。四、第三轮推荐、风控与 AI RAG 智能客服4 问场景背景平台要做个性化推荐和智能客服系统结合大数据与 AI解决用户商品推荐、售前问答、售后问题咨询等同时要做风控识别欺诈订单、薅羊毛行为。问题 10如何用 Elasticsearch 推荐服务进行商品搜索与排序老周用户在搜索框输入“运动鞋”我们需要用Elasticsearch做匹配和检索用推荐服务做个性化排序你能描述一下这个流程的整体架构吗小Y呃……用户请求到后端后端先调 Elasticsearch 查出一批候选商品然后再把这些商品 ID 给推荐服务让推荐服务根据用户特征打分排序。推荐服务可能用 Flink 或 Spark 做离线特征或者实时计算然后返回排序结果……具体细节比如怎么建索引、怎么设计倒排我只是知道概念……老周整体思路还可以说明你接触过相关资料。问题 11风控服务如何通过 Kafka Flink 进行实时风险分析老周对欺诈订单我们一般会采集用户行为和订单数据写入 Kafka用 Flink 流计算进行实时风控你能说说这个数据流的关键环节吗小Y数据从业务系统写到 Kafka 的 topic然后 Flink 从 Kafka 消费做各种规则计算比如同一设备、同一 IP 短时间下很多单。然后 Flink 把结果写回到 Redis 或数据库业务系统在下单时再查风控结果。具体 Flink 的窗口、状态管理我知道词但不熟……老周好至少知道 Kafka Flink 是一条典型数据链路。问题 12如何用 RAG 和 Agent 做智能客服系统老周我们现在想做一个智能客服系统用户问“这款运动鞋适不适合跑步”或“我退款怎么走流程”你觉得用RAG检索增强生成 Agent该怎么设计小YAI 这块我最近在看RAG 就是先从知识库里检索相关文档再让大模型结合这些文档回答问题这样可以减少幻觉Agent 就是让模型能拆任务、调用工具比如查询订单 API、查物流 API智能客服的话可以把商品详情、使用场景、售后政策都放到向量数据库比如 Milvus 或 Redis Search然后问问题时先语义检索再把结果给模型回答。Agent 则可以在需要的时候帮用户查订单、发起退款……具体框架我知道有 Spring AI、MCP、Agentic RAG但没自己从零搭过一个完整系统。老周这个回答不错至少理解了 RAG 与 Agent 的核心价值。问题 13如何减少 AI 幻觉并做好业务安全与风控老周智能客服如果胡说八道答错退款规则、乱给优惠会出大问题。你觉得在业务安全与风控方面如何减少 AI 幻觉并把风险控制住小Y我看过一些文章要用检索增强尽量让模型只在我们提供的文档和接口范围回答要做工具调用的严格权限控制不能让模型随便改数据对关键操作要有人类审核比如退款、优惠券发放还可以做一些规则校验让模型的回答经过业务规则过滤细节比如怎么在生产做好审核流程我理解不太深只是知道有这些点。老周很好说明你有业务安全意识这点很重要。五、面试结束回家等通知老周今天聊了商品服务、订单与支付、高并发秒杀、日志监控以及推荐、风控和 AI 智能客服。你基础还可以但很多地方停留在概念层面工程细节需要再打磨。小Y紧张那我……还有机会吗老周我们会综合评估你回去再系统学习一下这些场景和技术栈。结果会通过邮件通知你无论如何这次当作一次很好的复盘。辛苦了。小Y好的谢谢周哥心想得赶紧把今天问到的东西全查一遍……六、面试问题标准答案与场景拆解给小白看的系统讲解下面按问题顺序对每个问题给出更严谨的参考答案帮助你系统理解业务场景与技术点。1. Spring Boot 商品服务设计业务场景商品服务是电商的基础中台为商城、营销、分销等前台提供统一商品数据典型功能商品查询、类目查询、库存占用、上下架、价格策略技术选型核心框架Spring BootWebMVC、Spring Data / MyBatis构建工具Maven / Gradle数据源与连接池HikariCPORMMyBatis 或 JPA Spring Data缓存Redis Spring Cache文档springdoc-openapi Swagger UI典型分层controller层暴露 REST 接口/api/productsservice层业务逻辑如校验上下架状态、拼装类目信息repository/mapper层数据库访问domain层领域模型Product,Category,Sku等示例接口设计GET /api/products/{id}查询单个商品详情GET /api/products分页查询商品列表支持类目、品牌、价格区间过滤使用 DTO 对外返回避免直接暴露数据库实体2. Spring Cloud 微服务协同商品服务与类目服务服务发现方案传统 Spring CloudEureka / Consul / Zookeeper 做注册中心服务启动时向注册中心注册自身地址客户端通过服务名category-service访问而不是写死 IPKubernetes 环境利用 K8s 的Service和 DNS 发现http://category-service可配合 Spring Cloud Kubernetes / Fabric8 Kubernetes Client服务调用方式OpenFeign声明式 HTTP 客户端RestTemplate/WebClient手写 HTTP 调用示例 Feign 客户端FeignClient(name category-service) public interface CategoryClient { GetMapping(/api/categories/{id}) CategoryDTO getCategory(PathVariable Long id); }商品服务在领域层组合类目信息而不是直接走 SQL join以保持服务边界清晰。3. Redis 本地缓存的多级缓存设计为什么多级缓存本地缓存在 JVM 内存中访问速度极快适合热数据、短 TTLRedis跨节点共享适合集群环境、较大容量多级缓存可以减少 Redis 压力、降低网络延迟典型实现方式使用 Spring Cache 抽象底层配置 Caffeine / Ehcache 作为本地缓存配置 RedisCacheManager 作为分布式缓存或者自行实现“本地 Redis”双读写逻辑缓存一致性与防击穿读流程查本地缓存本地不存在查 RedisRedis 不存在查数据库并回写缓存为防缓存穿透对不存在的数据也缓存一个“空值”设置较短 TTL为防缓存击穿对热点 Key 设置互斥锁Redis 分布式锁避免高并发下同时回源数据库为防缓存雪崩避免大批量 Key 在同一时间过期TTL 加随机因子4. Swagger/OpenAPI API 规范管理目的统一对内对外的 API 规范自动生成文档便于前端和合作方对接可以导出 OpenAPI JSON/YAML做代码生成或接口 MockSpring Boot 实践使用 springdoc-openapi引入依赖后自动扫描 Controller通过注解Operation,Parameter记录接口说明、参数、返回体提供/swagger-ui.html或/docs等路径的文档界面对外合作方导出 OpenAPI 规范JSON/YAML合作方可以使用 Swagger Codegen 或 OpenAPI Generator 生成客户端 SDK5. 订单服务的领域模型与持久层设计核心表order订单主表id,user_id,status,total_amount,created_at...order_item订单明细表order_id,product_id,sku_id,price,quantity...order_discount/coupon_usage优惠、满减、积分等记录领域模型Order聚合根包含订单明细集合OrderStatus枚举CREATED,PAID,CANCELLED,PARTIALLY_REFUNDED,FULLY_REFUNDED…可以引入一个简单状态机定义合法的状态迁移如CREATED - PAID禁止CANCELLED - PAID持久层技术MyBatis显式 SQL适合复杂查询和精细控制JPA Spring Data适合快速开发、简单 CRUDSpring Data JDBC更轻量兼顾关系型和领域驱动6. 订单与支付的幂等设计典型风险支付网关重复回调用户重复点击支付按钮消息重复投递 / 消费幂等策略利用业务唯一键out_trade_no商户支付单号或orderId作为幂等 key支付结果处理时先检查数据库中该 key 是否已经标记处理过数据库防重复唯一索引 INSERT IGNORE或乐观锁Redis 防重复SETNX写入一个处理标志pay:callback:{outTradeNo}带过期时间若已经存在则丢弃本次处理Kafka 幂等消费在消费端对业务主键做“处理记录”表如processed_messages每次消费先查是否处理过该消息 ID 或业务键7. 秒杀场景的 Redis Kafka 高并发架构核心目标保护数据库免受突发高并发冲击防止超卖与数据错乱典型架构预热阶段将秒杀商品库存加载到 Redisstock:{skuId}用户请求阶段入口层使用 Nginx/LB 限流策略应用层快速校验登录、活动时间、黑名单使用 Redis 的原子操作DECR, Lua 脚本预扣库存请求写入 Kafkaseckill-orderstopic不直接写数据库后台处理阶段专门的订单写入服务消费 Kafka 消息写数据库订单表 减真实库存处理失败需要补偿机制如死信队列、人工排查这种设计利用 Redis 和 Kafka 做“削峰填谷”将瞬时高并发变成可控的后台队列处理。8. 分布式事务的性能与一致性权衡强一致方案Two-Phase Commit2PC、XA、Seata AT 模式优点事务语义简单、开发成本低缺点性能较差、对资源管理器要求高容易成为瓶颈柔性 / 最终一致方案TCC / Saga 模式TCCTry/Confirm/Cancel 三阶段接口对业务侵入较大Saga长事务拆成多个本地事务失败时通过补偿操作回滚本地事务 可靠消息利用事务消息或事件表保证跨服务最终一致电商大促实践对金额、支付等强一致要求较高的场景可使用较严格的事务或多重校验对库存、优惠券等则可以接受适当的最终一致配合风控与监控9. 日志与监控ELK Prometheus Grafana日志体系应用层使用 SLF4J Logback/Log4j2统一日志格式JSON输出到文件或直接到 LogstashELKElasticsearch 存储 搜索Logstash 收集和转发Kibana 可视化与检索指标监控Micrometer度量库支持多种监控后端Spring Boot Actuator暴露健康检查、指标端点Prometheus拉取指标如/actuator/prometheusGrafana仪表盘和告警电商关键指标QPS、延迟P95/P99、错误率订单创建成功率、支付成功率Kafka 消息堆积量消费延迟10. Elasticsearch 推荐服务的搜索与排序基本流程用户输入搜索关键字搜索服务通过 Elasticsearch 根据文本、分词、权重等搜索出候选商品推荐服务根据用户画像、行为数据等对候选商品打分排序合并结果返回给前端Elasticsearch 部分为商品建立索引字段包括名称、描述、类目、品牌、价格、标签使用合适的分词器中文分词和权重如名称比描述权重更高推荐服务部分离线计算利用 Spark/Flink 处理行为日志生成用户/商品特征在线服务根据实时上下文当前搜索词、历史浏览、购买历史计算排序分11. Kafka Flink 风控数据流数据流关键环节业务系统埋点和日志收集用户登录、下单、支付行为将结构化事件写入 Kafka topic如risk-eventsFlink 从 Kafka 消费使用窗口时间窗口、计数窗口分析短时间内的行为模式维护状态如同一设备/账号的历史行为应用规则引擎或机器学习模型做风险评分将风险结果写入Redis实时查询数据库或 Elasticsearch审计和分析业务系统在关键流程如下单、提现查询风控结果决定拦截、人工审核或通过12. RAG Agent 智能客服设计RAG检索增强生成将企业文档商品说明、帮助中心、售后政策、内部操作手册进行分段和向量化将向量存储在向量数据库Milvus、Chroma、Redis Search用户提问时使用 Embedding 模型OpenAI、Ollama 等将问题转换为向量在向量库中做语义检索找出相关文档将文档内容作为上下文传给大模型让其基于这些“可靠知识”回答Agent智能代理为大模型配置一组“工具”查询订单 API查询物流状态创建售后工单模型根据用户意图决定是否调用工具并且利用工具返回的实时数据回答框架Spring AI在 Spring Boot 中统一封装模型调用MCP模型上下文协议标准化模型与外部工具、数据源之间的交互Agentic RAG将 RAG 与 Agent 结合既利用文档检索又可调用业务 API 完成复杂任务13. 减少 AI 幻觉与业务风控减少幻觉强制模型基于检索到的文档回答避免凭空编造对关键信息价格、政策从实时 API 获取而非依赖模型记忆在提示prompt中增加约束“不确定时请说明不确定并建议转人工服务”业务风控与安全对 Agent 工具调用做严格鉴权哪些操作允许自动执行哪些必须人工确认对敏感操作退款、增加额度、修改用户信息设置审批流程保留完整审计日志记录模型决策、工具调用、返回结果通过规则引擎对模型输出进行二次校验如不允许输出超过配置的最大退款金额通过这些措施可以在享受 AI 带来的效率提升的同时降低业务风险和合规压力。结语这篇文章以一个电商 Java 面试故事为主线从商品中台到订单支付、高并发秒杀再到推荐、风控和 AI 智能客服串起了 Spring Boot、Spring Cloud、Redis、Kafka、Elasticsearch、Flink 以及 RAG/Agent 等技术栈。希望你不仅能看到“面试知识点”更能理解这些技术在真实业务场景下是如何组合和落地的。