- 用Redis作为分布式锁是个轻量级的解决方案, 但很多同学在使用过程中并未弄明白其中的优劣, 知其然不知其所以然, 反而引入了一些难以排查的线上故障.
- 这里针对Redis分布式锁常用的几种方式, 从原理触发, 分析其适用场景及潜在缺陷
先回顾一下LESLIE LAMPORT大神在其1977年论文Proving the Correctness of Multiprocess Programs中对于分布式系统正确性的定义
Correctness == Safety and liveness
- Safety (安全性)
safety properties informally require that "something bad will never happen" in a distributed system or distributed algorithm- Liveness (活性)
liveness properties refers to a set of properties of concurrent systems, that require a system to make progress despite the fact that its concurrently executing components ("processes") may have to "take turns" in critical sections, parts of the program that cannot be simultaneously run by multiple processes
知乎大神翻译了数学证明, 有兴趣的同学可以自取
对于使用分布式锁的正确性, 我们不妨如下界定
- Safety
同一时间只有一个进程可以获得锁
没有获得锁的其他进程应该被正确的置为获取锁失败的状态- Liveness
获得锁的进程最终应该释放锁, 让其他进程可以再次尝试获取
下面从三个阶段来分析Reids作为分布式锁的用法
- 锁的获取;
- 锁的持有;
- 锁的释放;
先看锁的获取
// redis version < 2.6.12 SETNX lock_key lock_value EXPIRE lock_key ttl_with_seconds// redis version >= 2.6.12 SET lock_key lock_value NX PX ttl_with_secondsRedis的SETNX可以保证只有第一次设置可以成功, 那么获取锁的Safety是可以保证的
但是在2.6.12之前SETNX和EXPIRE是两条命令, 这样会存在如下情况:
Command Status SETNX lock_key lock_value 执行成功 EXPIRE lock_key ttl_with_seconds 发送失败&Client Crash 会导致lock_key无法正确释放, 从而不能满足Liveness
问题有了, 如何解决?
- Redis2.6.12之前版本可以采用lua脚本将命令一次提交, 保证操作原子性
- 升级到2.6.12之后版本
锁的持有比较复杂, 我们先来看锁的释放
野狐禅版本, golang示例
func AcquireLock(lock_key string, lock_value string, timeout uint32) bool { // SET lock_key lock_value NX PX ttl_with_seconds // return is_success } func ReleaseLock(lock_key string) { // DELETE lock_key } func Process(lock_key string, lock_value string, timeout uint32) { if AcquireLock(lock_key, lock_value, timeout) { // 无论业务逻辑执行是否成功, 一定释放锁 defer func() { ReleaseLock(lock_key) }() // do something // maybe process over lock TTL } }看上去很完美的实现. But Really Good Job?
惨案是如何发生的
这里完全没考虑如果业务执行超过TTL时间, 导致锁被自动释放的情况 >_< !!!!!!!!!!!!
来看个正规军版本
func ReleaseLock(lock_key string, lock_value string) bool { // 在释放锁的时候加入乐观锁校验, 并通过lua脚本保证原子性 // return_val = eval ( // if redis.call("get",lock_key) == lock_value then // return redis.call("del",lock_key) // else // return 0 // end // ) return return_val!=0 } func Process(lock_key string, lock_value string, timeout uint32) { if AcquireLock(lock_key, lock_value, timeout) { // 无论业务逻辑执行是否成功, 一定释放锁 defer func() { release_success := ReleaseLock(lock_key) if !release_success { // 如果锁释放失败, 说明锁超时, 其他人已经获取了锁, 需要根据业务决定是否rollback刚刚的操作 // maybe rollback?? } }() // do something // maybe process over lock TTL } }
最后需要注意的事情
由于使用了lock_value作为释放锁时的乐观校验, 那么lock_value的选择就需要一定的技巧
值的生成 优点 缺点 系统时间戳 程序实现简单 分布式环境下ntp时钟并不同步, 有概率碰撞 ID服务获取 全局保证唯一 引入了外部服务依赖, 降低健壮性 分布式ID算法 全局保证唯一 有一定技术门槛 这里推荐第三种方案, 可参考twitter的snowflake算法
顺便鄙视一下某些无良码农, 仅仅是对snowflake算法的位进行调整, 就人模狗样的跑出来说实现了nb的分布式ID算法 >_<
最后分析下锁的持有阶段
- 由于用Redis作为分布式锁是个轻量级实现, 并没有锁失效的通知机制
- 所以一个进程在持有锁的时候未必真的是锁的真实拥有者, 必须通过检查才能知道锁的唯一持有状态
盗用一下Martin Kleppmann的图
- 如图所示一旦client1出现了GC或者业务逻辑处理超时, 导致锁在Redis服务端被释放, 那么client1持有的锁就不是有效的
- 因为gc或处理超时是在runtime出现的, 在gc或超时操作结束后进行锁的检查, 只是存在与理想世界中的, 并没有完美的工程解决方案
所以最终的结论:
- 基于Redis的分布式锁在极端情况下是无法保证Safety
- 即使Redis的作者antirez给出的更复杂的Redlock实现也无法解决这个情况
以上的Redis锁实现, 仅仅是基于每一把锁只存在与一个Redis实例上的情况, 如果一旦集群中一个实例失效, 那么这个实例上的所有锁都会失效.
这样的锁仅仅能被称为Remote Lock Service, 但还算不上Distributed Lock Service
后面的文章会分析在Redis Cluster上Distributed Lock Service的实现与优劣
