1. 秒杀系统架构设计核心挑战

电商秒杀场景通常具备"三高"特征：瞬时高并发（10万级QPS）、高资源竞争（1000件商品被数万人抢购）、高一致性要求（不能超卖也不能少卖）。我在参与某头部电商平台618大促秒杀系统改造时，实测发现传统架构在5000QPS时就会出现服务雪崩。下面这个典型超卖案例，揭示了问题本质：

// 存在严重并发问题的库存扣减实现 public String deductStock(String itemId) { Integer stock = (Integer) redisTemplate.opsForValue().get("stock:" + itemId); if (stock > 0) { redisTemplate.opsForValue().set("stock:" + itemId, stock - 1); return "抢购成功"; } return "库存不足"; }

当两个线程同时执行这段代码时，可能出现以下时序问题：

1. 线程A和线程B同时查询库存，都得到stock=1
2. 线程A执行set("stock", 0)
3. 线程B继续执行set("stock", 0)
4. 实际卖出2件商品，但库存只减少1，造成超卖

2. Redis+Lua原子性解决方案

2.1 Lua脚本的原子性本质

Redis采用单线程事件循环模型，每个Lua脚本会作为一个整体执行。我在压测时验证过：当脚本执行期间，即使有10万个并发请求到达，也必须等待当前脚本执行完成。这种机制比传统数据库事务更轻量，但同样保证原子性。

2.2 库存扣减Lua脚本精解

以下是经过生产验证的增强版扣减脚本：

-- KEYS[1]: 库存key -- ARGV[1]: 扣减量 -- ARGV[2]: 当前时间戳（用于限流） local stockKey = KEYS[1] local decrement = tonumber(ARGV[1]) local timestamp = tonumber(ARGV[2]) -- 库存存在性检查（防缓存击穿） if redis.call('exists', stockKey) == 0 then return {-1, "商品不存在"} -- 编码-1 end -- 获取当前库存 local stock = tonumber(redis.call('get', stockKey)) local afterStock = stock - decrement -- 库存检查 if stock <= 0 then return {-2, "已售罄"} -- 编码-2 end if afterStock < 0 then return {-3, "库存不足"} -- 编码-3 end -- 执行扣减 redis.call('decrby', stockKey, decrement) -- 记录抢购流水（防重复扣减） local orderKey = "order:"..stockKey..":"..timestamp if redis.call('setnx', orderKey, 1) == 1 then redis.call('expire', orderKey, 86400) -- 24小时过期 return {afterStock, "抢购成功"} else -- 回滚库存 redis.call('incrby', stockKey, decrement) return {-4, "请勿重复提交"} -- 编码-4 end

脚本关键增强点：

1. 增加缓存存在性检查，避免缓存击穿
2. 引入订单流水记录，防止客户端重试导致重复扣减
3. 严格类型转换（tonumber）避免类型错误
4. 多状态码返回，便于客户端处理不同场景

2.3 Spring Boot集成实践

在Spring中推荐这样管理Lua脚本：

