电商秒杀系统架构实战：Spring Boot+Kafka+Redis高并发优化

1. 项目背景与核心挑战

去年参与某头部电商平台秒杀系统重构时，我们团队基于Spring Boot+Kafka+Redis的技术栈实现了每秒3万笔订单的稳定处理。这个过程中积累的实战经验，或许能帮你少走弯路。

电商秒杀场景本质上是在解决"三高"问题：

• 高并发：瞬时流量可能是平时的100倍以上
• 高性能：必须在500ms内完成核心链路
• 高一致：既要防止超卖又要保证数据准确

2. 技术架构设计解析

2.1 整体架构分层

我们的分层设计如下（数字表示QPS能力）：

code复制用户层       → 接入层(50万) → 服务层(5万) → 存储层(3万)
(静态化+CDN)   (Nginx集群)   (Spring Boot)  (Redis+Kafka+MySQL)

2.2 关键组件选型原因

• Spring Boot：快速构建微服务，配合Actuator实现健康检查
• Kafka：峰值流量削峰，消息堆积能力达百万级
• Redis：单节点10万+ QPS，Lua脚本保证原子性

特别注意：Redis一定要用集群版，单机版在压力测试时出现了连接数爆满的问题

3. 核心实现细节

3.1 库存预热方案

java复制// Redis预减库存Lua脚本
String script = "if redis.call('exists',KEYS[1])==1 then" +
                "   local stock=tonumber(redis.call('get',KEYS[1]));" +
                "   if stock>0 then" +
                "      redis.call('decrby',KEYS[1],1);" +
                "      return stock-1;" +
                "   end;" +
                "   return -1;" +
                "end;" +
                "return -2;";

3.2 异步下单流程

1. 前端：按钮置灰+随机延迟提交
2. 网关：令牌桶限流（Guava RateLimiter）
3. 服务层：
   • Redis校验库存
   • Kafka发送订单消息
   • 返回"处理中"状态
4. 消费者：
   • 数据库最终扣减
   • 订单状态更新

4. 性能优化实战

4.1 Redis调优记录

4.2 Kafka分区设计

根据压测数据，我们确定了分区数计算公式：

code复制分区数 = 峰值QPS / 单分区处理能力(约3000)

最终设置16个分区，每个分区配置：

properties复制num.io.threads=8
queued.max.requests=5000

5. 踩坑实录

5.1 热点Key问题

某次大促出现Redis CPU 100%，发现是seckill:stock:123这个Key被百万次访问。解决方案：

• 本地缓存+随机过期时间
• Key拆分：seckill:stock:123_[0-9]

5.2 消息堆积告警

Kafka曾积压50万消息，发现是消费者处理超时。优化方案：

• 增加消费者线程池
• 批量消费配置：

java复制props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, 100);
props.put(ConsumerConfig.FETCH_MAX_BYTES_CONFIG, 5242880);

6. 面试要点梳理

大厂常问的深水区问题：

1. Redis事务和Lua脚本的原子性区别？
2. Kafka如何保证消息顺序消费？
3. 分布式锁在秒杀中的正确用法？
4. 如何设计兜底方案应对Redis崩溃？

建议准备方向：

• 底层原理（如Redis单线程模型）
• 极限场景（如网络分区时如何处理）
• 数据一致性（如缓存与DB同步策略）

这个架构经过618、双十一考验，核心在于：异步化设计+多级缓存+柔性降级。实际开发中还需要配合全链路压测，我们当时用JMeter模拟了10万并发请求，持续优化了3个版本才达到SLA要求。