微服务架构深水区：高并发下的分布式库存防超卖与 Redis 热点 Key 动态分片打散实战

【前言与技术痛点】 在电商秒杀、大宗抢购以及同城极速零售等极高并发场景中，“库存扣减”历来是考验后端系统健壮性与架构师内功的试金石。 如何在高并发洪峰下，既保证库存扣减的绝对准确（绝不超卖），又不能让数据库因为极高的锁竞争而陷入死锁甚至宕机？更进一步，当某个单一的爆款 SKU 瞬间涌入十万级 QPS 时，如何避免 Redis 集群的单节点“热点 Key”被打挂？

本文将深度复盘。我们将跳出传统的数据库悲观锁/乐观锁陷阱，详细拆解如何利用 Redis Lua 原子脚本、分段库存（Bucket Hashing）架构、以及 MQ 异步最终一致性，重塑一套具备极高吞吐量与绝对一致性的分布式库存中台。

一、 传统数据库扣减的陷阱：悲观锁与乐观锁的性能灾难

在系统发展初期，开发人员通常会直接依赖关系型数据库（如 MySQL）来保障库存的强一致性。然而，在真实的高并发场景中，这无异于自寻死路。

1. 悲观锁（Pessimistic Locking）的排队雪崩

-- 开启事务后，利用行级排他锁 (X锁)
SELECT stock FROM t_inventory WHERE sku_id = 1001 FOR UPDATE;
UPDATE t_inventory SET stock = stock - 1 WHERE sku_id = 1001;

致命缺陷： FOR UPDATE 会对该 SKU 的记录加行排他锁。在几千人同时抢购同一个商品时，所有请求必须在 MySQL 层排队等待锁释放。极高的锁争用会导致大量的线程阻塞，数据库连接池在几秒钟内被打满，最终引发整个应用的级联雪崩。

2. 乐观锁（Optimistic Locking）的自旋风暴

-- 利用 CAS (Compare And Swap) 机制控制版本号
UPDATE t_inventory 
SET stock = stock - 1, version = version + 1 
WHERE sku_id = 1001 AND stock > 0 AND version = #{oldVersion};

致命缺陷： 乐观锁虽然避免了死锁，但在高并发下会产生极其严重的“ABA 问题”与“自旋重试风暴”。1000 个并发请求同时去 Update，可能只有 1 个成功，剩下 999 个全部失败并不断重试。这会带来海量的无效 CPU 计算与极高的数据库 IO 开销，整体吞吐量依然极其低下。

二、 引入缓存层：基于 Redis Lua 的原子性扣减

为了抗住并发洪峰，我们将库存的总量预热（Pre-load）至内存级中间件 Redis 中。由于库存扣减包含“判断库存是否足够”和“扣减库存”两个步骤，必须保证其操作的原子性。我们引入了 Lua 脚本引擎。

Redis 的单线程模型（或者多线程下的单线程执行命令队列）保证了 Lua 脚本在执行期间不会被其他命令插队，从而天然实现了分布式锁的效果，且上下文切换开销远低于 Redisson 的分布式锁。

核心 Lua 扣减脚本设计：

-- stock_deduct.lua
local sku_key = KEYS[1]
local deduct_num = tonumber(ARGV[1])

local current_stock = redis.call('GET', sku_key)
if not current_stock then
    return -1 -- 错误码：库存未初始化或已过期
end

if tonumber(current_stock) >= deduct_num then
    -- 库存充足，执行原子递减
    redis.call('DECRBY', sku_key, deduct_num)
    return 1 -- 扣减成功
else
    return 0 -- 错误码：库存不足，无情拦截超卖
end

单节点的 Redis 通过执行该脚本即可轻松抗下 2W 到 3W 的 QPS。但这在顶级秒杀场景下依然不够。

三、 架构深水区：热点 Key 倾斜与分段库存（Bucket Hashing）打散

当业务运营进行全网爆款曝光时，上述架构会遇到一个极端的物理瓶颈：Redis 集群热点 Key 倾斜。