@Configuration public class LuaConfiguration { @Bean public DefaultRedisScript<List> stockDeductScript() { DefaultRedisScript<List> script = new DefaultRedisScript<>(); script.setLocation(new ClassPathResource("lua/stock_deduct.lua")); script.setResultType(List.class); // 注意返回类型匹配 return script; } } @Service @Slf4j public class SecKillService { @Autowired private RedisTemplate<String, String> redisTemplate; @Autowired private DefaultRedisScript<List> stockDeductScript; public SecKillResult handleSecKill(String userId, String itemId) { List<String> keys = Collections.singletonList("stock:" + itemId); String timestamp = String.valueOf(System.currentTimeMillis()); // 执行脚本 List result = redisTemplate.execute( stockDeductScript, keys, "1", // 每次扣减1件 timestamp ); // 处理结果 Long code = (Long) result.get(0); String msg = (String) result.get(1); if (code > 0) { // 异步创建订单 orderService.asyncCreateOrder(userId, itemId); return SecKillResult.success(code); } return SecKillResult.fail(code, msg); } }

生产环境建议：

1. 使用连接池配置（Lettuce优于Jedis）
2. 脚本预加载到Redis（SCRIPT LOAD）
3. 异常时降级到数据库乐观锁

3. Redis Stream消息队列应用

3.1 为什么选择Stream

对比传统消息队列方案：

• RabbitMQ：性能瓶颈（约1万QPS）
• Kafka：延迟较高（至少100ms）
• Redis List：没有消费组概念

Stream的独特优势：

• 百万级QPS处理能力
• 消费组自动负载均衡
• 消息回溯能力
• 精确的Pending消息管理

3.2 秒杀订单处理架构

// 初始化Stream @PostConstruct public void initStream() { if (!redisTemplate.hasKey("order_stream")) { redisTemplate.opsForStream().createGroup( "order_stream", "order_group" ); } } // 生产者（抢购成功后写消息） public void produceOrderEvent(Order order) { Map<String, String> fields = new HashMap<>(); fields.put("userId", order.getUserId()); fields.put("itemId", order.getItemId()); fields.put("orderTime", order.getCreateTime().toString()); redisTemplate.opsForStream().add( "order_stream", StreamRecords.string(fields).withId(RecordId.autoGenerate()) ); } // 消费者（集群部署） @Scheduled(fixedRate = 100) public void consumeOrderEvent() { try { List<MapRecord<String, String, String>> records = redisTemplate.opsForStream().read( Consumer.from("order_group", "consumer_1"), StreamReadOptions.empty().count(10), StreamOffset.create("order_stream", ReadOffset.lastConsumed()) ); if (records != null && !records.isEmpty()) { for (MapRecord<String, String, String> record : records) { processOrder(record); redisTemplate.opsForStream().acknowledge( "order_group", record ); } } } catch (Exception e) { log.error("订单处理异常", e); // 错误处理策略： // 1. 重试3次 // 2. 转入死信队列 // 3. 人工补偿 } }

3.3 Stream管理技巧

1. 监控Pending消息：

XINFO GROUPS order_stream XPENDING order_stream order_group

2. 消息回溯处理：

// 重新处理未ACK的消息 List<MapRecord<String, String, String>> failedRecords = redisTemplate.opsForStream().range( "order_stream", "1526567895632-0", "1526567895632-1" );

3. 性能调优参数：

• maxlen：设置Stream最大长度（避免内存溢出）
• MINID：定期清理已处理消息

4. 高并发优化组合拳

4.1 多级缓存架构

graph TD A[客户端] -->|本地缓存| B(浏览器缓存) A -->|CDN缓存| C[边缘节点] C -->|Nginx缓存| D[应用服务器] D -->|Redis集群| E[分布式缓存] E -->|数据库缓存| F[MySQL BufferPool]

实战技巧：

1. 商品详情页静态化
2. 库存数据采用"Redis+本地缓存"二级缓存
3. 缓存key设计：业务前缀:版本号:ID（如 "stock:v1:1001"）

4.2 库存分段方案

当库存量较大时（如10万件），可以采用分段库存提升并发：

// 初始化分段库存 public void initSegmentStock(String itemId, int total, int segments) { int base = total / segments; for (int i = 0; i < segments; i++) { int segmentStock = (i == segments - 1) ? base + total % segments : base; redisTemplate.opsForValue().set( "stock:" + itemId + ":" + i, segmentStock ); } } // 随机选择分段扣减 public boolean deductSegmentStock(String itemId, int segments) { Random random = new Random(); for (int i = 0; i < 3; i++) { // 重试3次 int segment = random.nextInt(segments); Long result = redisTemplate.execute( stockDeductScript, Collections.singletonList("stock:" + itemId + ":" + segment), "1" ); if (result > 0) return true; } return false; }

注意事项：

1. 分段数建议为并发线程数的2-3倍
2. 定期合并库存碎片（凌晨低峰期执行）

4.3 分布式限流方案

-- 滑动窗口限流脚本 -- KEYS[1]: 限流key -- ARGV[1]: 窗口大小(秒) -- ARGV[2]: 最大请求数 local key = KEYS[1] local window = tonumber(ARGV[1]) local max = tonumber(ARGV[2]) local now = tonumber(redis.call('TIME')[1]) local clearBefore = now - window -- 清除过期记录 redis.call('ZREMRANGEBYSCORE', key, 0, clearBefore) -- 获取当前计数 local current = redis.call('ZCARD', key) if current >= max then return 0 else redis.call('ZADD', key, now, now..math.random()) redis.call('EXPIRE', key, window) return 1 end

应用场景：

1. 用户维度限流（防止脚本抢购）
2. IP维度限流（防止DDoS攻击）
3. 商品维度限流（热点商品保护）

5. 生产环境注意事项

5.1 Redis高可用配置

推荐集群方案：

• 哨兵模式：适用于中小规模（主从切换自动完成）
• Cluster模式：大规模场景（数据分片存储）
• 双写方案：主集群+灾备集群（通过DTS同步）

关键参数：

# 连接池配置 spring.redis.lettuce.pool.max-active=200 spring.redis.lettuce.pool.max-wait=1000ms spring.redis.lettuce.pool.max-idle=50 # 超时设置 spring.redis.timeout=3000ms spring.redis.lettuce.command-timeout=2000ms

5.2 压测指标参考

我们在4核8G服务器上的测试数据：

5.3 常见故障处理

案例1：Stream消费积压现象：XPENDING数量持续增长 解决方案：

1. 增加消费者实例
2. 调整batchSize参数
3. 监控消费速度与生产速度比例

案例2：Redis内存溢出现象：OOM错误日志 处理步骤：

1. 设置maxmemory-policy=allkeys-lru
2. 对大数据key进行分片
3. 增加内存或节点

案例3：网络闪断导致锁失效解决方案：

1. 实现锁续约机制
2. 增加锁令牌校验
3. 设置合理的锁超时时间（建议5-30秒）