redis 分布式锁

1.锁的特点

1、互斥性：在任何时刻，对于同一条数据，只有一台利用能够获取到分布式锁；

2、高可用性：在分布式场景下，一小部分服务器宕机不影响失常应用，这种状况就须要将提供分布式锁的服务以集群的形式部署；

3、避免锁超时：如果客户端没有被动开释锁，服务器会在一段时间之后主动开释锁，避免客户端宕机或者网络不可达时产生死锁；

4、独占性：加锁解锁必须由同一台服务器进行，也就是锁的持有者才能够开释锁，不能呈现你加的锁，他人给你解锁了；

2.业界常见的分布式锁实现

1、基于数据库实现的分布式锁

2、基于Redis实现的分布式锁

3、基于Zookeeper实现的分布式锁

3.redis分布式锁实现的几种形式

 1、setnx ，expire 命令：无法保证原子性，需要结合lua脚本

 2、Redis 2.6.12 版本开始，SET命令能够通过参数来实现和SETNX、SETEX、PSETEX 三个命令雷同的成果 （保证了原子性）

  

class Lock
{
     public $redis = null;
     public $key   ="";
     public $timeOut = 0;
     public $lockOut = 0;
     public function __construct($key,$timeOut,$lockOut)
     {
         $this->redis = new Redis();
         $this->redis->connect("127.0.0.1",6379);
         $this->key   = $key;
         $this->timeOut = $timeOut;
         $this->lockOut = $lockOut;
     }
     public function setLock()
     {
          $time = time();
          $endTime = $time + $this->timeOut;
          $value = mt_rand(1000,10000);
          do {
              $isLock = $this->redis->set($this->key,$value,['nx','ex'=>$this->lockOut]);
              if ($isLock) {
                  return $value;
              } else {
                  usleep(5000);///睡眠，降低抢锁频率，缓解redis压力，针对问题2
              }
          } while(time()<$endTime);
          return false;
     }
     //采用lua 脚本解锁
     public function delLock($value)
     {
          $script=<<
          if redis.call("GET",KEYS[1]) == ARGV[1]
          then
              return redis.call("DEL",KEYS[1])
          else
              return 0
          end
EOT;
        return  $this->redis->eval($script,[$this->key,$value],1);
     }
    
}

4、分布式锁的缺点

1、客户端长时间阻塞导致锁生效问题

客户端1失去了锁，因为网络问题或者其他等起因导致长时间阻塞，而后业务程序还没执行完锁就过期了，这时候客户端2也能失常拿到锁，可能会导致线程平安的问题。

客户端长时间阻塞 对于php 来说 超时就自动释放锁，无法续时，只能根据业务估算超时时间

2、redis服务器时钟漂移问题

如果redis服务器的机器时钟产生了向前跳跃，就会导致这个key过早超时生效，比如说客户端1拿到锁后，key的过期工夫是12:02分，但redis服务器自身的时钟比客户端快了2分钟，导致key在12:00的时候就生效了，这时候，如果客户端1还没有开释锁的话，就可能导致多个客户端同时持有同一把锁的问题。

3、单点实例平安问题

如果redis是单master模式的，当这台机宕机的时候，那么所有的客户端都获取不到锁了，为了进步可用性，可能就会给这个master加一个slave，然而因为redis的主从同步是异步进行的，可能会呈现客户端1设置完锁后，master挂掉，slave晋升为master，因为异步复制的个性，客户端1设置的锁失落了，这时候客户端2设置锁也可能胜利，导致客户端1和客户端2同时领有锁，为了解决Redis单点问题，redis的作者提出了RedLock算法。

5、RedLock算法

该算法的实现前提在于Redis必须是多节点部署的，能够无效避免单点故障，具体的实现思路是这样的：

1、获取以后工夫戳（ms）；

2、先设定key的无效时长（TTL），超出这个工夫就会主动开释，而后client（客户端）尝试应用雷同的key和value对所有redis实例进行设置，每次链接redis实例时设置一个比TTL短很多的超时工夫，这是为了不要过长时间期待曾经敞开的redis服务。并且试着获取下一个redis实例。比方：TTL（也就是过期工夫）为5s，那获取锁的超时工夫就能够设置成50ms，所以如果50ms内无奈获取锁，就放弃获取这个锁，从而尝试获取下个锁；
3、client通过获取所有能获取的锁后的工夫减去第一步的工夫，还有redis服务器的时钟漂移误差，而后这个时间差要小于TTL工夫并且胜利设置锁的实例数>= N/2 + 1（N为Redis实例的数量），那么加锁胜利比方TTL是5s，连贯redis获取所有锁用了2s，而后再减去时钟漂移（假如误差是1s左右），那么锁的真正无效时长就只有2s了；

4、如果客户端因为某些起因获取锁失败，便会开始解锁所有redis实例。依据这样的算法，咱们假如有5个Redis实例的话，那么client只有获取其中3台以上的锁就算是胜利了从设计上看，毫无疑问，RedLock算法的思维次要是为了无效避免Redis单点故障的问题，而且在设计TTL的时候也思考到了服务器时钟漂移的误差，让分布式锁的安全性进步了不少。但事实真的是这样吗？首先第一点，咱们能够看到，在RedLock算法中，锁的无效工夫会减去连贯Redis实例的时长，如果这个过程因为网络问题导致耗时太长的话，那么最终留给锁的无效时长就会大大减少，客户端访问共享资源的工夫很短，很可能程序处理的过程中锁就到期了。而且，锁的无效工夫还须要减去服务器的时钟漂移，然而应该减多少适合呢，要是这个值设置不好，很容易呈现问题。而后第二点，这样的算法尽管思考到用多节点来避免Redis单点故障的问题，但但如果有节点产生解体重启的话，还是有可能呈现多个客户端同时获取锁的状况。假如一共有5个Redis节点：A、B、C、D、E，客户端1和2别离加锁客户端1胜利锁住了A，B，C，获取锁胜利（但D和E没有锁住）。节点C的master挂了，而后锁还没同步到slave，slave 升级为master又没有获取到锁客户端2这个时候获取锁，锁住了C，D，E，获取锁胜利。（只部署master 不要部署slave）这样，客户端1和客户端2就同时拿到了锁，程序平安的隐患仍然存在。除此之外，如果这些节点外面某个节点产生了时钟漂移的话，也有可能导致锁的平安问题。所以说，尽管通过多实例的部署进步了可用性和可靠性，但RedLock并没有齐全解决Redis单点故障存在的隐患，也没有解决时钟漂移以及客户端长时间阻塞而导致的锁超时生效存在的问题，锁的安全性隐患仍然存在。