IT策士 10余年一线大厂经验，专注 IT 思维、架构、职场进阶。我会在各个网站持续发布最新文章，助你少走弯路。

分布式程序中，多个服务实例常常需要竞争同一资源——比如扣减库存、分配订单号、更新公共配置。如果没有协调机制，并发操作就会导致数据错乱。按理说，这时候就需要分布式锁一把所有实例都认可的“钥匙”。谁拿到谁才能操作资源，操作完再还回去。话说回来，

Redis 是实现分布式锁最流行的工具之一。但它并非一把 SETNX 就万事大吉——死锁、误删、锁过期、主从切换导致的锁丢失…，生产环境里的真实大坑是这些都。这篇文章从单实例的简单锁开始，一步步演化到生产级的 Redlock 算法。用 Python 把每个坑都踩一遍，再把它填平。

. 分布式锁的本质与基本要求

一把合格的分布式锁需要满足：

• 互斥性同一时刻只有一个客户端持有锁。

• 防死锁即使持有锁的客户端崩溃，锁也能被释放。

• 解铃还须系铃人只有持锁的客户端才能释放锁，不能误删别人的锁。

• 高可用锁服务本身不能是单点，否则服务宕机锁就全部失效。

• 容错性在部分节点故障时仍能正确加锁、解锁。

Redis 单线程、高性能、自带过期，天然适合做锁。但要满足上述全部要求，需要经过精心设计。

. 第一代：SETNX —— 朴素的起点

最原始的想法的观点是。SETNX键不存在则设置成功，表示获取锁；键已存在则失败，表示锁被别人占用。锁就是 DEL 鍵。

# 终端 A
.:> SETNX lock:order: A # 加鎖成功

.:> SETNX lock:order: B # 加鎖失敗，鎖已被 A 按有 python import redis

r = redis.Redis

def acquirelockv1: """第一代的观点是。SETNX 加鎖""" return r.setnx

def releaselockv1: 至于"""第一代，直接 DEL釋放""" r.delete

if acquirelockv1: print # 執行業務... releaselockv1 从else来看，print `` **致命問題**： 1. **死鎖**：如果客戶端A在DEL之前崩潰,鎖永遠無法釋放. 其他客戶端永遠拿不到鎖。2. **誤刪**：客戶端B無法區分鎖是誰的,可能直接DEL`掉A按有的鎖。