Redis分布式锁升级：RedLock+SpringBoot

分布式锁概览

在多线程的环境下，为了保证一个代码块在同一时间只能由一个线程访问，Java中我们一般可以使用synchronized语法和ReetrantLock去保证，这实际上是本地锁的方式。但是现在公司都是流行分布式架构，在分布式环境下，如何保证不同节点的线程同步执行呢？因此就引出了分布式锁，它是控制分布式系统之间 互斥访问共享资源 的一种方式。

在一个分布式系统中，多台机器上部署了多个服务，当客户端一个用户发起一个数据插入请求时，如果没有分布式锁机制保证，那么那多台机器上的多个服务可能进行并发插入操作，导致数据重复插入，对于某些不允许有多余数据的业务来说，这就会造成问题。而分布式锁机制就是为了解决类似这类问题，保证多个服务之间互斥的访问共享资源，如果一个服务抢占了分布式锁，其他服务没获取到锁，就不进行后续操作。大致意思如下图所示：

分布式锁的特点

分布式锁一般有如下的特点：

• 互斥性： 同一时刻只能有一个线程持有锁
• 可重入性： 同一节点上的同一个线程如果获取了锁之后能够再次获取锁
• 锁超时：和J.U.C中的锁一样支持锁超时，防止死锁
• 高性能和高可用： 加锁和解锁需要高效，同时也需要保证高可用，防止分布式锁失效
• 具备阻塞和非阻塞性：能够及时从阻塞状态中被唤醒

分布式锁的实现方式

我们一般实现分布式锁有以下几种方式：

• 基于数据库
• 基于Redis
• 基于zookeeper

Redis普通分布式锁存在的问题

说到Redis分布式锁,大部分人都会想到： setnx+lua （redis保证执行lua脚本时不执行其他操作，保证操作的原子性），或者知道 set key value px milliseconds nx 。后一种方式的核心实现命令如下：

- 获取锁（unique_value可以是UUID等）
SET resource_name unique_value NX PX 30000

- 释放锁（lua脚本中，一定要比较value，防止误解锁）
if redis.call("get",KEYS[1]) == ARGV[1] then 
    return redis.call("del",KEYS[1])
else   
    return 0
end

这种实现方式有3大要点（也是面试概率非常高的地方）：

set key value px milliseconds nx

事实上这类锁最大的缺点就是它加锁时只作用在一个Redis节点上，即使Redis通过sentinel保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况：

1. 在Redis的master节点上拿到了锁；
2. 但是这个加锁的key还没有同步到slave节点；
3. master故障，发生故障转移，slave节点升级为master节点；
4. 导致锁丢失。

为了避免单点故障问题，Redis作者antirez基于分布式环境下提出了一种更高级的分布式锁的实现方式： Redlock 。Redlock也是Redis所有分布式锁实现方式中唯一能让面试官高潮的方式。

Redis高级分布式锁:Redlock

antirez提出的redlock算法大概是这样的：

在Redis的分布式环境中，我们假设有N个Redis master。这些节点 完全互相独立，不存在主从复制或者其他集群协调机制 。我们确保将在N个实例上使用与在Redis单实例下相同方法获取和释放锁。现在我们假设有5个Redis master节点，同时我们需要在5台服务器上面运行这些Redis实例，这样保证他们不会同时都宕掉。

为了取到锁，客户端应该执行以下操作:

• 获取当前Unix时间，以毫秒为单位。
• 依次尝试从5个实例，使用相同的key和 具有唯一性的value （例如UUID）获取锁。当向Redis请求获取锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间 TTL 为10秒，则超时时间应该在5-50毫秒之间。这样可以避免服务器端Redis已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试去另外一个Redis实例请求获取锁。
• 客户端使用当前时间减去开始获取锁时间（步骤1记录的时间）就得到获取锁使用的时间。 当且仅当从大多数 （N/2+1，这里是3个节点） 的Redis节点都取到锁，并且使用的时间小于锁失效时间时，锁才算获取成功 。
• 如果取到了锁，key的真正有效时