Java大厂面试官灵魂拷问：Spring Boot + Kafka + Redis 在电商秒杀场景下的高并发设计

场景设定

假设在一个领先的电商平台进行技术二面，面试官严肃地坐在那里，而候选人则略带紧张地走进会议室。

第一轮：基础构建与服务启动（3问）

面试官： 我们从简单的问题开始。如果你要构建一个秒杀系统，使用 Spring Boot 搭建服务，你会如何初始化项目？你倾向于使用 Maven 还是 Gradle 来管理依赖？

候选人： 这个很简单！我通常使用 Spring Initializr 来创建项目，选择例如 3.1.5 版本的 Spring Boot，并添加 Web、Data JPA 和 Redis 等 starter。至于构建工具，我更习惯使用 Maven，尽管 Gradle 在构建速度上更快，但我对 pom.xml 文件的编写更为熟悉。

面试官： （点头）不错，Maven 确实更适合大型团队的统一管理。那么你是如何确保不同环境的配置隔离的？

候选人： 这个我也知道！可以通过使用 application-dev.yml 和 application-prod.yml 文件来区分开发和生产环境的配置，然后在启动时通过指定 profile 来应用相应的配置文件，例如

--spring.profiles.active=prod

。

面试官： 很好。如果需要处理支付回调，涉及到异步通知，你将如何设计接口的安全性？

候选人： 嗯……可以在前端传递一个 token，后端接收到后进行校验……或者使用 HTTPS 协议？

面试官： （微微皱眉）HTTPS 确实是必要的，但这还不够。我建议你研究一下签名机制，例如使用商户密钥对请求参数执行 HMAC-SHA256 签名，以验证请求的合法性和来源。

第二轮：缓存与数据库优化（4问）

面试官： 接下来谈谈核心部分。在秒杀活动开始之前，商品信息会被频繁查询，你打算如何优化这一过程？

候选人： 我会选择将这些信息存储在 Redis 中！首次查询时将数据从数据库写入 Redis，之后的查询就可以直接从 Redis 获取，这样速度会非常快！

面试官： 那么如果有人恶意查询不存在的商品 ID，导致缓存穿透怎么办？

候选人： 呃……我的想法是在代码中进行检查，如果数据库中也未找到该商品 ID，则向 Redis 中存储一个 null 值，从而避免后续再次查询数据库。

面试官： 这种方法称为“缓存空对象”。不过它是否有什么潜在的问题呢？

候选人： 可能会占用一定的内存空间，并且设置合理的过期时间可能会比较麻烦……

面试官： 回答得很好。实际上，更好的解决方案是使用布隆过滤器预先判断 key 是否存在。关于库存减少，你会如何操作？

候选人： 我会先查询库存，如果大于零就减少库存，并更新数据库……

面试官： 在高并发情况下，这种方法可能导致超卖问题，你知道吗？

候选人： 啊？不会吧……我可以使用 synchronized 关键字来解决这个问题？

面试官： （摇头）在单机环境中使用 synchronized 是可行的，但在分布式环境中则需要采用 Redis 分布式锁，例如使用 setnx 或 Redlock 来确保操作的原子性。

第三轮：消息队列与系统解耦（5问）

面试官： 为了应对瞬时流量对数据库的压力，你将采取哪些措施来实现流量削峰？

候选人： 我可以让用户先排队……在前端显示“正在排队中”的提示，然后逐步处理这些请求？

面试官： 思路是对的，但具体的技术手段是什么？

候选人： 呃……可以使用 RabbitMQ？将请求发送到队列中，后台再逐渐消费这些请求。

面试官： 为什么不选择 Kafka？

候选人： Kafka……主要是用于大数据日志处理的吧？RabbitMQ 相对来说更轻量级一些……

面试官： 实际上，Kafka 是处理高吞吐量的最佳选择，它可以支持每秒数百万条消息的处理，非常适合像秒杀这样的场景。而 RabbitMQ 虽然功能灵活，但其吞吐量较低。你有使用过 Kafka 的消费者组吗？

候选人： 消费者组……是指多个消费者共同消费同一个主题？这样做可以提升处理速度吗？

面试官： 是的，而且还可以实现广播或负载均衡的效果。最后一个问题：如果订单生成过程中出现失败，如何确保消息不会丢失？

候选人： 我……可能需要手动重试？

面试官： 你需要实施生产者确认机制（ack）、Broker 持久化以及消费者手动提交偏移量等措施，以确保即使在机器宕机的情况下，消息也不会丢失。

