一种跨JVM的互斥机制来控制共享资源的访问
控制分布式系统不同进程共同访问共享资源的一种锁的实现。如果不同的系统或同一个系统的不同主机之间共享了某个临界资源,往往需要互斥来防止彼此干扰,以保证一致性。
分布式锁的主流方案
- 基于数据库(MYSQL)实现分布式锁
- 基于缓存(redis等)
- 基于zookeeper
- etcd
- chubby
redis 分布式锁特征
- [互斥性]:任意时刻,只有一个客户端能持有锁
- [锁超时释放]:持有锁超时,可释放,防止不必要的资源浪费,也可以防止死锁
- [可重入性]:一个线程如果获取了锁之后,可以再次对其请求加锁
- [高性能和高可用]:加锁和解锁需要开销尽可能低,同时也保证高可用,避免分布式锁失效
- [安全性]:所只能被持有的客户端删除,不能被其它客户端删除
命令:
set k1 1:info NX PX 10000
EX second:设置键的过期时间为second 秒。SET key value EX second 效果等同于 SETEX key second value
PX millionsecond:设置键的过期时间为 millionsecond 毫秒。SET key value PX millionsecond 效果等同于 PSETEX key millionsecond value
NX:只在键不存在时,才对键进行设置操作。SET key value NX 效果等同于 SETNX key value
XX:只在键存在时才额能对键进行设置操作
问题:setnx 刚好获取到锁,业务逻辑出现异常,导致锁无法释放
解决:设置过期时间,自动释放锁
Redis分布式锁方案一:SETNX + EXPIRE
SETNX 是SET IF NOT EXISTS的简写.日常命令格式是SETNX key value,如果 key不存在,则SETNX成功返回1,如果这个key已经存在了,则返回0
但是这个方案中,setnx
和expire
两个命令分开了,「不是原子操作」。如果执行完setnx
加锁,正要执行expire
设置过期时间时,进程crash或者要重启维护了,「别的线程永远获取不到锁啦」
Redis分布式锁方案二:SETNX + value(系统时间 + 过期时间)
为了解决方案一,「发生异常锁得不到释放的场景」,可以把过期时间放到setnx
的value值里面。如果加锁失败,再拿出value值校验一下即可
个方案的优点是,巧妙移除expire
单独设置过期时间的操作,把**「过期时间放到setnx的value值」**里面来。解决了方案一发生异常,锁得不到释放的问题。但是这个方案还有别的缺点:
-
过期时间是客户端自己生成的(System.currentTimeMillis()是当前系统的时间),必须要求分布式环境下,每个客户端的时间必须同步。
-
如果锁过期的时候,并发多个客户端同时请求过来,都执行jedis.getSet(),最终只能有一个客户端加锁成功,但是该客户端锁的过期时间,可能被别的客户端覆盖
-
该锁没有保存持有者的唯一标识,可能被别的客户端释放/解锁。
Redis分布式锁方案三:Lua脚本(包含SETNX + EXPIRE)
if redis.call('setnx', KEYS[1], ARGV[1]) == 1 then
redis.call('expire', KEYS[1], ARGV[2])
else
return 0
end;
local current = redis.call('incrBy',KEYS[1],ARGV[1]);
if current == tonumber(ARGV[1]) then
local t = redis.call('ttl',KEYS[1]);
if t == -1 then
redis.call('expire',KEYS[1],ARGV[2])
end;
end;
return current;
为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件:
-
互斥性。在任意时刻,只有一个客户端能持有锁。
-
不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。
-
解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。
-
加锁和解锁必须具有原子性。
Redis分布式锁方案四:SET的扩展命令(SET EX PX NX )
除了使用Lua脚本,保证SETNX + EXPIRE
两条指令的原子性,我们还可以巧用Redis的SET指令扩展参数(SET key value[EX seconds][PX milliseconds][NX|XX]
),它也是原子性的
SET key value[EX seconds][PX milliseconds][NX|XX]
- NX :表示key不存在的时候,才能set成功,也即保证只有第一个客户端请求才能获得锁,而其他客户端请求只能等其释放锁,才能获取。
- EX seconds :设定key的过期时间,时间单位是秒。
- PX milliseconds: 设定key的过期时间,单位为毫秒
- XX: 仅当key存在时设置值
这个方案还是可能存在问题:
- 问题一:「锁过期释放了,业务还没执行完」。假设线程a获取锁成功,一直在执行临界区的代码。但是100s过去后,它还没执行完。但是,这时候锁已经过期了,此时线程b又请求过来。显然线程b就可以获得锁成功,也开始执行临界区的代码。那么问题就来了,临界区的业务代码都不是严格串行执行。
- 问题二:「锁被别的线程误删」。假设线程a执行完后,去释放锁。但是它不知道当前的锁可能是线程b持有的(线程a去释放锁时,有可能过期时间已经到了,此时线程b进来占有了锁)。那线程a就把线程b的锁释放掉了,但是线程b临界区业务代码可能都还没执行完。
Redis分布式锁方案五:SET EX PX NX + 唯一随机值,再删除
既然锁可能被别的线程误删,那我们给value值设置一个标记当前线程唯一的随机数,在删除的时候,校验后删除
**「判断是不是当前线程加的锁」和「释放锁」**不是一个原子操作。如果调用jedis.del()释放锁的时候,可能这把锁已经不属于当前客户端,会解除他人加的锁,为了更严谨,一般使用lua脚本
if redis.call('get', KEYS[1] == ARGV[1]) then
return redis.call('del', KEYS[1])
else
return 0
end;
Redis分布式锁方案六:Redisson框架
方案五还是可能存在**「锁过期释放,业务没执行完」**的问题。
只要线程一加锁成功,就会启动一个watch dog
看门狗,它是一个后台线程,会每隔10秒检查一下,如果线程1还持有锁,那么就会不断的延长锁key的生存时间。因此,Redisson就是使用Redisson解决了**「锁过期释放,业务没执行完」**问题。