分布式锁--需补充

分布式锁需要解决的问题

      互斥性

      安全性

      死锁

      容错

基于数据库实现--悲观锁和乐观锁

      example:秒杀抢商品，使用悲观锁会增加where 库存>0,本次执行的会进行行锁，锁住本行数据，等他执行完后才会释放锁。而乐观锁则是select  for update,首先查询出版本号，然后update version=version+1 where version=#{version}

redis  实现分布式锁

单redis

    前提条件：只有一个redis服务，或者多台redis都实现了集群

方案1

setnx()
     setnx 的含义就是 SET if Not Exists，其主要有两个参数 setnx(key, value)。该方法是原子的，如果 key 不存在，则设置当前 key 成功，返回 1；如果当前 key 已经存在，则设置当前 key 失败，返回 0。
expire()
      expire 设置过期时间，要注意的是 setnx 命令不能设置 key 的超时时间，只能通过 expire() 来对 key 设置

缺点：当执行了第一步的时候，redis服务器gg的时候，就无法释放锁
 

方案2

SETNX()、GET()、GETSET()方法做分布式锁
这个方案的背景主要是在 setnx() 和 expire() 的方案上针对可能存在的死锁问题，做了一些优化。

getset()
这个命令主要有两个参数 getset(key，newValue)。该方法是原子的，对 key 设置 newValue 这个值，并且返回 key 原来的旧值。假设 key 原来是不存在的，那么多次执行这个命令，会出现下边的效果：

getset(key, “value1”) 返回 null 此时 key 的值会被设置为 value1
getset(key, “value2”) 返回 value1 此时 key 的值会被设置为 value2
依次类推！
使用步骤

setnx(lockkey, 当前时间+过期超时时间)，如果返回 1，则获取锁成功；如果返回 0 则没有获取到锁，转向 2。
get(lockkey) 获取值 oldExpireTime ，并将这个 value 值与当前的系统时间进行比较，如果小于当前系统时间，则认为这个锁已经超时，可以允许别的请求重新获取，转向 3。
计算 newExpireTime = 当前时间+过期超时时间，然后 getset(lockkey, newExpireTime) 会返回当前 lockkey 的值currentExpireTime。
判断 currentExpireTime 与 oldExpireTime 是否相等，如果相等，说明当前 getset 设置成功，获取到了锁。如果不相等，说明这个锁又被别的请求获取走了，那么当前请求可以直接返回失败，或者继续重试。
在获取到锁之后，当前线程可以开始自己的业务处理，当处理完毕后，比较自己的处理时间和对于锁设置的超时时间，如果小于锁设置的超时时间，则直接执行 delete 释放锁；如果大于锁设置的超时时间，则不需要再对锁进行处理。

 

方案3（推荐）：

   使用redisTemplate
      redisTemplate.opsForValue().set("myTest", "abc",Duration.ofSeconds(100));
      redisTemplate.opsForValue().set("myTest", "abc",100,TimeUtil.SECONDS);

   

 

多台redis和zk的后续补充