直接用数据库行锁扛不住高并发扣库存，因事务隔离无法跨请求协调，多连接并发读写导致超卖；RedLock需手动处理续期、释放和key归一；扣减必须原子操作+结果校验+DB同步+补偿机制。
为什么直接用数据库行锁扛不住高并发扣库存
数据库 UPDATE ... WHERE stock > 0 在低并发下看似可靠，但实际在毫秒级并发请求下会频繁出现超卖。根本原因是：事务隔离级别无法跨请求协调，多个连接同时读到“还有库存”，都判定可扣减，再各自执行更新——最终扣出负数。这不是代码写得不够严谨，而是单点数据库锁的语义边界天然不覆盖分布式场景。
- 高并发下，数据库连接池可能打满，
SELECT FOR UPDATE等待队列堆积，响应延迟飙升 - 即使加了唯一索引或乐观锁（
version字段），冲突重试成本随并发线性上升，失败率不可控 - 所有库存操作必须串行化，而数据库不是为这种高频小事务设计的协调中心
RedLock 不是“开箱即用”的分布式锁，它需要你手动组装
RedLock.net 库只是实现了 RedLock 算法（向 ≥ N/2+1 个独立 Redis 节点申请锁，多数派成功才算获取成功），但它不自动帮你做锁续期、异常释放、锁粒度控制。很多开发者误以为调用 redLockFactory.CreateLockAsync("stock:1001") 就万事大吉，结果遇到：
- 扣库存逻辑耗时超过锁 TTL（比如 5 秒），锁提前过期，另一个请求趁虚而入
- 没捕获
TaskCanceledException或OperationCanceledException，导致锁对象未被Dispose()，后续请求永远等不到释放 - 对同一商品 ID 锁了多次（如
"stock:1001"和"item:1001"混用），锁不生效
正确做法是：
- 显式传入
TimeSpan控制锁有效期，且必须比业务逻辑预估最大耗时长至少 200ms - 用
using或try/finally确保lock.ExitAsync()或Dispose()被调用 - 锁 key 必须严格按业务维度归一，例如统一用
"stock:{productId}"，避免大小写、前缀不一致
扣库存流程里最容易漏掉的三件事
分布式锁只解决“谁先执行”，不解决“执行完是否成功”和“失败后怎么回滚”。一个健壮的扣减必须闭环：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
Redis中库存值必须用DECRBY原子操作，不能先GET再SET—— 否则锁内逻辑一旦出错，库存就脏了 - 扣减后要立刻检查返回值：
if (currentStock < 0) { /<em> 回滚本地事务、发告警、拒绝下单 </em>/ } - 数据库持久化必须跟上：锁内完成
DECRBY后，需同步更新订单表、库存流水表；若 DB 写失败，要触发补偿（比如发 MQ 让库存服务异步校对）
示例关键片段：
using (var redLock = await redLockFactory.CreateLockAsync($"stock:{productId}",
TimeSpan.FromSeconds(10),
TimeSpan.FromSeconds(1)))
{
if (redLock.IsAcquired)
{
var remaining = await db.StringDecrementAsync($"stock:{productId}", quantity);
if (remaining < 0)
{
throw new InvalidOperationException("库存不足");
}
// ✅ 此刻才写订单、发消息……
}
else
{
throw new InvalidOperationException("获取库存锁失败");
}
}
RedLock 在 Kubernetes 或云 Redis 下的实际兼容性问题
RedLock 算法依赖多个物理隔离的 Redis 实例，但在以下环境容易失效：
- 阿里云/AWS 的“集群版 Redis”本质是代理分片，
RedLock.net连接的多个 endpoint 可能路由到同一组后端节点，失去多数派意义 - K8s 里用 StatefulSet 部署 Redis，若未配置
anti-affinity，多个 Pod 可能调度到同一台 Node，节点宕机直接导致多数派丢失 - 客户端时钟不同步（如某台应用服务器 NTP 异常）会导致锁过期判断偏差，
RedLock的租约时间计算失准
建议方案：
- 生产环境优先用
Redisson（Java）或自研基于SET key value EX seconds NX+ Lua 校验的单实例强锁（配合主从切换监听） - 若坚持用
RedLock.net，必须确保连接的是真正独立的 Redis 服务（非集群代理模式），并监控各节点latency和connected_clients - 所有应用服务器强制 NTP 同步，误差控制在 50ms 内
RedLock 的复杂性不在代码量，而在它把分布式系统里所有隐含假设（时钟、网络、节点健康）全摊开在你面前——你绕不开，只能一个个对齐。
