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

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

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

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

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

通过后面的例子能够晓得，协调解决分布式锁的资源，必定不能是 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 节点故障了，产生主从切换，此时就会有可能呈现锁失落的问题。

锁的必要条件

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

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

正确的加锁

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 服务器去治理。因而理论开发过程中，大家不要再用这种比拟原始的形式加锁了。

正确的加锁

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 申请好不容易获取到的锁给删了。

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

后面咱们说过，在 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. 局限性和改良

Just My Socks（注册教程内含优惠码）

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

1. 定义

2. 分布式锁比照

3. Redis 实现分布式锁

3.1. 加锁

3.2. 解锁

3.3. lua

3.4. 局限性和改良

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）