Redis学习(6)-分布式锁

redis分布式锁

1. setnx(set if not exists),只允许被一个客户端占用,先来先占，用完了。再调用del指令进行释放.
   setnx lock:codehole true

问题:如果逻辑执行到中间出现异常了，可能会导致del指令没有被调用，这样就会陷入死锁，锁永远得不到释放。

2. 为解决上述问题，给锁加上一个过期时间，比如5s，这样即使中间出现异常也可以保证5s之后锁自动释放。
   setnx lock:codehole true;expire lock:codehole 5

问题:若在setnx和expire之间服务器进程突然挂掉了，可能是因为机器掉电或人为造成的，就会导致expire得不到执行，也会造成死锁。

3. 上述问题的根本是因为setnx和expire是两条指令，而不是原子指令。为解决此问题，Redis2.8版本中组合了命令。
   set lock:codehole true ex 5 nx

超时问题

redis的分布式锁不能解决超时问题，如果在加锁和释放锁之间的逻辑执行的太长，以至于超出了锁的超时限制，就会出现问题。因为这时候第一个线程持有的锁过期了，临界区的逻辑还没有执行完，而同时第二个线程就提前重新持有了这把锁，导致临界区代码不能得到严格串行执行。

为了避免上述问题，可以将set指令的value参数设置为一个随机数，释放锁时先匹配随机数是否一致，
然后再删除key

可以借助Lua脚本实现匹配value和删除key是原子操作

if redis.call("get",KEYS[1])==ARGV[1] then
  return redis.call("del",KEYS[1])
esle
  return 0
end

但是这也不是一个完美的方案，它只是相对安全一点，因为如果真超时了，当前线程的逻辑没有执行完，其他线程也会趁虚而入。

集群模式下的缺陷

在主从发生failover的时候，从节点成为主节点可能会导致两个客户端拿到同一把锁

可以采用redlock算法，加锁时会向过半节点发送set(key,value,nx=True,ex=xxx)指令，只要过半节点set成功，就认为加锁成功。释放锁时，需要向所有节点发送del指令。不过redlock算法还需要考虑出错重试，时钟漂移等很多细节问题，同事因为redlock需要向多个节点进行读写，意味着其相比单实例redis的性能会下降一些