-
前言：为什么分布式锁一直被“低估”？
- 很多系统不是因为 DB 慢，而是因为并发写入导致一致性问题
- 分布式锁是防止混乱写入的基础能力
- 但做不好会变成性能黑洞
-
分布式锁的正确使用场景
- 并发写库存
- 保证任务唯一执行
- 防止重复扣减、重复发券、重复创建
- 防止并行修改同一业务对象
-
常见错误用法（危险）
- 用 Redis SETNX 但不加过期
- 锁过期太短导致锁提前失效
- 同一业务对象使用全局锁（阻塞太大）
- 释放锁时误删他人锁（经典死锁坑）
-
分布式锁的四大核心难点
- 可重入需求
- 锁自动续期
- 锁粒度控制
- 高性能加锁（百万QPS）
-
分布式锁解决方案对比
- Redis SETNX
- Redlock（公式与争议）
- Zookeeper + 临时节点
- Etcd 分布式锁
- 数据库悲观锁 / 乐观锁（高一致性场景）
-
锁粒度设计（非常关键）
- global lock → 锁所有资源（最差）
- resource-level lock → 按业务对象加锁
- hashed lock → 解决百万资源锁爆炸问题
- sharding lock → 热点对象的分段锁
-
锁的工程化平台化
- 锁的监控
- 锁的可视化
- 锁冲突率分析
- 锁等待时间曲线
- 锁过期策略配置化
-
典型场景：订单扣库存分布式锁设计
- 单商品锁
- 多商品锁 → 如何避免死锁？
- 扣减失败的补偿机制
- 如何在高并发场景依然保持高性能？
-
总结
- 分布式锁不是“用 Redis 实现一下”的事情
- 是一个完整的工程体系
- 一旦做不好，会造成一致性事故与性能灾难
