Java大厂面试实录：Spring Boot + Kafka + Redis 在电商秒杀场景下的应用与避坑指南

面试官：我们开始吧。你是谢飞机？

谢飞机：是的！我就是那个代码写得飞起，Bug 修得更快的谢飞机！

面试官（皱眉）：……先别起飞，咱们今天聊聊电商秒杀系统。你用过 Spring Boot 做高并发项目吗？

---

🟢 第一轮：基础技术栈考察 —— 秒杀系统的骨架

Q1：如果让你设计一个基于 Spring Boot 的商品秒杀系统，你会怎么搭建核心模块？

A1（谢飞机）：这个简单！我用 Spring Boot 搭个 Web 项目，加个@RestController写个/seckill接口，再连个 MySQL，查库存、减库存，搞定！

面试官：……那你有没有考虑超卖问题？

Q2：在高并发下，多个请求同时减库存，如何防止超卖？

A2（谢飞机）：啊？超卖？不会吧，我数据库字段设成int不就行了……最多卖完为止。

面试官：那如果库存是 100，1000 个人同时抢，数据库层面怎么保证不超卖？

A2补答（含糊）：呃……我可以加个synchronized锁整个方法？或者用 Redis 先扣一下？好像是这么回事……

面试官：接近了。你可以继续。

Q3：MySQL 中如何通过 SQL 实现乐观锁防止超卖？

A3（谢飞机）：乐观锁？是不是像谈恋爱一样，相信别人不会改？SQL……我试过UPDATE product SET stock = stock - 1 WHERE id = 1 AND stock > 0，应该可以吧？

面试官：✅ 正确。这就是典型的 CAS 操作，利用数据库行锁和条件更新避免超卖。不错，进入下一轮。

---

🟡 第二轮：中间件进阶 —— 高并发下的流量削峰与异步处理

Q4：如果瞬时 10 万请求涌入，你的服务直接打到数据库会怎样？

A4（谢飞机）：嗯……数据库可能就“噶了”。我听说可以用 Redis 缓存库存，先从 Redis 扣，再异步同步到数据库。

面试官：很好。那 Redis 如何防止扣成负数？比如库存 100，来了 120 个请求。

Q5：你如何用 Redis 原子操作实现库存预扣？

A5（谢飞机）：我用DECR命令！每次减一，Redis 是单线程嘛，天然原子性！

面试官：但如果要判断库存是否足够呢？DECR会直接减到负数。

A5补答（挠头）：那……我先GET一下，大于 0 再DECR？

面试官：非原子操作，会有并发问题。提示：Lua 脚本或DECRBY配合条件？

A5最终（支吾）：呃……好像 Redis 有个啥脚本语言……我回去再查查……

面试官：没关系。接下来，扣完库存后，订单怎么生成？

Q6：如何解耦下单逻辑，避免阻塞主线程？

A6（谢飞机）：我知道！用消息队列！比如 Kafka，把秒杀成功的消息发进去，后面慢慢创建订单！

面试官：✅ 很好。那 Kafka 如何保证消息不丢失？

A6补答（自信）：Kafka 有副本机制！我配replication.factor=3，还有acks=all，这样 leader 和 follower 都写成功才算成功！

面试官：不错。那消费者重复消费怎么办？

A6最终（卡壳）：重复……消费？我让消费者自己判断？比如查数据库有没有这个订单……

面试官：对，幂等性设计。可以接受。

---

🔴 第三轮：系统设计与稳定性 —— 监控、降级与安全

Q7：如果 Redis 宕机了，秒杀系统还能用吗？

A7（谢飞机）：不能用了……那不就完了？

面试官：有没有预案？比如本地缓存？

A7补答（灵光一闪）：哦！我可以用 Caffeine 做本地缓存？但数据一致性咋办……

面试官：可以结合多级缓存，但要注意缓存穿透、击穿、雪崩。你说说缓存击穿是什么？

A8（谢飞机）：击穿？是不是缓存里没有，数据库被疯狂查？我加互斥锁，比如用 Redis 的SETNX……

