互联网大厂 Java 面试：电商即时下单与秒杀系统的三轮深挖

场景：某互联网大厂正在招聘 Java 后端工程师，候选人燕双非坐在面试官对面，准备迎接一场围绕电商场景、支付链路、库存一致性与系统高可用的面试。

第一轮：基础能力与业务链路

面试官：你先说说，秒杀活动开始前，系统为什么通常要做预热？

燕双非：这个……预热就是先把热点商品信息、库存和页面资源提前准备好，避免活动一开始把数据库直接打爆。比如用 Redis 先缓存商品详情，用 CDN 或静态化页面减轻压力。

面试官：回答得不错，说明你知道“削峰填谷”的思路。那如果下单请求同时很多，Spring Boot 这层你会怎么设计接口？

燕双非：嗯……我会做限流、幂等和参数校验。接口层先用 Spring MVC 接收请求，再加上校验注解和统一异常处理。高并发的话，可以先把请求挡在网关或者入口层。

面试官：那库存扣减你会放在数据库里直接减，还是先走缓存？为什么？

燕双非：一般不会直接每次都打数据库。会先用 Redis 预扣减，成功后再异步落库，减少数据库压力。不过要处理一致性，不然可能出现超卖。

面试官：可以，至少方向是对的。那你说说，JVM 在这种高并发接口里，最容易出什么问题？

燕双非：呃……可能是 GC 频繁、对象创建太多、线程池配置不合理吧。比如大量 JSON 反序列化，短命对象很多，就会导致 Young GC 比较频繁。

第二轮：分布式事务、消息与缓存协同

面试官：如果用户下单后要扣库存、写订单、发优惠券、发短信，这一串怎么保证最终一致性？

燕双非：这个通常会用消息队列，比如 Kafka 或 RabbitMQ。下单成功后先落订单，再发消息给库存、营销、通知服务，各服务异步消费。失败的话就重试，必要时做补偿。

面试官：那你怎么避免消息重复消费？

燕双非：嗯……可以做消费幂等，比如用订单号作为唯一键，数据库加唯一索引，或者消费前先查 Redis 标记。总之不能让同一条消息把库存扣两次。

面试官：如果库存服务是用 MyBatis + HikariCP 访问数据库，你会怎么写扣减 SQL？

燕双非：会写成带条件的更新，比如 update stock set available = available - 1 where sku_id = ? and available > 0。这样可以在数据库层防止超卖。HikariCP 负责连接池，性能和稳定性也比较好。

面试官：很好。那 Redis 在这个链路里除了库存缓存，还能干什么？

燕双非：可以做热点商品详情缓存、用户限购标记、分布式锁、秒杀资格校验、以及活动开始前的倒计时状态。还可以用 Spring Cache 包一层，但核心秒杀逻辑通常还是自己控制更清晰。

面试官：如果缓存和数据库不一致了，你怎么排查？

燕双非：这个……一般看是先删缓存还是先改库的问题。可能是缓存双写顺序、消息延迟或者补偿失败。排查时会结合日志、监控和消息消费记录，确认是哪一段链路出了问题。

第三轮：可观测性、风控与系统演进

面试官：大促期间你怎么监控这个系统是否健康？

燕双非：会用 Prometheus + Grafana 看 QPS、RT、错误率、JVM 指标，还会接入 Micrometer 统一采集指标。日志方面用 SLF4J + Logback，方便做链路排查。

面试官：如果要定位一次下单慢请求，你会怎么做？

燕双非：可以加链路追踪，比如 Zipkin 或 Jaeger，查看请求经过网关、订单、库存、支付各服务的耗时。再结合日志和慢 SQL 分析，找出瓶颈。

面试官：支付成功后怎么防止重复通知、重复回调？

燕双非：支付回调一定要做签名校验、幂等处理和状态机控制。比如订单状态只能从待支付变成已支付，重复回调时直接返回成功，不重复更新。

面试官：最后一个问题，如果未来你们要从传统同步接口演进到更灵活的智能客服下单助手，你觉得 Java 侧会引入哪些 AI 能力？

