关于redis:分布式锁和Redis实现

很多老手将 分布式锁 和 分布式事务 混同，集体了解：锁 是用于解决多程序并发抢夺某一共享资源；事务 是用于保障一系列操作执行的一致性。我后面有几篇文章解说了分布式事务，对于2PC、TCC和异步确保计划的实现，这次打算把几种分布式锁的计划说一说。

1. 定义

在传统单体架构中，咱们最常见的锁是jdk的锁。因为线程是操作系统可能运行调度的最小单位，在java多线程开发时，就不免波及到不同线程竞争同一个过程下的资源。jdk库给咱们提供了synchronized、Lock和并发包java.util.concurrent.* 等。然而它们都对立的限度，竞争资源的线程，都是运行在同一个Jvm过程下，在分布式架构中，不同Jvm过程是无奈应用该锁的。

为了避免分布式系统中的多个过程之间互相烦扰，咱们须要一种分布式协调技术来对这些过程进行调度。而这个分布式协调技术的外围就是来实现这个分布式锁。

举个经典“超卖”的例子，某个电商我的项目中抢购100件库存的商品，抢购接口的逻辑可简略分为：1、查问库存是否大于零；2、当库存大于零时，购买商品。当只剩1件库存时，A用户和B用户都同时执行了第一步，查问库存都为1件，而后都执行购买操作。当他们购买实现，发现库存是 -1 件了。咱们能够在java代码中将“查问库存”和“减库存”的操作加锁，保障A用户和B用户的申请无奈并发执行。但万一咱们的接口服务是个集群服务，A用户和B用户的申请别离被负载平衡转发到不同的Jvm过程上，那还是解决不了问题。

2. 分布式锁比照

通过后面的例子能够晓得，协调解决分布式锁的资源，必定不能是Jvm过程级别的资源，而应该是某个能够共享的内部资源。

三种实现形式

常见分布式锁个别有三种实现形式：1. 数据库锁；2. 基于ZooKeeper的分布式锁；3. 基于Redis的分布式锁。

数据库锁：这种形式很容易被想到，把竞争的资源放到数据库中，利用数据库锁来实现资源竞争，能够参考之前的文章《数据库事务和锁》。例如：（1）乐观锁实现：查问库存商品的sql能够加上 “FOR UPDATE” 以实现排他锁，并且将“查问库存”和“减库存”打包成一个事务 COMMIT，在A用户查问和购买实现之前，B用户的申请都会被阻塞住。（2）乐观锁实现：在库存表中加上版本号字段来管制。或者更简略的实现是，当每次购买实现后发现库存小于零了，回滚事务即可。
zookeeper的分布式锁：实现分布式锁，ZooKeeper是业余的。它相似于一个文件系统，通过多零碎竞争文件系统上的文件资源，起到分布式锁的作用。具体的实现形式，请参考之前的文章《zookeeper的开发利用》。
redis的分布式锁：之前的文章讲过redis的开发利用和事务，始终没有讲过redis的分布式锁，这也是本文的核心内容。简略来说是通过setnx竞争键的值。

“数据库锁”是竞争表级资源或行级资源，“zookeeper锁”是竞争文件资源，“redis锁”是为了竞争键值资源。它们都是通过竞争程序外的共享资源，来实现分布式锁。

比照

不过在分布式锁的畛域，还是zookeeper更业余。redis实质上也是数据库，所有其它两种计划都是“兼职”实现分布式锁的，成果上没有zookeeper好。

性能耗费小：当真的呈现并发锁竞争时，数据库或redis的实现根本都是通过阻塞，或一直重试获取锁，有肯定的性能耗费。而zookeeper锁是通过注册监听器，当某个程序开释锁是，下一个程序监听到音讯再获取锁。
锁开释机制欠缺：如果是redis获取锁的那个客户端bug了或者挂了，那么只能期待超时工夫之后能力开释锁；而zk的话，因为创立的是长期znode，只有客户端挂了，znode就没了，此时就主动开释锁。
集群的强一致性：家喻户晓，zookeeper是典型实现了 CP 事务的案例，集群中永远由Leader节点来处理事务申请。而redis其实是实现 AP 事务的，如果master节点故障了，产生主从切换，此时就会有可能呈现锁失落的问题。

锁的必要条件

另外为了确保分布式锁可用，咱们至多要确保锁的实现同时满足以下几个条件：

