Java大厂面试实录：Spring Boot + Kafka + Redis 在电商场景下的高频考点全解析本文通过一场幽

面试现场：谢飞机勇闯互联网大厂

面试官（推了推眼镜）：今天我们围绕一个电商秒杀系统来聊聊技术实现。你是谢飞机？

谢飞机（挠头）：是的！我飞得很稳，不抖～

第一轮：基础搭建 —— Spring Boot 与 Web 层设计

Q1：如果我们要做一个高并发的秒杀活动页面，你会怎么选型？为什么用 Spring Boot 而不是传统 Jakarta EE？

谢飞机：这个我知道！Spring Boot 快啊，内嵌 Tomcat，不用配 XML，启动快，开发效率高！而且注解多，写起来像搭积木！

面试官（点头）：不错，它自动配置和起步依赖确实提升了开发速度。那 Controller 层如何接收请求参数？比如商品 ID 和用户 token？

谢飞机：用 @RequestParam 接商品 ID，@RequestHeader 拿 token，或者直接上 @RequestBody 接 JSON！

面试官：很好。那如果我想统一处理所有接口返回格式，比如都包装成 {code: 0, data: ..., msg: "ok"}，怎么做？

谢飞机：嗯……我在每个方法里手动 new 一个 Result 类？

面试官（微笑）：有更优雅的方式——可以用 @ControllerAdvice 配合 ResponseEntity 或自定义拦截器。

谢飞机：哦！那我回去就加个“AOP切一切”！

第二轮：数据层与缓存策略 —— Redis + MySQL + HikariCP

Q3：秒杀最怕什么？

谢飞机：怕……程序员放假？

面试官：怕超卖！你怎么防止库存超卖？

谢飞机：数据库加个字段，每次减之前查一下还有没有货，有就减一！

面试官：在高并发下，这种“查再减”会出现竞态条件，怎么办？

谢飞机：呃……我让数据库 sleep 一毫秒？

面试官（扶额）：应该用原子操作。比如 Redis 的 DECR，或 MySQL 的 UPDATE xxx SET stock = stock - 1 WHERE stock > 0。

Q4：那为什么要引入 Redis？

谢飞机：因为快！内存里的，比数据库快一万倍！

面试官：对，我们通常会把热点商品信息和库存预热到 Redis。那连接池用哪个？

谢飞机：HikariCP！听说是最快的！

面试官：没错，它的性能和响应时间优于 Druid、C3P0。那你项目中怎么配置的？

谢飞机：复制粘贴别人的 yaml……

面试官：……建议你了解下最大连接数、空闲超时这些参数。

第三轮：消息队列与异步化 —— Kafka 解耦下单流程

Q5：用户抢到了，但订单创建失败怎么办？

谢飞机：让他重新抢！

面试官：这体验不行。我们希望即使下游服务短暂不可用，也能保证订单最终生成。

谢飞机：那就……等它修好再补？人工导出 Excel 导进去？

面试官：我们需要异步解耦。用什么？

谢飞机：Kafka？听说过，是个快递站？

面试官：类比得不错。Kafka 就像消息中转站，把下单事件发给它，订单服务、积分服务、物流服务各自消费。

Q6：如果消费者挂了，消息会不会丢？

谢飞机：不会吧……应该存在天上？

面试官：靠的是持久化和确认机制。Kafka 把消息写磁盘，并支持副本备份；消费者手动提交 offset 才算消费成功。

Q7：那 RabbitMQ 和 Kafka 有什么区别？

谢飞机：Rabbit 是兔子，跑得快；Kafka 是咖啡，提神醒脑……

面试官（无奈）：RabbitMQ 更适合低延迟、复杂路由的小规模场景；Kafka 偏向高吞吐、日志流式处理，适合大数据和微服务解耦。

面试官（合上本子）：今天先到这里。你的基础知识还行，但深度有待加强。回去好好看看分布式事务、限流降级这些内容。我们会尽快通知你结果。

谢飞机（起身鞠躬）：谢谢！我一定等您电话，不吃不喝一直等！

【附录】知识点详解：电商秒杀系统的架构设计

🎯 业务场景：电商秒杀系统

秒杀场景具有瞬时高并发、短时间流量洪峰、核心资源有限（如库存）等特点。例如双十一小米手机限量抢购，10万用户同时点击，只有100台可售。

🔧 技术栈选型与原理

1. Spring Boot 作为主框架

优势：自动装配、起步依赖（starter）、内嵌容器、Actuator 监控端点。
替代方案对比：相比 Jakarta EE 的繁琐配置，Spring Boot 开发效率提升显著。

2. Redis 缓存库存

使用 INCR/DECR 实现原子扣减，避免超卖。
利用 Lua 脚本实现“判断+扣减”原子操作。

示例脚本：

if redis.call('get', KEYS[1]) > 0 then
  return redis.call('decr', KEYS[1])
else
  return -1
end

3. MySQL + 乐观锁防超卖

SQL：UPDATE product SET stock = stock - 1 WHERE id = ? AND stock > 0
结合唯一索引防止重复下单（用户ID+商品ID）。

4. HikariCP 连接池优化

关键参数：
- maximumPoolSize: 根据 DB 承载能力设置（通常 10~20）
- connectionTimeout: 获取连接超时时间（默认 30s）
- idleTimeout 和 maxLifetime

5. Kafka 异步解耦订单流程

流程：
1. 用户抢购成功 → 发送消息到 topic order_create
2. 订单服务消费 → 创建订单
3. 积分服务消费 → 增加积分
4. 短信服务消费 → 发送通知
优点：
- 解耦业务逻辑
- 提高系统可用性（允许部分服务暂时宕机）
- 支持削峰填谷

6. 消息可靠性保障

生产者：启用 acks=all，确保 ISR 全部落盘
Broker：设置 replication.factor >= 3
消费者：关闭自动提交，手动 commit offset

7. 其他配套技术

限流：Sentinel 或 Resilience4j 控制每秒请求数
降级：当库存服务异常时，返回“已售罄”静态页
监控：Prometheus + Grafana 监控 QPS、RT、错误率
CI/CD：Jenkins 构建镜像，K8s 部署灰度发布

✅ 总结：构建高性能秒杀系统的四大原则

读多写少 → 缓存前置（Redis）
防止超卖 → 原子操作 + 数据库校验
削峰填谷 → 消息队列异步化
系统稳定 → 限流、降级、熔断三位一体

💡 小白学习建议：先掌握 Spring Boot + Redis + MySQL 单体架构，再逐步引入 Kafka 和微服务治理组件。