面试官： （合上笔记本）今天的面试就到这里。你的基础知识还不错，但在高并发的实际操作方面还有待加强。希望你能深入学习分布式架构设计，特别是消息中间件和缓存策略。我们会尽快通知你面试结果。

候选人： （松了一口气）谢谢面试官，我会加倍努力学习的！

面试题详解：电商秒杀系统的高并发架构设计

业务场景： 电商大促销期间的秒杀活动。用户在特定时间点抢购限量商品，此时的瞬时流量可能达到百万级 QPS，传统的同步直连数据库架构容易崩溃。因此，必须引入缓存、异步处理和限流等策略来应对这种情况。

核心技术栈解析

1. Spring Boot： 快速构建微服务，集成了 Web、Cache、Data 和 AMQP 模块。
   使用 @Cacheable 注解自动管理 Redis 缓存。
   通过 Profile 实现多环境配置分离，方便 DevOps 的部署。
   

   @Cacheable

2. Redis 缓存设计：
   • 缓存热点数据：提前将商品详情和库存数量加载到 Redis 中。
   • 防止缓存穿透：
     方案一：缓存空值（

     SET key null EX 60

     ）
     方案二（推荐）：使用布隆过滤器（Bloom Filter）预先拦截非法 key
   • 防止缓存雪崩：为缓存项设置随机的过期时间，以避免大量缓存同时失效。
   • 分布式锁扣减库存：利用 Redis 的 SETNX 命令（如果 key 不存在则设置）实现互斥，结合 Lua 脚本确保操作的原子性。
     

     SET inventory_lock_1001 true NX PX 30000

     
     

     NX

3. Kafka 实现削峰填谷： 通过 Kafka 的高吞吐能力，有效处理秒杀活动中的突发流量，确保系统稳定运行。

当用户请求成功时，系统会立即返回“抢购成功待处理”的通知，并同时向 Kafka Topic 发送消息。

后台多个消费者会并行处理下单流程，包括扣减库存、生成订单及发送短信。

优势：

• 高吞吐量：单个 Kafka 节点能够达到每秒处理百万条消息的能力。
• 消息持久化：通过日志分段存储支持消息的重复消费。
• 水平扩展：可以通过增加分区和消费者组成员来提高系统的消费能力。

数据库优化：

• 利用 InnoDB 的行级锁定机制，在 SQL 语句中添加锁定条件以锁定特定记录。
  

  FOR UPDATE

• 采用 HikariCP 数据库连接池，通过合理设置最大连接数量来防止系统雪崩现象。
• 使用 Flyway 工具实现数据库版本控制，确保不同环境下的数据一致性。

安全与幂等性：

• 所有接口均采用 HTTPS 协议，并实施 JWT 认证机制。
• 对于支付回调，采用 RSA 或 HMAC 签名验证请求的有效性。
• 在下单接口中实施幂等控制措施，例如通过唯一的订单编号或在 Redis 中记录请求标识来避免重复提交。

监控与可观测性：

• 集成 Prometheus 和 Grafana 监控工具，用于监控 JVM、Redis 和 Kafka 的性能指标。
• 使用 ELK 堆栈收集日志信息，并借助 Zipkin 进行调用链路跟踪。
• 在关键业务路径上设置监控点，用于统计响应时间、每秒查询次数以及错误发生率。

总结：高并发系统设计原则

原则	实现方式
缓存	使用 Redis 缓存热点数据，结合布隆过滤器防止缓存穿透
异步处理	利用 Kafka 进行流量削峰，实现订单处理的异步化
限流	通过 Sentinel 或 Nginx 控制每秒钟的请求数量
服务降级	秒杀活动结束后，直接向用户反馈商品已售罄的信息
熔断机制	采用 Resilience4j 实现自动化的服务熔断功能
幂等处理	通过数据库中的唯一索引和 Redis 中的请求 ID 来去重请求

给初学者的建议：

学习技术时，不应仅停留在理论层面，而应结合实际业务场景深入理解各种技术选择的理由。比如，为什么选择 Kafka 而不是 RabbitMQ？这是因为 Kafka 更注重消息的吞吐量而非复杂的路由功能；又如，为什么选用 Redis 而不是 Ehcache？因为 Redis 能够支持跨节点的数据共享。

掌握了这些原理和技术，你距离获得知名企业的录用通知书就只有一步之遥——那就是进行一次全面的技术回顾与实践操作。