互斥性。在任意时刻，只有一个客户端能持有锁。
不会产生死锁。即便有一个客户端在持有锁的期间解体而没有被动解锁，也能保障后续其余客户端能加锁。
解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端本人不能把他人加的锁给解了。

3. Redis实现分布式锁

3.1. 加锁

正确的加锁

public class RedisTool {

    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 申请标识
     * @param expireTime 超期工夫
     * @return 是否获取胜利
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;
    }
}

以看到，咱们加锁就一行代码：jedis.set(String key, String value, String nxxx, String expx, int time)，这个set()办法一共有五个形参：

key：咱们应用key来当锁，因为key是惟一的。
value：咱们传的是requestId，很多童鞋可能不明确，有key作为锁不就够了吗，为什么还要用到value？起因就是咱们在下面讲到可靠性时，分布式锁要满足第四个条件解铃还须系铃人，通过给value赋值为requestId，咱们就晓得这把锁是哪个申请加的了，在解锁的时候就能够有根据。requestId能够应用UUID.randomUUID().toString()办法生成。
Nxxx：这个参数咱们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，咱们进行set操作；若key曾经存在，则不做任何操作；
EXPX：这个参数咱们传的是PX，意思是咱们要给这个key加一个过期的设置，具体工夫由第五个参数决定。
time：与第四个参数相响应，代表key的过期工夫。

总的来说，执行下面的set()办法就只会导致两种后果：

以后没有锁（key不存在），那么就进行加锁操作，并对锁设置个有效期，同时value示意加锁的客户端。
已有锁存在，不做任何操作。

不举荐的加锁形式（不举荐！！！）

我看过很多博客中，都用上面的形式来加锁，即setnx和getset的配合，手动来保护键的过期工夫。

public static boolean wrongGetLock2(Jedis jedis, String lockKey, int expireTime) {

    long expires = System.currentTimeMillis() + expireTime;
    String expiresStr = String.valueOf(expires);

    // 如果以后锁不存在，返回加锁胜利
    if (jedis.setnx(lockKey, expiresStr) == 1) {
        return true;
    }

    // 如果锁存在，获取锁的过期工夫
    String currentValueStr = jedis.get(lockKey);
    if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
        // 锁已过期，获取上一个锁的过期工夫，并设置当初锁的过期工夫
        String oldValueStr = jedis.getSet(lockKey, expiresStr);
        if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
            // 思考多线程并发的状况，只有一个线程的设置值和以后值雷同，它才有权力加锁
            return true;
        }
    }
    // 其余状况，一律返回加锁失败
    return false;
}

外表上来看，这段代码也是实现分布式锁的，而且代码逻辑和下面的差不多，然而有上面几个问题：

因为是客户端本人生成过期工夫，所以须要强制要求分布式下每个客户端的工夫必须同步。
当锁过期的时候，如果多个客户端同时执行jedis.getSet()办法，那么尽管最终只有一个客户端能够加锁，然而这个客户端的锁的过期工夫可能被其余客户端笼罩。
锁不具备拥有者标识，即任何客户端都能够解锁。

网上的这类代码可能是基于晚期jedis的版本，过后有很大的局限性。Redis 2.6.12以上版本为set指令减少了可选参数，像后面说的jedis.set(String key, String value, String nxxx, String expx, int time)的api，能够把 SETNX 和 EXPIRE 打包在一起执行，并且把过期键的解锁交给redis服务器去治理。因而理论开发过程中，大家不要再用这种比拟原始的形式加锁了。

3.2. 解锁

正确的加锁

public class RedisTool {

    private static final Long RELEASE_SUCCESS = 1L;

