电商实时交易系统 Java 面试实战Spring Boot Kafka Redis Resilience4j Prometheus/Grafana场景互联网大厂电商交易与营销中台面试面试官今天我们围绕“电商实时交易系统”来聊场景会从订单、库存、优惠、风控、监控一路展开。你先别紧张先自我介绍一下。燕双非大家好我是燕双非擅长把“能跑”写成“能上线”把“上线了”写成“稳定了”。第一轮订单下单链路1面试官你用 Spring Boot 设计过高并发下单接口吗从控制器到服务层你会怎么组织代码燕双非会一点。一般就是 Controller 接收参数Service 里做校验、扣库存、创建订单最后返回结果。Spring Boot 比较方便配置少接口也好写。面试官基础思路没问题说明你至少知道分层。那如果订单接口要支持幂等你会怎么做燕双非嗯……我可能会先加个唯一订单号再查一下数据库有没有重复差不多就行吧。面试官方向对但还不够完整后面我们再展开。2面试官下单后要发消息给库存系统你会选 Kafka 还是 RabbitMQ为什么燕双非Kafka 听起来更像大厂标配吞吐高适合发订单事件。RabbitMQ 我印象里比较适合业务路由和复杂消息模式。面试官回答得不错至少能区分吞吐和路由场景。那如果消息重复消费了你怎么处理燕双非……那就消费者里加个去重表或者 Redis set 判断一下面试官可以思路上接近生产做法但要考虑去重窗口和一致性。3面试官库存扣减你会放在 Redis 里做预扣还是直接落数据库燕双非如果是秒杀或者高峰场景先 Redis 预扣比较快再异步落库如果普通交易数据库事务也可以。面试官很好能结合业务场景判断不是所有问题都一刀切。4面试官下单接口如何保证短时间大量请求下系统不被打垮燕双非可以做限流、排队、缓存、异步化还可以加熔断。比如用 Resilience4j 做限流和降级。面试官这个回答比刚才更像一个真正做过线上系统的人。第二轮交易稳定性与数据一致性1面试官订单成功但库存扣减失败怎么保证最终一致性燕双非可以用本地消息表或者事务消息。订单落库后发一条待发送消息后台任务补偿发送。面试官对已经接近生产实践。那如果要更标准一点你会怎么设计状态机燕双非嗯……订单状态可以有待支付、已支付、已取消、已完成。状态流转尽量单向避免乱跳。面试官很好状态机是交易系统的骨架。2面试官你会如何使用 Redis 来提升订单详情查询性能燕双非把热点订单信息缓存起来查缓存没有再查数据库回填 Redis。还可以设置过期时间防止脏数据太久。面试官不错。那缓存击穿、缓存穿透、缓存雪崩分别怎么处理燕双非击穿就加互斥锁穿透可以布隆过滤器雪崩就给 key 加随机过期时间。面试官回答清楚了说明你至少认真背过线上问题。3面试官如果用 Spring Cache 统一管理缓存你会怎么配合 Caffeine 和 Redis燕双非可以做两级缓存Caffeine 做本地缓存Redis 做分布式缓存。热点数据先打本地减少网络开销。面试官可以但要注意缓存一致性和失效通知。4面试官现在很多系统都要求监控下单链路你会埋哪些指标燕双非QPS、RT、错误率、消息堆积量、库存预扣失败率、订单创建成功率。可以用 Micrometer 接 Prometheus再用 Grafana 看板展示。面试官这个挺好已经有一点平台工程思维了。第三轮风控、可观测性与 AI 辅助客服1面试官订单链路里如果要做风控你会怎么设计燕双非可以按用户、设备、IP、支付行为做规则判断比如同一设备频繁下单、异常地域切换、短时间内大量取消等。面试官对规则风控是第一层。那复杂场景下怎么做动态决策燕双非呃……可以上机器学习模型或者把规则配置化面试官可以先规则引擎化再逐步引入模型评分。2面试官如果客服系统要接入 AI 做订单咨询你会怎么设计燕双非可以做一个 Spring AI 的服务结合 RAG把订单 FAQ、退换货政策、物流规则做向量化接向量数据库检索后再生成回答。面试官不错已经不只是会“调大模型”了。那怎么降低 AI 幻觉燕双非限制它只能基于检索结果回答必要时提示“不确定”并且对关键业务做工具调用不让模型瞎编。面试官这点很关键生产里必须控制幻觉。3面试官你如何设计一个支持人工客服接管的智能客服工作流燕双非先让 AI 处理标准问题复杂问题转人工聊天上下文要保留工单要带上会话摘要方便人工快速接手。面试官对聊天会话内存和工具执行框架都要考虑。4面试官最后一个问题线上出了支付回调延迟你怎么排查燕双非先看日志再看链路追踪比如 Zipkin 或 Jaeger结合 Prometheus 指标看是不是消息堆积、数据库慢查询或者第三方通道抖动。面试官思路是对的能从可观测性维度下手。面试官今天先到这儿你回去等通知吧。所有面试问题详解1. Spring Boot 如何组织高并发下单接口典型做法是 Controller 负责入参和返回值Service 负责业务编排DAO 负责数据访问。高并发场景下要特别关注参数校验、幂等控制、事务边界、线程池隔离和异常回滚。电商下单不是简单 CRUD而是“校验用户资格、检查库存、创建订单、发消息、落审计日志”的组合流程。2. 幂等如何设计可使用业务唯一键、请求幂等 token、订单状态校验、分布式锁等方式。生产中常见的是“客户端生成请求号 服务端幂等表/唯一索引 状态机约束”避免重复提交、重复扣库存、重复发消息。3. Kafka 和 RabbitMQ 如何选择Kafka 更适合高吞吐、事件流、日志型消息和削峰填谷RabbitMQ 更适合复杂路由、低延迟业务消息和灵活投递模式。订单事件、埋点、行为流更偏 Kafka订单状态变更通知、精细路由补偿可能更适合 RabbitMQ。4. 消息重复消费怎么处理消息队列通常至少一次投递因此消费者必须幂等。常见方案有数据库唯一约束、消费日志表、Redis 去重标记、业务状态判断。关键不是“避免重复”而是“重复了也不出错”。5. Redis 预扣库存为什么常见因为 Redis 读写快适合在秒杀、抢购、促销场景中先做快速拦截减少数据库压力。通常先在 Redis 中原子扣减再异步落库如果落库失败要靠补偿机制修正最终库存。6. 如何处理缓存击穿、穿透、雪崩击穿热点 key 失效导致大量请求打到 DB可用互斥锁或逻辑过期。穿透请求不存在的数据可用布隆过滤器或缓存空值。雪崩大量 key 同时失效可给过期时间加随机值、做多级缓存、限流降级。7. Caffeine Redis 两级缓存有什么价值Caffeine 是本地缓存访问极快适合热点数据Redis 是分布式缓存适合跨实例共享。两级缓存能降低网络开销和 Redis 压力但需要处理一致性、失效通知和热点漂移问题。8. 交易系统为什么要有状态机订单、支付、退款、发货都有严格状态流转状态机能防止非法跳转例如“未支付订单不能直接完成”。状态机让业务逻辑更清晰也利于审计、补偿和并发控制。9. 如何保证最终一致性常见方式有本地消息表、事务消息、可靠消息投递、定时补偿、消息确认机制。核心思想是本地事务先成功再异步传播事件如果中间失败要有补偿任务继续推进直到结果收敛。10. Micrometer Prometheus Grafana 怎么用Micrometer 负责统一度量指标埋点Prometheus 负责采集和存储时序指标Grafana 负责可视化。电商系统常监控 QPS、RT、错误率、消息堆积、订单成功率、支付回调延迟、库存失败率等。11. 风控系统怎么设计第一层规则先做规则风控同设备频繁下单、同 IP 异常行为、异常地域切换、短时间重复支付失败等。规则层简单直接响应快适合作为实时拦截的第一道防线。12. AI 客服如何结合 RAGRAG 的核心是“先检索再生成”。把 FAQ、政策、工单知识库、订单操作文档做文档加载、切分、向量化存入向量数据库用户提问后先语义检索再把命中文档拼进提示词让模型基于证据回答。13. 如何降低 AI 幻觉限制模型只能引用检索结果、对高风险问题强制工具调用、对关键信息加入校验、对未知回答“不确定”。生产中还要对回答做审计、打分和人工兜底避免模型胡编订单状态、退款金额等敏感信息。14. 智能客服如何支持人工接管需要保留会话内存、摘要、用户上下文和已执行工具结果。AI 先处理标准问答复杂问题转人工人工接手时可看到完整历史避免重复问用户。15. 出现支付回调延迟怎么排查先看日志再看链路追踪再看指标。重点检查第三方支付通道、消息堆积、数据库慢 SQL、线程池耗尽、网络抖动和限流规则。排查顺序一般是现象确认、定位入口、拆分链路、回放请求、验证瓶颈。以上内容围绕电商实时交易系统从下单、库存、消息、缓存、监控、风控到 AI 客服串起了 Java 面试中最常见也最容易追问的关键点。希望这篇内容能帮助你在面试中把握节奏、讲清思路、答出深度。感谢阅读希望能真正帮助到大家。