redisson 分布式锁（Redis分布式锁）

redisson 分布式锁（Redis分布式锁）以上例子中，线程自己的锁被其他线程删除，导致锁失效，所以在使用setNx获取锁的时候需要设置每个线程的唯一值 每个线程只能释放属于自己的锁，通过判断Value值是否一致来释放锁；线程A，通过setNx获得锁，但是业务逻辑耗时超过了锁设置的超时时间(假设30秒) 锁被自动释放，这个时候线程B获得锁，开始B的业务逻辑，这个时候线程A执行完成返回了，释放了B的锁，而线程B同样执行超时的同时，线程C获取到锁，然后线程B又释放了C的锁，问题恶行循环；这样就无法实现锁的互斥性，等于上锁无效；单点Redis获取分布式锁 在中小型的应用中，并发量不大，通过单点Redis获取分布式锁是可以满足要求，但是在高并发场景下是无法满足的，让我们看看这些例子，再作进一步优化；例子一

一、分布式锁应用场景

在我们的软件开发中，在高并发的场景下，经常需要遇到多个线程同时操作同一块资源的问题，例如商品库存扣减；为了保证资源的一致性，多个线程需要通过利用锁来进行排队操作;

分布式锁具有互斥性，在任意时刻只有一个客户端获得锁；

二、redis单点分布式锁实现

客户端向Redis服务器发送Set命令 返回TRUE则获取锁成功，接下来的逻辑跑完，然后执行delete操作，释放锁；否则获取锁失败；

$this->redisService ->set(key random_value [‘nx’ ’ex’=>expire]);

单点Redis获取分布式锁

在中小型的应用中，并发量不大，通过单点Redis获取分布式锁是可以满足要求，但是在高并发场景下是无法满足的，让我们看看这些例子，再作进一步优化；

例子一

线程A，通过setNx获得锁，但是业务逻辑耗时超过了锁设置的超时时间(假设30秒) 锁被自动释放，这个时候线程B获得锁，开始B的业务逻辑，这个时候线程A执行完成返回了，释放了B的锁，而线程B同样执行超时的同时，线程C获取到锁，然后线程B又释放了C的锁，问题恶行循环；这样就无法实现锁的互斥性，等于上锁无效；

以上例子中，线程自己的锁被其他线程删除，导致锁失效，所以在使用setNx获取锁的时候需要设置每个线程的唯一值 每个线程只能释放属于自己的锁，通过判断Value值是否一致来释放锁；

IF($clientId=-$this->redisService->get($key)){

$this->redisService->del($key)

}

例子二

线程A在执行完业务逻辑，通过get指令获取到key的值，进入IF判断value的时候，同时线程A的锁超时了，锁被自动删除，同时线程B正在这个时候进入获取锁成功，还没来得及执行业务代码，线程A就执行del(key) 也就是把线程B的锁删除了，导致锁失效；

上述例子场景中，导致锁失效的原因在于redis在执行get、del指令时无法满足原子性；redis中内置了LUA运行时，在执行LUA脚本的时候是一次性载入执行，能在每一次的请求中保证多个指令执行成功；

local clientId=ARGV[1]

Local lockKey= KEYS[1]

Local lockValue=redis.call(‘get’ lockKey)

If localValue == clientId then

Return redis.call(‘del’ lockKey)

Else

Return 0

End

$this->redisService->eval($luaFileContent $arg $keyCount);

单点Redis部署可靠性比较低，在需要保证系统高可用的情况下，构建Redis集群进行生产部署是必须的，在集群模式下，简单地使用SetNx获取分布式锁是不适合的；

Redis在主从群集模式下，主从节点之间的数据数据同步是通过异步实现的，如果Master节点出现异常，群集会主从切换；在这种情况下会有可能出现数据丢失；让我们看看一下例子：

1、线程A在master节点获取到锁

2、数据从Master同步到slave节点

3、数据还没有来得及同步完成，这个时候Master出现故障，系统自动主从切换，slave变成Master；线程A锁丢失；

4、线程B进入新Master获取锁，这个锁有可能和线程A的锁一样，这样就出现同一把锁被使用多次；

三、Redis集群分布式锁- RedLock

为了解决集群环境下分布式锁的问题，官方提供了RedLock算法；根据官方文档我们可以清楚知道RedLock的算法大概分5个步骤；

假设我们通过redis-cluster构建3 3主从集群；

Reids-Cluster集群

1、获取当前时间

2、客户端使用相同的key和Value 尝试一次向3个主节点获取锁；在这个步骤中，应该考虑客户端获取锁的时间应该远远小于锁的超时时间（获取锁的时间主要包括网络连接和响应超时时间），这个是为了避免长时间等待无法提供服务的Redis节点，从而快速转向下一个服务节点获取锁；

例如：客户端设置key的超时时间（TTL）是10S，则设置锁的超时时间应该在5~50ms之间；

3、客户端使用当前时间减去开始时间（步骤1的时间）就可以获得客户端获取锁需要的时间；这个获取锁的时间要小于锁的超时时间，且至少大部分主节点（这里是2个redis主节点）都获取锁成功，客户端才算成功获取到锁；

4、如果获取锁成功，那么锁的真正超时时间是key设置的TTL 减去 客户端获取锁需要的时间，才算是分布式锁真正的超时时间（严格来说还需要减去时钟漂移）；

5、如果获取锁失败（原因可能是没有成功在大部分主节点（ N/2 1 ）中获取到锁又或者真正超时时间小于0），客户端都应该释放所有redis主节点的锁（解锁），哪怕某些节点没有加锁成功；

所以根据以上算法，我们就可以解决在主从集群情况下，由于异步通信，数据不一致导致锁无效的问题；

但是RedLock在某些场景下也出现问题：

1、Redis服务没有设置数据持久化，服务器断电重启后，数据丢失，之前添加的锁无效；

2、Redis 开启AOF 进行数据持久化，由于AOF的设置最少单位是秒，仍然无法保证锁不会因为服务重启恢复后丢失；

3、把AOF设置成同步磁盘的方式（设置成每一个修改操作都同步到磁盘（fsync=always）），这样Redis的性能会大幅度下降，性能和锁有效性两者不可兼得，需要做出平衡选择；

4、解决办法延时重启：开启Redis服务的AOF，数据同步到磁盘方式设置成默认的每秒，服务器无论什么原因宕机都需要等待TTL的时间后才进行重启；这样缺点也明显，就是在TTL时间内无法提供服务了，如果大部分节点都出现宕机，服务就缺乏可用性。

四、总结：

1、单点Redis分布式锁需要使用LUA保证指令的原子性操作

2、集群情况下使用RedLock解决异步通讯造成的锁丢失问题；

3、使用RedLock算法要注意Key的真实超时时间=TTL-获取锁时间-时钟漂移；

4、由于RedLock算法严重依赖系统时钟，服务器的时间要注意系统时钟发生跳跃问题；

5、使用RedLock获取分布式锁失败后，必须要释放集群中所有节点中的锁（其中某些服务节点由于网路原因客户端无法收到锁设置成功的返回，导致该锁一直存在于某些服务节点中）