您的位置：首页行业资讯文章干货

Redis分布式锁实施方案

发布日期：2019-10-22 16:01:07 来源：汇智动力

分布式锁是为了解决在分布式环境里，当多个节点同时竞争访问同一个资源带来数据不一致的问题，分布式锁除了要满足互斥、无死锁、可重入等特性外，还需要考虑高可用、高性能等问题。分布式锁比较流行的实现方式有三种：

数据库
Redis
Zookeeper

本文主要介绍使用Redis时如何实现分布式锁，使用Redis实现分布式锁的最低要求需要满足以下三点：

互斥，在任何给定时刻，只有一个客户端可以持有锁。
无死锁，即使锁定资源的客户端崩溃或分区，也始终可以获取锁定。
容错能力，只要大多数Redis节点都处于运行状态，客户端就可以获取和释放锁。

互斥和无死锁可以可以使用Redis的setnx指令保证只能有一个节点设置锁，同时设置一个超时时间保证在极端情况下能自动释放锁，容错能力可部署Redis集群。

基于故障转移Redis分布式锁的实施

使用Redis实施分布式锁最简单的方法是在实例在创建一个key，使用Redis的超时功能，在有限的时间内保持key的可用性，以便最终将其释放。最后当客户端处理完成后删除key。

一看使用Redis实施分布式锁还蛮容易，不需要过多的步骤，但是在单实例里面如果实例发生宕机或网络不可用时会发怎么办呢？这个也蛮好解决我们可以加个奴隶使用一主一从，如果主服务器不可用还可以使用它。这样会带来另外一个问题，你们发现这样实施后锁没法保证互斥性了，比如发生以下的情况：

客户端A获取Master节点中的锁
Slave节点同步key之前，Master宕机
Slave节点升级为Master节点
客户端再次去获取同样的锁，获取锁成功。安全违规！

画个图比较清楚一点：

单个实例实施分布式锁

在解决单实例Redis分布式锁的限制之前，先看一下如果正确的使用Redis在单实例中实施分布式锁，要获取分布式锁，必遵循循以下方法：

SET resource_name my_random_value NX PX 30000

该命令只有在key不存在时才设置key（NX选项），并且会设置到期时间为30000ms（PX选项），key的值为一个随机值，唯一的限制是必需保持该值在所有的锁定请求中必需唯一。

使用随机值是为了更安全的释放锁，只有只有key中存放的值是期望的值时才释放锁了，为了保证判断值是否一致与删除key的原子性，使用Lua脚本来完成：

if redis.call("get",KEYS[1]) == ARGV[1] then
 return redis.call("del",KEYS[1])
else
 return 0
end

ReidsLock算法

在分布式环境中，如何保证Redis锁的高可用呢？假设有N个Master节点，所有节点相互独立，不采用任务复制或其他协调系统。比如我们有5个Redis主服务器，为了获取锁客户端相当做如下操作：

可以以毫秒为单位获取当前时间
生成key和随机值和超时时间
发送Redis命令的超时时间尽可能的小，这样当节点故障时能快速的访问下一个节点
顺序发送获取锁命令
客户使用当前时间减去第一步中获取的时间得到锁的有效时间，当有至少3个节点获取锁功能，并且锁的有效时间小于锁的超时时间才认为成功获取到锁
如果客户端由于某种原因（无法锁定N / 2 + 1个实例或有效时间为负），则认为获取锁失败，它将尝试解锁所有实例。

上图简单画出5台Redis获取锁的过程，客户端A成功在Redis 1、Redis 2、Redis 4中获取到锁。伪代码大概是这样子：

long timestamp = System.currentTimeMillis();
String lockKey = xxx
String value = xxx
long timeout = 5000
int n = 5
int successCount = 0;
for (i = 0; i < n; i++){
 if(
 redis[i].setnx(lockKey, value, timeout) 
 ){
 //设置成功
 successCount++;
 }
 
 if(successCount == (N / 2 + 1) ) 
 break;
}
//获取锁总花费时间
long spent = System.currentTimeMillis() - timestamp 
//获取成功的数量等于 (N / 2 + 1)并且，有交时间小时超时时间
if(successCount == (N / 2 + 1) && 
 (timeout - spent) > 0
){
 //成功获取到锁
}else{
 //获取锁失败，需要释放锁
}