燕双非：可以用 Spring AI 对接大模型，结合 RAG 做企业商品文档和售后政策检索，再加 Agent 去调用查询库存、创建订单、查询物流等工具。还要注意提示填充、向量化、语义检索，以及控制 AI 幻觉，不然客服会一本正经地胡说八道。

面试官：嗯，思路还算完整。今天先到这里，你回家等通知吧。

问题详解：结合电商场景理解技术点

1. 为什么秒杀要预热？

秒杀的本质是将瞬时流量从数据库和核心服务中“挪走”。预热通常包括商品详情缓存、活动页静态化、库存预加载、限流规则准备、热点数据本地缓存等。这样能减少活动开始瞬间对数据库、缓存和线程池的冲击。

2. Spring Boot 接口层应如何应对高并发？

常见做法是：参数校验、统一异常处理、幂等设计、限流降级、接口鉴权、请求追踪。Spring MVC 负责同步请求入口，Spring Boot 负责快速搭建与自动配置。更高压力场景下，网关层或边缘层还会做削峰。

3. 为什么库存扣减常用 Redis 预扣减 + 数据库落库？

Redis 适合高并发读写与原子操作，可先做预扣减，避免大量请求直接打数据库。随后通过消息队列异步落库，降低主链路耗时。但必须处理一致性、补偿和幂等问题，否则容易出现超卖或库存丢失。

4. JVM 在大促场景常见问题是什么？

最常见的是 GC 压力大、对象分配过快、线程竞争、内存泄漏和接口响应抖动。大量 JSON 序列化/反序列化、日志打印、临时集合对象，都会增加年轻代回收频率。通常需要结合 JVM 参数、对象复用、线程池治理和压测来优化。

5. 分布式事务如何落地？

电商订单链路通常不推荐强一致分布式事务，而更常用最终一致性方案：消息队列、事务消息、可靠消息本地表、补偿任务、状态机、SAGA 思路等。关键是每个服务都要支持幂等和重试。

6. 如何设计幂等？

常见方式包括唯一业务键、数据库唯一索引、幂等表、Redis 去重标记、状态机约束等。比如支付回调时，订单状态只能向前流转，重复回调不会重复扣款或重复发货。

7. MyBatis + HikariCP 扣减库存为什么常写条件更新？

因为条件更新可以把并发安全性放在数据库层：只有库存大于 0 时才扣减成功。相比先查再改，条件更新更简洁，也更能避免并发下的竞态问题。HikariCP 则提供高性能连接池，适合高并发访问。

8. Redis 除了缓存还能做什么？

还可以做分布式锁、限购标记、验证码、会话存储、排行榜、消息通知、计数器和热点数据预计算。电商场景里，Redis 常常是“高并发中转站”。

9. 如何排查缓存与数据库不一致？

重点看：更新顺序是否正确、缓存失效是否成功、消息是否丢失、补偿是否执行、是否存在延迟双删或双写竞态。结合日志、指标、消息堆积情况和数据库变更记录，才能定位问题。

10. 可观测性为什么重要？

大促和秒杀中，系统问题往往不是单点故障，而是链路局部变慢。Prometheus、Grafana、Micrometer、SLF4J、Logback、Zipkin、Jaeger 能帮助你快速定位性能瓶颈、错误分布和请求路径。

11. 支付回调为什么必须幂等？

支付平台通常会重试回调，网络抖动也可能造成重复请求。服务端必须通过签名校验、订单状态判断、唯一流水号、状态机控制，确保同一笔支付不会重复生效。

12. AI 能力如何融入电商系统？

可使用 Spring AI 对接大模型，结合 RAG 检索商品文档、售后政策、活动规则；通过 Agent 调用库存、订单、物流等工具；用向量数据库存储商品知识，结合语义检索提升问答准确率。企业落地时要重点防止 AI 幻觉，保证回答可追溯、可校验。

感谢阅读，希望这篇文章能帮助你在 Java 面试中更好地理解电商高并发、分布式一致性、可观测性和 AI 结合的核心问题，也希望能对大家的求职准备带来实际帮助。