从零到一：基于Spring Cloud Alibaba + Nacos + Sentinel的电商秒杀系统实战

从零到一：基于Spring Cloud Alibaba + Nacos + Sentinel的电商秒杀系统实战

秒杀场景一直是电商系统中最具挑战性的业务场景之一。想象一下，当某款热门商品以极低价格限量发售时，瞬间涌入的流量可能达到平时系统的数十倍甚至上百倍。这种突发的高并发场景，不仅考验系统的承载能力，更考验架构设计的合理性。本文将带你从零开始，构建一个完整的电商秒杀系统，重点展示Spring Cloud Alibaba生态中的Nacos和Sentinel如何协同解决高并发场景下的各类技术难题。

1. 秒杀系统架构设计

在设计秒杀系统时，我们需要解决三个核心问题：瞬时高并发、库存准确性和系统稳定性。传统单体架构很难应对这些挑战，因此我们采用微服务架构，将系统拆分为多个独立服务，每个服务专注于单一职责。

我们的系统主要包含以下服务：

• 商品服务：负责商品信息管理
• 库存服务：处理库存扣减与恢复
• 订单服务：管理订单创建与状态
• 用户服务：处理用户认证与授权
• 秒杀服务：核心业务逻辑处理

// 秒杀服务核心接口示例 @RestController @RequestMapping("/seckill") public class SeckillController { @PostMapping("/{itemId}") public Result seckill(@PathVariable Long itemId, @RequestHeader("userId") Long userId) { // 秒杀业务逻辑 } }

系统架构采用Spring Cloud Alibaba作为基础框架，主要组件包括：

提示：在实际项目中，建议将秒杀商品信息提前预热到Redis缓存，避免活动开始时直接冲击数据库。

2. Nacos在秒杀系统中的应用

Nacos作为Spring Cloud Alibaba的核心组件之一，在我们的秒杀系统中扮演着两个重要角色：服务注册中心和动态配置中心。

2.1 服务注册与发现

在微服务架构下，服务间的调用关系复杂。Nacos提供了高效的服务注册与发现机制，使得服务之间能够动态感知彼此的存在。

配置Nacos服务注册非常简单：

# application.yml spring: cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: seckill-prod

关键配置项说明：

• server-addr: Nacos服务器地址
• namespace: 命名空间，用于环境隔离
• group: 服务分组，默认为DEFAULT_GROUP

2.2 动态配置管理

秒杀系统中，很多参数需要根据实际情况动态调整，比如：

• 秒杀活动开始时间
• 限流阈值
• 库存缓存时间

通过Nacos Config，我们可以实现配置的集中管理和动态刷新：

@RefreshScope @RestController public class SeckillConfigController { @Value("${seckill.limit.rate:100}") private Integer limitRate; // ... }

Nacos配置的优势在于：

1. 实时生效：修改配置后无需重启服务
2. 版本管理：支持配置回滚
3. 权限控制：不同环境配置隔离

3. Sentinel实现流量防护

Sentinel是系统稳定性的守护者，在高并发场景下尤为重要。我们的秒杀系统主要使用Sentinel实现以下功能：

3.1 流量控制

针对秒杀接口，我们需要设置合理的QPS阈值，防止系统被突发流量冲垮：

// 资源定义 @SentinelResource(value = "seckill", blockHandler = "handleBlock") public Result doSeckill(Long itemId, Long userId) { // 业务逻辑 } // 限流处理 public Result handleBlock(Long itemId, Long userId, BlockException ex) { return Result.fail("当前参与人数过多，请稍后再试"); }

Sentinel控制台可以实时调整规则：

3.2 熔断降级

当依赖服务出现不稳定时，Sentinel可以自动熔断，避免级联故障：

@SentinelResource(value = "inventory", fallback = "queryInventoryFallback") public Integer queryInventory(Long itemId) { // 调用库存服务 } public Integer queryInventoryFallback(Long itemId, Throwable t) { return 0; // 降级逻辑 }

熔断策略配置建议：

1. 慢调用比例：响应时间>500ms的比例超过阈值
2. 异常比例：异常请求比例超过阈值
3. 异常数：单位时间内异常数超过阈值

注意：生产环境中，Sentinel规则应该持久化到Nacos或文件，避免重启丢失。

4. 高并发优化技巧

秒杀系统的性能优化是一个系统工程，需要从多个层面进行优化。

4.1 缓存策略

合理的缓存设计可以极大减轻数据库压力：

1. 多级缓存架构：

   • 浏览器缓存静态资源
   • CDN缓存商品图片
   • Redis缓存热点数据
   • 本地缓存不常变的数据

2. 库存预热：

   // 活动开始前预热库存 public void preheatInventory(Long itemId, Integer count) { String key = "seckill:stock:" + itemId; redisTemplate.opsForValue().set(key, count); }

4.2 异步化设计

将非核心流程异步化，可以显著提升系统吞吐量：

1. 下单流程异步化：

   • 同步：校验库存→扣减库存→创建订单
   • 异步：校验库存→发送MQ消息→异步处理后续步骤

2. 使用RocketMQ削峰填谷：

   @Service public class OrderProducer { @Autowired private RocketMQTemplate rocketMQTemplate; public void sendCreateOrderMessage(OrderMessage message) { rocketMQTemplate.convertAndSend("seckill-order-topic", message); } }

4.3 分布式锁

防止超卖是秒杀系统的核心需求之一，我们采用Redis分布式锁：

public boolean seckillWithLock(Long itemId, Long userId) { String lockKey = "seckill:lock:" + itemId; String requestId = UUID.randomUUID().toString(); try { // 尝试获取锁 Boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, 10, TimeUnit.SECONDS); if (locked != null && locked) { // 执行业务逻辑 return doSeckill(itemId, userId); } return false; } finally { // 释放锁 if (requestId.equals(redisTemplate.opsForValue().get(lockKey))) { redisTemplate.delete(lockKey); } } }

5. 压力测试与调优

系统上线前，必须进行充分的压力测试。我们使用JMeter模拟高并发场景，重点关注以下指标：

测试过程中发现并解决的典型问题：

1. 数据库连接池耗尽：

   • 调整HikariCP配置：

     spring: datasource: hikari: maximum-pool-size: 50 connection-timeout: 3000

2. Redis响应变慢：

   • 优化Redis数据结构，使用Hash代替String存储商品信息
   • 增加Redis集群节点

3. Full GC频繁：

   • 调整JVM参数：

     -Xms2g -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=200

在实际项目中，我们通过逐步优化，最终实现了单机3000QPS的稳定表现，完全满足了业务需求。