Java 大厂面试实录：电商秒杀系统中的 Spring Boot、Redis、Kafka、Spring Security 与 Observability

场景：某互联网大厂电商中台团队，候选人燕双非前来面试后端 Java 岗位。面试官风格严肃，问题围绕高并发秒杀、订单支付、风控告警、异步解耦与可观测性展开。

第一轮：基础与高并发入口

面试官：先说说 Java 17 相比 Java 8，在你做高并发电商服务时，最值得关注的变化是什么？

燕双非：嗯，最大的感受就是语法更顺手，像 switch 表达式、文本块这些挺方便，另外 JDK 17 性能也更好，GC 也更先进，平时写代码会更舒服。

面试官：说得不错，语法和运行时提升都能影响工程效率。那如果我们用 Spring Boot 做秒杀网关，为什么你会优先考虑统一入口做限流和鉴权？

燕双非：因为入口最容易爆，先在网关挡住一部分流量，不然后面的库存、订单、支付全会被打穿。鉴权也能提前把非法请求过滤掉。

面试官：对，先把“坏流量”挡在外面是很实用的。那你觉得 Redis 在秒杀场景里主要承担什么职责？

燕双非：缓存热点商品信息、库存预扣、分布式锁，还有用户是否已经抢过之类的标记，减少数据库压力。

面试官：思路基本对，不过“库存预扣”和“防重复下单”要分开设计，别把一个 Redis key 当万能药。

第二轮：异步解耦与安全风控

面试官：秒杀请求进来后，如果直接同步创建订单，为什么通常不推荐？

燕双非：因为同步链路太长，库存、订单、优惠券、风控、支付都串起来，容易超时，也容易把数据库打崩。一般会先返回“已受理”，再异步处理。

面试官：很好。那这里如果用 Kafka 做异步消息，你会关注哪些关键点？

燕双非：我会关注消息是否丢失、重复消费、顺序问题，还有消费失败后的重试和死信队列。最好订单消息能幂等处理。

面试官：回答得像样。那如果风控团队要求“同一设备短时间内多次下单要拦截”，Spring Security 能直接解决吗？

燕双非：Spring Security 主要还是认证授权，设备风控更像业务规则，要结合 JWT、用户画像、Redis 计数和风控策略引擎一起做。

面试官：对，这个区分很重要。那 JWT 放在电商系统里，适合放哪些信息，不适合放哪些信息？

燕双非：适合放用户标识、角色、过期时间这些不敏感信息；不适合放密码、支付信息之类敏感内容，因为 JWT 本质上不是加密，只是签名。

面试官：回答可以，至少没把 JWT 当保险箱。

第三轮：可观测性、支付闭环与故障排查

面试官：假设大促时订单创建成功率突然下降，你怎么用 Prometheus、Grafana、Micrometer 去定位问题？

燕双非：先看接口 QPS、P95、错误率，再看消息堆积、Redis 命中率、数据库连接池和线程池状态。如果某个指标异常，就沿着链路追踪对应服务。

面试官：继续说，如果你发现订单服务 CPU 不高，但响应时间很长，可能是什么原因？

燕双非：可能是线程在等外部调用，比如支付网关、库存服务，或者数据库锁等待；也可能是 Kafka 消费积压，导致业务间接变慢。

面试官：不错。那你会如何设计支付回调接口，避免重复回调导致重复发货？

燕双非：做幂等校验，按支付流水号和订单号做唯一约束；回调接口先落库记录状态，再执行后续逻辑，重复请求直接返回成功。

面试官：可以。最后一个问题：如果让你补一套链路追踪，你会优先接入什么？

燕双非：我会先接入日志统一 traceId，再结合 Jaeger 或 Zipkin 做分布式链路追踪，关键接口加上埋点和异常告警。

面试官：行，今天先到这里，你回家等通知吧。

详细解析：所有问题的业务场景与技术要点

1. Java 17 相比 Java 8 的价值

在电商秒杀、订单、支付等核心系统中，Java 17 更适合承载新项目：语法更简洁，JVM 运行时和垃圾回收策略也更成熟。实际工程里，升级版本通常带来更好的可维护性与性能收益。

2. Spring Boot 统一入口与限流鉴权

秒杀系统最怕流量洪峰直接冲击后端。统一入口可以做：鉴权、黑名单、限流、灰度、请求校验、签名验证。这样能把无效流量挡住，减少核心服务压力。

3. Redis 的核心职责

Redis 在高并发电商中常用于热点缓存、库存预扣、防重复下单、验证码校验、会话缓存等。但它不是数据库替代品，库存扣减、订单落库仍要依赖数据库做最终一致性保护。

4. 秒杀链路为什么要异步化

同步链路越长，越容易超时和放大故障。异步化后，入口只负责快速接单，后续的订单创建、优惠计算、发货、积分等动作交给消息队列处理，吞吐更高，也更容易削峰填谷。

5. Kafka 关注点：丢失、重复、顺序、重试

生产中常见的设计是：生产端确认、消费端幂等、失败重试、死信队列补偿、必要时分区保证局部顺序。对于订单类消息，幂等是第一原则，因为消息“至少一次”投递非常常见。

6. Spring Security 与业务风控的边界

Spring Security 解决的是认证和授权，比如用户是否登录、是否有权限访问某接口。设备风控、行为风控、异常订单识别属于业务安全能力，需要结合 JWT、Redis、规则引擎、风控模型综合实现。

7. JWT 的使用边界

JWT 适合承载不敏感、可验证的身份信息，例如 userId、role、exp。它是签名令牌，不等于加密存储。敏感数据必须避免放入 JWT，必要时还要结合短期有效期和刷新机制。

8. 指标监控与故障定位

Prometheus 负责采集指标，Grafana 负责展示，Micrometer 负责在应用中统一埋点。排障时一般看：QPS、错误率、P95/P99、线程池、连接池、缓存命中率、消息堆积和数据库慢查询。

9. 高响应时间但低 CPU 的原因

这通常说明系统不是“算不过来”，而是“等得太久”。可能在等数据库锁、远程 HTTP 调用、RPC、消息消费、磁盘 IO 或连接池资源。要结合链路追踪和线程栈分析定位。

10. 支付回调幂等设计

支付回调常常会重复到达，因此必须通过唯一流水号、订单状态机、数据库唯一索引和幂等表来兜底。处理逻辑一般是：先记录回调，再更新订单状态，再做后续发货或通知。

11. 链路追踪与 traceId

统一 traceId 能把一个请求在多个服务、多个线程、多个消息消费环节串起来。配合 Jaeger/Zipkin，可以更直观地发现延迟发生在哪里，尤其适合微服务和异步系统。

总结

电商高并发场景下，Java 后端的核心能力不只是“会写接口”，还要能把入口治理、缓存、异步消息、安全、幂等、监控和链路追踪串成一套完整方案。只有把业务和技术一起理解，才更像一名真正能打的大厂后端。

感谢阅读，希望这篇文章能帮助你在 Java 面试中更从容地回答高并发电商相关问题，也希望能对你的技术成长有所帮助。