Java 面试实战：Spring Boot + Kafka + Redis + Spring Security 在电商秒杀与风控场景中的 3 轮深挖

场景背景

面试场景：互联网大厂 Java 后端面试。

业务场景：电商秒杀、订单链路、库存扣减、风控校验、消息异步化、接口限流与登录安全。

人物设定：严肃面试官 + 搞笑水货程序员燕双非。

第一轮：秒杀入口与系统架构

面试官：我们做一个电商秒杀活动，前端请求进来之后，你会怎么设计整体链路，先保证系统不被打爆？

燕双非：我会先加个网关，然后做限流，再把流量挡住。热点商品信息放 Redis，页面静态化，后端尽量少查数据库。

面试官：说得不错。那如果是 Spring Boot 项目，你怎么落地这个限流和熔断？

燕双非：可以用 Spring Boot 集成 Sentinel 或者 Resilience4j，接口级别限流，失败了就降级返回兜底页面。还可以配合 Spring Security 做登录校验，避免未登录用户直接打秒杀接口。

面试官：继续。Redis 里你会存什么，为什么不直接查 MySQL？

燕双非：Redis 里可以存商品库存、活动状态、用户是否抢过资格、验证码这些高频数据。因为秒杀读多写少，Redis 比 MySQL 快很多，而且能扛住高并发。MySQL 更适合最终落库，不适合直接顶前面流量。

面试官：嗯，思路是对的。那如果库存都在 Redis，怎么防止超卖？

燕双非：可以用 Lua 脚本原子扣减库存，或者用分布式锁……

面试官：先停一下，这里我更想听你说清楚原子性和消息异步化的关系。

燕双非：噢，那就是先在 Redis 原子校验和扣减成功，再把下单消息发到 Kafka，异步处理订单创建。这样前端很快收到“排队中”，后面订单服务慢慢落库。

面试官：这就比较像大厂的答案了，继续保持。

第二轮：订单链路、消息队列与一致性

面试官：你说用了 Kafka 异步下单，那消息重复消费怎么办？

燕双非：额……可以在消费者那边判断订单号是否已经处理过，做幂等。比如订单表加唯一键，或者用 Redis 记录消费状态。

面试官：对，幂等很关键。那你会怎么设计消息体？用 JSON 还是别的？

燕双非：如果是简单场景 JSON 就可以，便于调试。如果对性能和体积要求高，可以用 Protobuf。订单创建这种链路，我一般会把用户 ID、商品 ID、活动 ID、请求唯一号、时间戳带上，保证能追踪和去重。

面试官：很好。那你在 Spring Boot 里怎么处理 Kafka 的生产和消费事务一致性？

燕双非：可以用本地事务 + 可靠消息最终一致性。也就是数据库事务先提交，再发消息，或者用 outbox 表把消息先写库，再由后台任务投递 Kafka。消费端再用幂等保证最终一致。

面试官：如果你的下单服务挂了，Redis 库存已经扣了，但消息没发出去，怎么办？

燕双非：这个……我会……做补偿任务吧。比如定时扫描 Redis 和数据库之间的差异，或者对未完成订单做超时回滚，释放库存。

面试官：可以。那如果风控要求同一个用户、同一设备、同一 IP 不能频繁抢购，你会怎么做？

燕双非：Spring Security 负责身份认证，Redis 负责频次计数，网关层做 IP 限流，必要时还能加验证码和行为校验。高风险请求直接拦截，降低刷单和脚本攻击。

面试官：不错，你已经开始把业务和安全串起来了。

第三轮：安全、监控与故障治理

面试官：现在假设秒杀活动上线后，用户反馈“点了没反应”，你会怎么排查？

燕双非：先看日志，再看监控。日志用 Logback 或 Log4j2 打关键链路，监控用 Micrometer 接 Prometheus，再上 Grafana 看 QPS、RT、错误率和 Kafka 堆积。

面试官：那如果日志里看到大量 401 和 429，你怎么判断问题在哪？

燕双非：401 可能是 Spring Security 鉴权问题，比如 token 过期、签名错误；429 多半是限流触发了，说明流量太集中。要看是不是策略过严，或者秒杀入口没有做足够的预热和分流。

面试官：很好。那你们如果用了 JWT，怎么避免 token 泄露后长期有效？

燕双非：我会控制 access token 短时有效，refresh token 单独管理，必要时做黑名单。敏感接口再叠加二次校验，比如短信验证码、设备指纹或者风控评分。

面试官：最后一个问题：如果这套系统要扩展成企业级营销平台，还要接入活动中心、消息中心、审计中心，你会怎么考虑 Spring Boot 的服务拆分？

燕双非：可以按领域拆成活动服务、库存服务、订单服务、风控服务和通知服务。服务间用 REST 或者消息队列通信，公共能力抽成 SDK。配置、限流、监控、链路追踪统一治理，避免每个服务各搞一套。

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

所有问题详细解析

1. 电商秒杀为什么要做网关限流、静态化和 Redis 预热？

秒杀的核心挑战是瞬时流量极高，系统如果直接打到数据库，很容易出现连接池耗尽、锁竞争和雪崩。通常会在网关层做限流，先挡住明显异常流量；页面和活动信息尽量静态化，减少动态接口调用；把商品库存、活动状态、是否已抢购等高频数据预热到 Redis，避免每次都查 MySQL。

2. Spring Boot 如何结合限流、降级与安全控制？

Spring Boot 本身负责快速集成业务组件，常见做法是配合网关和 Resilience4j 实现限流、熔断