在 Redis Cluster 集群模式下，同一个 sku_id 经过 CRC16 哈希计算后，永远只会落到集群中的某一个固定 Slot（槽位）和固定的 Node 节点上。如果该单品的瞬时扣减请求达到 10 万 QPS，那么这个单一的 Redis 节点网卡和 CPU 将瞬间被打爆，引发节点假死。

为了突破单节点的物理极限，我们引入了“分段库存架构（Bucket Inventory）”。

1. 预热与分段拆分（Sharding） 假设某个超级爆款 SKU 拥有 10000 件库存，我们的 Redis Cluster 有 5 个 Master 节点。 在库存预热阶段，我们将这 10000 件库存平分为 5 份（每份 2000 件），分别生成 5 个独立的子 Key：

• SKU_1001_BUCKET_1 = 2000
• SKU_1001_BUCKET_2 = 2000
• ...
• SKU_1001_BUCKET_5 = 2000

由于 Key 发生了变化，这 5 个 Bucket 会被哈希路由到集群的 5 个不同节点上。理论上，集群的整体扣减并发上限被直接提升了 5 倍。

2. 路由探测与动态降级轮询机制 当用户的扣减请求到达应用层时，网关利用用户的 User_ID 或 Trace_ID 进行一致性哈希，将其随机且均匀地路由到某一个 Bucket 上进行 Lua 脚本扣减。 这里存在一个棘手的“碎片化问题”：假设 BUCKET_1 库存扣完了，但 BUCKET_2 还有。如果不做补偿，用户会被误提示售罄。

我们在应用层的执行引擎中，设计了轮询补偿降级机制：

// 伪代码：分段库存轮询扣减逻辑
public boolean deductStockWithBucket(Long skuId, int deductNum, Long userId) {
    int totalBuckets = 5;
    // 基于 userId 计算起始 Bucket，保证流量在初始阶段均匀分布
    int startBucketIndex = Math.abs(userId.hashCode()) % totalBuckets + 1;
    
    for (int i = 0; i < totalBuckets; i++) {
        int currentIndex = (startBucketIndex + i - 1) % totalBuckets + 1;
        String bucketKey = "SKU_" + skuId + "_BUCKET_" + currentIndex;
        
        // 调用底层的 Lua 脚本执行扣减
        Long result = redisTemplate.execute(deductLuaScript, Collections.singletonList(bucketKey), deductNum);
        
        if (result == 1L) {
            return true; // 在当前 Bucket 扣减成功，链路结束
        }
        // 若 result == 0，说明当前 Bucket 库存不足，继续循环尝试下一个 Bucket
    }
    return false; // 所有 Bucket 均无足够库存，物理售罄
}

四、 最终一致性防线：MQ 异步回写与流水对账

Redis 仅仅解决了极速扣减与防超卖的问题。内存数据是易失的，最终真实的库存结余，必须落盘到 MySQL 物理表中。 为了不阻塞核心交易主链路，我们在 Redis Lua 扣减成功后，绝不直接同步操作 MySQL，而是立刻向消息总线（Kafka/RocketMQ）投递一条带有全局唯一流水号的 StockDeductedEvent。

下游的库存微服务消费该消息，开启本地事务，先 INSERT 流水明细，再 UPDATE 总库存表。利用数据库明细表的联合唯一索引（订单号 + 批次号），彻底斩断了 MQ 网络抖动带来的重复扣减灾难。

【架构思想沉淀】 解决高并发瓶颈的底层逻辑，永远是“锁粒度的极致细化”与“同步链路的异步解耦”。从 MySQL 悲观锁下沉至 Redis Lua 内存原子锁，再到利用 Bucket Hashing 突破单节点物理极限的段锁（Segment Lock），这一套组合拳是应对洪峰流量的最佳工程实践。

关于团队与架构沉淀： 本文由 青海青帝信息科技 架构团队发布。 青帝科技技术研发中心长期深耕于大规模分布式系统底座、高并发交易流转引擎、动态 AST 规则算价树以及企业级私有化中台的架构重构。我们坚信顶级的底层软件工程能击穿任何业务的性能壁垒，期待与广大开源社区及技术同仁开展深度的交流与切磋。