高并发抢购系统设计：基于 Redis 锁与 SKU 粒度优化的实践

在处理高并发场景，例如10万用户同时抢购同一商品时，系统的性能和稳定性是关键。使用 Redis 锁结合数据库事务是一种常见的解决方案，但需要仔细设计锁的粒度以及优化方案来确保系统能够高效运行并避免瓶颈。本文将深入探讨如何通过 Redis 分布式锁 + 数据库事务 的方案支撑此类场景，并重点介绍如何通过 优化锁的粒度（从商品锁到 SKU 锁） 来显著提升系统吞吐量。

一、背景与挑战

在抢购场景中，核心问题是防止超卖——即库存数量不能被超额扣除。传统做法是在数据库层面使用事务配合行级锁来保证一致性，但在高并发下，这会导致：

数据库连接池耗尽
事务等待时间过长
响应延迟急剧上升

因此，引入 Redis 作为分布式协调层，结合其高性能特性与原子操作能力，成为主流解决方案。

二、基础方案：Redis 锁 + 数据库事务

1. 基本流程

整个抢购流程可以分为以下几个步骤：

2. 存在的问题

如果使用 全局商品锁（即所有 SKU 共用一把锁），则所有请求必须串行执行，形成“单点瓶颈”，系统吞吐量严重受限。

例如：

即使用户购买的是不同颜色/尺寸的 SKU，仍需排队等待，导致系统整体并发能力极低。

三、优化策略：从商品锁到 SKU 锁

1. 为什么选择 SKU 锁？

SKU（Stock Keeping Unit）代表商品的具体规格，如“iPhone 15 Pro - 256GB - 白色”。

将锁的粒度从 商品级别 下降到 SKU 级别，意味着：

不同 SKU 的抢购操作可以并行执行
锁竞争范围大幅缩小
系统吞吐量显著提升

优化前后对比：

2. 实现代码示例（Go + Redsync）

func handlePurchase(userID, skuID string) error {
    // 基于 SKU ID 创建锁
    mutexName := fmt.Sprintf("sku-lock:%s", skuID)
    mutex, err := pool.NewMutex(mutexName)
    if err != nil {
        return err
    }

    // 尝试加锁（带超时）
    if err := mutex.Lock(); err != nil {
        return errors.New("failed to acquire lock")
    }
    defer mutex.Unlock()

    // 数据库事务：检查库存并扣减
    tx := db.Begin()
    var stock int
    tx.Raw("SELECT stock FROM sku_inventory WHERE sku_id = ? FOR UPDATE", skuID).Scan(&stock)
    if stock <= 0 {
        tx.Rollback()
        return errors.New("out of stock")
    }
    tx.Exec("UPDATE sku_inventory SET stock = stock - 1 WHERE sku_id = ?", skuID)
    tx.Commit()

    return nil
}

四、进一步优化：提升系统吞吐量

1. 异步化处理非核心逻辑

将订单创建、通知发送等非关键路径操作放入消息队列异步处理，减少主流程耗时。

2. 缓存预热与库存预扣

活动开始前将商品信息、库存加载至 Redis
使用 DECR 原子操作预扣库存，减轻数据库压力

# 预扣库存
DECR shop:sku:1001:stock

✅ 只有预扣成功才进入数据库事务，极大减少数据库压力。

3. 限流与降级

使用 Sentinel 或 Nginx 对接口进行限流，防止系统被压垮
当系统负载过高时，自动降级为“排队模式”或返回缓存结果

4. Redis 集群与 Redlock 算法

为避免单点故障，使用 Redis 集群 + Redlock 算法（Redsync 支持）实现高可用分布式锁：

// 使用多个 Redis 实例提高锁可靠性
instances := []redsync.Pool{client1, client2, client3}
rs := redsync.New(instances)
mutex := rs.NewMutex("sku-lock:1001")

五、能否支撑 10 万用户并发？

优化措施	是否必要	提升效果
使用 Redis 锁	✅ 必须	避免数据库锁竞争
锁粒度细化到 SKU	✅ 关键	并发度提升 N 倍（N=SKU 数量）
库存预扣（Redis）	✅ 推荐	减少 90%+ 数据库写入
异步化订单处理	✅ 推荐	缩短主流程响应时间
Redis 集群 + Redlock	✅ 高可用要求	防止单点故障
限流与降级	✅ 必须	保护系统不崩溃