    /**
     * 开释分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 申请标识
     * @return 是否开释胜利
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));

        if (RELEASE_SUCCESS.equals(result)) {
            return true;
        }
        return false;
    }
}

首先获取锁对应的value值，查看是否与requestId相等，如果相等则删除锁（解锁）。那么为什么要应用Lua语言来实现呢？因为要确保上述操作是原子性的。在之前《Redis的线程模型和事务》文章中，咱们通过事务的形式保障一系列操作指令的原子性，应用Lua脚本也同样能够实现相似的成果。

为什么要保障原子性呢？如果A申请在获取锁对应的value值验证requestId相等后，下达删除指令。然而因为网络等起因，删除的指令阻塞住了。而此时锁因为超时主动解锁了，并且B申请获取到了锁，从新加锁。这时候A申请到删除指令执行了，后果把B申请好不容易获取到的锁给删了。

3.3. lua

Redis命令的计算能力并不算很弱小，应用Lua语言则能够在很大水平上补救Redis的这个有余。在Redis中，执行Lua语言是原子性，也就是说Redis执行Lua的时候是不会被中断的，具备原子性，这个个性有助于Redis对并发数据一致性的反对。

Redis反对两种办法运行脚本，一种是间接输出一些Lua语言的程序代码，另一种是将Lua语言编写成文件。在理论利用中，一些简略的脚本能够采取第一种形式，对于有肯定逻辑的个别采纳第二种。而对于采纳简略脚本的，Redis反对缓存脚本，只是它会应用SHA-1算法对脚本进行签名，而后把SHA-1标识返回，只有通过这个标识运行就能够了。

redis中执行lua

这里就简略介绍，间接输出一些Lua语言的程序代码的形式，可在redis-cli中执行下列：

eval lua-script key-num [key1 key2 key3 ....] [value1 value2 value3 ....]

--示例1 
eval "return 'Hello World'" 0
--示例2
eval "redis.call('set',KEYS[1],ARGV[1])" 1 lua-key lua-value

eval 代表执行Lua语言的命令。
lua-script 代表Lua语言脚本。
key-num 示意参数中有多少个key，须要留神的是Redis中key是从1开始的，如果没有key的参数，那么写0。
[key1 key2 key3…] 是key作为参数传递给Lua语言，也能够不填，然而须要和key-num的个数对应起来。
[value1 value2 value3 …] 这些参数传递给Lua语言，他们是可填可不填的。

lua中调用redis

在Lua语言中采纳redis.call 执行操作：

redis.call(command,key[param1, param2…])

--示例1
eval "return redis.call('set','foo','bar')" 0
--示例2
eval "return redis.call('set',KEYS[1],'bar')" 1 foo

command 是命令，包含set、get、del等。
key 是被操作的键。
param1,param2… 代表给key的参数。

例如，实现一个getset的lua脚本
getset.lua

local key = KEYS[1]
local newValue = ARGV[1]
local oldValue = redis.call('get', key)
redis.call('set', key, newValue)
return oldValue

3.4. 局限性和改良

后面咱们说过，在Redis集群中，分布式锁的实现存在一些局限性，当主从替换时难以保障一致性。

景象

在redis sentinel集群中，咱们具备多台redis，他们之间有着主从的关系，例如一主二从。咱们的set命令对应的数据写到主库，而后同步到从库。当咱们申请一个锁的时候，对应就是一条命令 setnx mykey myvalue ，在redis sentinel集群中，这条命令先是落到了主库。假如这时主库down了，而这条数据还没来得及同步到从库，sentinel将从库中的一台选举为主库了。这时，咱们的新主库中并没有mykey这条数据，若此时另外一个client执行 setnx mykey hisvalue , 也会胜利，即也能失去锁。这就意味着，此时有两个client取得了锁。这不是咱们心愿看到的，尽管这个状况产生的记录很小，只会在主从failover的时候才会产生，大多数状况下、大多数零碎都能够容忍，但不是所有的零碎都能容忍这种瑕疵。

解决

为了解决故障转移状况下的缺点，Antirez 创造了 Redlock 算法。应用redlock算法，须要多个redis实例，加锁的时候，它会向多半节点发送 setex mykey myvalue 命令，只有过半节点胜利了，那么就算加锁胜利了。这和zookeeper的实现计划十分相似，zookeeper集群的leader播送命令时，要求其中必须有过半的follower向leader反馈ACK才失效。

在理论工作中应用的时候，咱们能够抉择已有的开源实现，python有redlock-py，java 中有 Redisson redlock。

redlock的确解决了下面所说的“不靠谱的状况”。然而，它解决问题的同时，也带来了代价。你须要多个redis实例，你须要引入新的库代码也得调整，性能上也会有损。所以，果然是不存在“完满的解决方案”，咱们更须要的是可能依据理论的状况和条件把问题解决了就好。

关于redis:分布式锁和Redis实现

1. 定义

2. 分布式锁比照

3. Redis实现分布式锁

3.1. 加锁

3.2. 解锁

3.3. lua

3.4. 局限性和改良

评论

发表回复取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

关于redis:分布式锁和Redis实现

1. 定义

2. 分布式锁比照

3. Redis实现分布式锁

3.1. 加锁

3.2. 解锁

3.3. lua

3.4. 局限性和改良

评论

发表回复 取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

发表回复取消回复