Java 面试实战：Spring Boot + Kafka + Redis + Spring Security 在电商场景下的 3 轮深入拷问

面试官：今天我们聊一个电商大促场景，看看你对 Java 后端技术栈到底掌握到什么程度。

燕双非：来吧，别整太难，我先热个身。

第一轮：基础架构与高并发下单链路

面试官：你用 Spring Boot 搭一个秒杀服务时，如何组织项目结构，避免后期模块越来越乱？

燕双非：嗯……就 controller、service、dao 分层吧，再加点 common、util，基本能跑。

面试官：说得不算深，但方向对。那如果你要接入 Redis 做库存预热和限流，为什么常见做法是把热点数据提前加载到缓存？

燕双非：这样可以减少数据库压力，用户抢购的时候直接读缓存，快一点，不容易把库打爆。

面试官：对，至少你知道缓存是为了扛热点。那你再说说 Kafka 在下单链路里适合放在哪一步？

燕双非：我觉得可以把订单创建后写 Kafka，异步发短信、发券、做埋点，不然主流程太慢。

面试官：这个思路不错，说明你知道解耦和削峰。最后一个问题，Spring Security 在电商系统里通常保护哪些接口？

燕双非：登录、下单、支付，还有后台管理接口吧，反正敏感的都得校验权限。

面试官：可以，至少安全意识是有的。

第二轮：订单一致性、消息可靠性与权限控制

面试官：现在我们把场景升级一下。用户下单后，库存扣减、优惠券核销、积分发放都通过 Kafka 异步处理。如何保证消息不丢？

燕双非：啊，这个……可以多发几次？或者消费者那边补偿一下？

面试官：补偿是思路之一，但你答得有点虚。那我换个问法：生产端、Broker、消费端分别有哪些常见可靠性保障？

燕双非：生产端要等确认，Broker 要落盘，消费端要手动提交 offset……大概这样。

面试官：这就好多了。那如果库存服务处理失败了，怎么避免 Kafka 消息无限重试导致雪崩？

燕双非：可以设置重试次数，超过就进死信队列，后面人工或者定时任务补偿。

面试官：对，继续说。Spring Security 里如果你要做前后端分离的登录认证，JWT 和 Session 各有什么特点？

燕双非：Session 是服务端保存状态，JWT 是客户端带着 token 到处跑。JWT 更适合分布式，但不好主动注销。

面试官：回答得挺到位。那如果电商平台要接入第三方支付回调，你会怎么做签名校验和防重放？

燕双非：校验签名、时间戳、nonce，再加幂等处理，不然同一笔通知来两次就炸了。

面试官：不错，这个你是真的碰过还是看过资料？

燕双非：……都算吧。

第三轮：可观测性、故障排查与面试收口

面试官：最后一轮，假设大促当天接口响应变慢，Redis 命中率正常，Kafka 堆积严重，你会先看哪些指标？

燕双非：我会看 CPU、内存、GC、线程池、Kafka consumer lag，还有下游数据库慢查询。

面试官：很好，说明不是只会写代码。那如果要把这些指标接入 Prometheus 和 Grafana，你会怎么做？

燕双非：Spring Boot 可以接 Micrometer，把自定义指标暴露出去，Prometheus 抓取，Grafana 看图表。

面试官：很好。那你怎么判断是代码问题、配置问题，还是流量突增导致的问题？

燕双非：看发布记录、压测数据、告警时间点，还有链路追踪，比如 Jaeger 或 Zipkin，定位慢在哪一段。

面试官：思路可以。最后一个问题，如果让你设计一个“下单成功后发送站内信 + 短信 + 邮件”的流程，你如何让它既解耦又可恢复？

燕双非：主流程下单成功后发事件到 Kafka，各个通知服务分别消费。消费失败就重试，超过次数进死信，补偿任务兜底。通知状态落库，方便查询和恢复。

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

问题详解

1. Spring Boot 项目结构如何设计

在电商秒杀、订单、支付等场景中，建议按领域和职责拆分模块，而不是简单堆 controller/service/dao。可以按“用户、商品、订单、库存、支付、营销”拆分业务模块，再配合公共基础模块，如 common、infra、security、mq。

这样做的价值在于：降低耦合、便于团队并行开发、方便后续微服务拆分。尤其在大厂面试中，面试官更关注你是否能从业务边界思考架构，而不仅是代码分层。

2. Redis 在热点缓存和限流中的作用

电商大促时，商品详情、库存、活动规则属于典型热点数据。提前预热到 Redis，可以减少数据库访问，提升吞吐。限流常见做法包括计数器、滑动窗口、令牌桶等，核心目标是防止突发流量把系统打垮。

业务上，热点缓存不是简单“能查到数据”就行，还要考虑缓存击穿、缓存雪崩、缓存穿透。面试中最好结合“商品详情页”“秒杀库存”“活动配置”这些具体场景说明。

3. Kafka 在业务链路中的位置

Kafka 最适合做异步解耦、削峰填谷、事件驱动。例如订单创建成功后，不必同步完成发券、发短信、埋点等非核心动作，而是通过 Kafka 发布订单事件，由下游服务异步消费。

这样可以缩短主链路耗时，提高用户体验。但要注意消息可靠性、顺序性、重复消费和幂等处理。对于“订单已支付”这类事件，消费者必须能做到重复消息不重复执行。

4. Spring Security 与 JWT 在前后端分离中的实践

Spring Security 负责认证授权框架，JWT 负责承载身份信息。前后端分离时，服务端通常不再维护 Session，而是通过 JWT 实现无状态认证，便于水平扩展。

优点是分布式友好、跨服务传递方便；缺点是 token 一旦签发，主动失效较麻烦。因此常搭配短 token + refresh token、黑名单机制、密钥轮换等方案。大厂面试中，能说出这些权衡会很加分。

5. 第三方支付回调如何防重放和保证幂等

支付回调属于高风险接口，必须做签名校验、防重放