Q9：如何监控整个链路的性能？比如哪个环节慢了？

A9（谢飞机）：我用日志！System.out.println("开始……结束")！

面试官：……生产环境这么干？

A9补答（尴尬）：呃，我们项目用了 Prometheus + Grafana，还集成了 Micrometer，监控 JVM 和接口耗时。

面试官：那分布式链路追踪呢？

A9最终（蒙圈）：链路追踪？是不是……看日志时间戳？

面试官：有了解 Jaeger 或 Zipkin 吗？

A9（摇头）：没用过，但听说过……

面试官：最后一个问题：秒杀接口如何防刷？比如有人用脚本疯狂请求。

Q10：如何实现接口限流？

A10（谢飞机）：我用 Redis + 漏桶算法！或者……Spring Cloud Gateway 配置限流规则！

面试官：具体点？比如用 Resilience4j？

A10最终（结巴）：Resilience……4j？我只用过 Hystrix……限流阈值……配置一下……

面试官：嗯，整体还可以。今天先到这里，你先回去吧，我们后续 HR 会联系你。

谢飞机：好的！我回去等通知！（小声）希望不是“回家等通知”……

---

✅ 真实答案解析：电商秒杀系统的技术全景图

业务场景：电商大促秒杀

秒杀是典型的高并发、低延迟、强一致性的业务场景。核心目标是：

• 防止超卖
• 抗住高并发
• 保障系统稳定
• 可监控、可运维

技术点详解

1. 防止超卖：数据库乐观锁

UPDATE product SET stock = stock - 1 WHERE id = ? AND stock > 0;

• 利用 WHERE 条件 + 更新影响行数判断是否成功
• 结合 Spring 的@Transactional保证事务

2. 流量削峰：Redis 预减库存

• 使用 Lua 脚本保证原子性：

local stock = redis.call('GET', 'seckill:stock:' .. KEYS[1]) if tonumber(stock) <= 0 then return -1 else return redis.call('DECR', 'seckill:stock:' .. KEYS[1]) end

• 通过EVAL命令执行，避免GET + DECR的并发问题

3. 异步化：Kafka 解耦订单创建

• 秒杀成功后发送消息到 Kafka Topic
• 订单服务作为消费者异步创建订单，支持重试和死信队列
• 幂等性设计：订单表加唯一索引（用户ID+商品ID）

4. 多级缓存架构

• L1：Caffeine 本地缓存（速度快，但有副本不一致风险）
• L2：Redis 集群（统一存储，支持持久化）
• 缓存穿透：布隆过滤器 or 缓存空值
• 缓存击穿：互斥锁（Redis SETNX）
• 缓存雪崩：随机过期时间 + 高可用集群

5. 限流与降级

• 限流：Resilience4j 速率限制器（RateLimiter）或 Sentinel
• 降级：Hystrix 或 Resilience4j Fallback，返回“活动太火爆，请稍后再试”

6. 分布式追踪

• 集成Sleuth + Zipkin或OpenTelemetry
• 每个请求生成 TraceId，贯穿网关、服务、DB、MQ
• 便于定位性能瓶颈

7. 安全防护

• 接口限流：API Gateway 层限流（如 Spring Cloud Gateway）
• 防脚本刷单：验证码（滑块）、设备指纹、用户行为分析
• 权限控制：JWT + OAuth2，确保用户合法

8. 监控体系

• Metrics：Micrometer + Prometheus + Grafana（QPS、响应时间、错误率）
• Logs：ELK Stack（Logback → Kafka → Elasticsearch → Kibana）
• Traces：Jaeger / Zipkin

总结

一个完整的秒杀系统，不仅仅是写个接口，而是涉及：

• Spring Boot快速开发
• Redis缓存与原子操作
• Kafka异步解耦
• MySQL乐观锁控制库存
• Resilience4j / Sentinel限流降级
• Prometheus + Grafana + Zipkin全链路监控

这才是大厂 Java 工程师的真实能力要求。

---

面试官内心OS：这小伙子基础还行，中间件知道些，深度不够……但态度不错，建议二面补底层原理。