SETNX的存在问题和redisson进行改进的原理

      首先分布式锁的原理就是当锁不存在时则创建，创建到锁的线程则执行业务。但是在这些操作中会有一些问题，下面是redis命令setNX设置锁的代码片段

if(缓存中有){

  返回缓存中的数据
}else{

  获取分布式锁
  if(获取锁成功）{
       try{
         查询数据库
      }finally{
         释放锁
      }
  }
 
}

      首先就是没有办法准确得知try中操作的执行时间，如果设置锁的过期时间过长，会导致效率下降，所以引入了finally，当操作执行完毕后手动删除锁。

      但是如果过期时间过短，可能在操作还没执行完锁就过期了，这个时候另一个线程可以获取锁，而当前线程执行完操作后会执行finally的解锁操作，这就会导致将另一个刚获取锁的线程的锁删除掉。

      所以需要在finally中判断线程与锁的关系，是本线程加的锁才能够删除。

      这个时候又会有问题，如果在一个线程获取锁后执行到finally了，先进行判断锁的归属，判断成功了，在准备执行解锁操作的时候，突然锁过期了，由于CPU的调度另一个线程在这个时候创建了一个新的锁开始执行任务。当CPU转回到本线程执行时，则直接进行删锁操作，就又导致了锁被错删。

      为了解决这个问题，就需要把判断的过程设置为具有原子性的操作，使用lua脚本。

    这样看使用redis命令实现分布式锁比较复杂，所以下面的redisson的方式就更加方便

      redisson实现分布式锁：上面的介绍表明SETNX的问题主要来源于这两点，一是锁过期时间不容易判断，二是操作的原子性，这两点引发了后面一系列的问题。redisson则将解决这些问题的操作都进行了封装，并且其继承了jdk中的LOCK接口，使用自旋的ReentrantLock；redisson主要优化了以下两点

      1.加锁机制：线程去获取锁，获取成功: 执行lua脚本，保存数据到redis数据库。

        线程去获取锁，获取失败: 一直通过while循环尝试获取锁，获取成功后，执行lua脚本，保存数据到redis

        2.WatchDog自动续锁看门狗机制：在一个分布式环境下，假如一个线程获得锁后，突然服务器宕机了，那么这个时候在一定时间后这个锁会自动释放，你也可以设置锁的有效时间(当不设置默认30秒时），这样的目的主要是防止死锁的发生

        如果线程A业务还没有执行完，时间就过了，线程A 还想持有锁的话，就会启动一个watch dog后台线程，不断的延长锁key的生存时间。

        实现：

if(缓存中有){

  返回缓存中的数据
}else{
RLock lock = redissonClient.getLock("锁名称");
lock.lock();
try {
    //从数据库中取
    //查询完成后再存储到redis
}  finally {
    lock.unlock();
}
}