Java大厂面试真题解析：Spring Boot + Kafka + Redis 在电商秒杀场景中的应用

Java大厂面试真题解析：Spring Boot + Kafka + Redis 在电商秒杀场景中的应用

面试官：我们今天来聊聊电商秒杀系统的架构设计。你是谢飞机是吧？

谢飞机：对对对！我就是谢飞机，飞得不高但挺稳！

第一轮：基础构建与Spring Boot应用

Q1：如果让你用Spring Boot做一个秒杀系统，你会怎么搭建项目结构？

谢飞机：这个我会！先建个Spring Boot工程，加spring-boot-starter-web，然后分controller、service、dao三层，再整一个entity包，标准MVC嘛！

面试官（点头）：不错，有框架感。那你怎么控制接口访问频率，防止用户疯狂刷新？

Q2：如何防止用户短时间内频繁请求秒杀接口？

谢飞机：加个注解就行！我用过@RateLimiter……啊不是，那是Guava的。我们可以用AOP+自定义注解，结合Redis做计数器，比如INCR key EX 1，超过阈值就拒绝。

面试官：很好，思路清晰。那你来说说Redis的原子操作是怎么保证计数准确的？

Q3：Redis的INCR为什么能保证高并发下的准确性？

谢飞机：因为……它是单线程的？所以命令是顺序执行的，不会乱。就像食堂打饭，只有一个窗口，大家排队，就不会抢到同一个菜。

面试官（微笑）：比喻很形象。Redis确实基于单线程事件循环，配合多路复用，既高效又安全。

第二轮：高并发挑战与库存超卖问题

Q4：用户抢购时，怎么避免超卖？比如只有10件商品，结果卖了15单。

谢飞机：嗯……我在数据库里减库存，UPDATE goods SET stock = stock - 1 WHERE id = 1 AND stock > 0，这样应该不会超卖吧？

面试官：基本正确。但如果并发很高，数据库压力大，还有没有优化方案？

Q5：如何用Redis预减库存来提升性能？

谢飞机：可以把库存提前放到Redis里，比如SET stock:1001 10，然后用DECR去减，减到负数就停止。速度快，不压数据库！

面试官：很好。但如果Redis减完了，后续订单怎么跟数据库最终一致？

Q6：Redis减完库存后，如何保证数据库最终一致性？

谢飞机：呃……可以……把订单写进消息队列？然后慢慢消费，更新数据库？我听说过Kafka……但没写过生产者……

面试官：方向是对的。我们来看下一个问题。

第三轮：异步化与消息队列设计

Q7：Kafka在秒杀系统中扮演什么角色？

谢飞机：就是……存消息的？用户抢到了，发个消息到Kafka，后面慢慢处理订单、发短信、扣积分……

面试官：对，这就是“削峰填谷”。那如果Kafka宕机了，消息会不会丢？

Q8：如何保证Kafka消息不丢失？

谢飞机：呃……可以重试？或者……Producer设置acks=all？Broker那边多副本？Consumer手动提交？我背过……但没调过参数……

面试官：概念还记得，实践要加强。最后一个问题：

Q9：Redis和Kafka都挂了，系统还能撑住吗？

谢飞机：那……那就……挂了吧……要不加个降级？比如返回“活动太火爆，请稍后再试”？

面试官（笑）：至少用户体验还在。好了，今天的面试就到这里，你回去等通知吧。

答案详解：电商秒杀系统的技术实现

🎯 业务场景：电商大促秒杀

用户在指定时间抢购限量商品，瞬时流量可达百万QPS。核心目标：

• 防止超卖
• 快速响应
• 系统稳定不崩溃

🔧 技术栈组合：Spring Boot + Redis + Kafka

| 组件 | 作用 | |------|------| | Spring Boot | 快速构建微服务，集成Web、Cache、Kafka等模块 | | Redis | 预减库存、限流计数、热点数据缓存 | | Kafka | 异步解耦，订单落库、日志、通知等异步处理 |

📌 核心技术点解析

1. Redis原子操作防超卖

# 初始化库存
SET stock:1001 10

# 用户抢购时尝试减库存
DECR stock:1001
# 或使用更安全的 Lua 脚本

Lua脚本确保“判断+减库存”原子性，避免竞态条件。

2. Kafka消息可靠性保障

• Producer: acks=all, retries>0, enable.idempotence=true
• Broker: 副本机制（replication.factor ≥ 3）
• Consumer: 手动提交offset，处理成功后再提交

3. 系统降级与容错

• Redis不可用 → 返回降级页面，记录日志
• Kafka不可用 → 本地队列缓存，或直接失败快速响应
• 数据库只读 → 拒绝下单，保障数据一致性

4. 整体流程图

用户请求 → Nginx → 网关限流 → Redis预减库存 → 成功 → 发Kafka消息 → 异步创建订单
                                   ↓ 失败 → 直接返回“已售罄”

✅ 总结

• 前端拦截：验证码、按钮置灰
• 网关层：IP限流、用户限流
• 服务层：Redis预减库存 + Lua脚本
• 异步层：Kafka削峰 + 消费幂等
• 持久层：数据库最终一致性

这套方案广泛应用于双11、618等大促场景，是Java高级工程师必须掌握的实战技能。

建议学习路径：Spring Boot → Redis → Kafka → 分布式锁 → 全链路压测 → 容灾演练