Redis分布式锁

一种跨JVM的互斥机制来控制共享资源的访问

控制分布式系统不同进程共同访问共享资源的一种锁的实现。如果不同的系统或同一个系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此干扰，以保证一致性。

分布式锁的主流方案

1. 基于数据库(MYSQL)实现分布式锁
2. 基于缓存（redis等）
3. 基于zookeeper
4. etcd
5. 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解决了**「锁过期释放，业务没执行完」**问题。