NoSql之Redis系列四: Redis实现分布式锁

[OTC](NoSql之Redis系列四: Redis实现分布式锁)

前言

分布式锁的实现方式很多, 可以使用 数据库乐观锁, 可以适用 Zookeeper, 可以使用Redis, 本文总结一下Redis的分布式锁的常用方式.

Redis分布式锁的特点

• 安全: 在任一时刻, 只有一个客户端持有锁, 同一把锁相互排斥.
• 保活1: 无死锁, 持有锁的客户端崩溃或者网络断开, 也可以获取新锁
• 保活2: 容错性, 只要大部分Redis节点活着, 客户端就可以正常获取和释放锁

单个Redis实例实现锁

单实例下, 假如Redis 服务端稳定运行, 那么下面最简单的实现方式就是: 在Redis中创建Key, 然后这个Key有失效时间, 当客户端在失效时间前释放, 则由客务端发起命令删除Key, 否则等待服务端自动删除Key.
该基础算法的命令实现就是

set lock_key lock_value NX PX timeout
// NX 命令只有不存在 lock_key的时候才会被执行
// PX 命令是设置timeout的自动失效时间
// 示例: set userId 9527 NX PX 20000  含义就是: 设置一个名称为userId 的key, 它的值是 9527, 超时时间是 20秒.

使用Jedis模拟上面执行就是下面的代码

public static void main(String[] args) throws InterruptedException {
    Jedis jedis = new Jedis("127.0.0.1", 6379);
    if (lock(jedis, "userId_1", 1000)) {
        System.out.println("lock first level success");     // output 
        if (lock(jedis, "userId_1", 1000)) {
            System.out.println("lock second level success");
            if (releaseLock(jedis, "userId_1")) {
                System.out.println("releaseLock second level success");
            } else {
                System.out.println("releaseLock second level fail"); 
            }
        } else {
            System.out.println("lock second level fail");   // output 
        }
        Thread.sleep(3000);
        if (releaseLock(jedis, "userId_1")) {
            System.out.println("releaseLock one level success");   // output 
        } else {
            System.out.println("releaseLock one level fail");
        }
    }
}
public static boolean lock(Jedis jedis, String name, long timeout) {
    String result = jedis.set(name, "1", "NX", "PX", timeout);
    if (result != null && result.equals("OK")) {
        return true;
    }
    return false;
}
public static boolean releaseLock(Jedis jedis, String name) {
    String result = jedis.get(name);
    if (result == null) {
        return true;
    }
    if (result.equals("1")) {
        jedis.del(name);
        return true;
    }
    return false;
}

但是上面的代码有一个问题, 假如客户端A获取了资源锁, 客户端A操作完毕时去释放锁, 但是锁已经因为超时被Redis自动释放掉了, 并且客户端B 又使用相同的KeyValue加锁, 这个时候客户端A 调用Del命令就删除掉了客户端B的锁, 为了避免这方情况的发生, 就要尽量避免多次加锁时, 使用相同的Key. 这里有两种通用的方式1: 使用 真正业务资源key+ Random 随机生成一个串; 2: 使用 真正业务资源key+毫秒时间戳+客户端编号. 虽然不能保证绝对安全, 但是大部分情况已经足够.

分布式环境Redis示例实现锁

假设我们有5个Redis Master节点, 他们完全相互独立, 不存在主从复制和其他集群协调机制, 我们为了取得锁, 可以使用下面的操作

1. 获取当前毫秒时间戳
2. 遍历5个客户端, 使用相同的Key,Value获取锁. 设置锁时, 客户端设置一个网络连接和响应超时时间, 该时间小于锁超时时间. 假设 锁自动超时时间是10秒, 则网络超时时间是5-50ms. 这样避免单个服务端挂掉, 影响其他服务端的尝试.
3. 客户端用当前时间减去1的时间戳就得到锁时间的时间, 当大于3个节点(大多数节点)同时获取锁的时候才算真正的获取锁成功.
4. 得到了锁之后, key的真实有效时间是锁超时时间减去3中获取锁的时间.
5. 如果获取锁失败(没有达到3个节点加锁成功或者获取锁的时间已经超过了锁的超时时间), 客户端需要在所有的Redis 示例上解锁.

释放锁比较简单, 直接删除key就好, 不用关系是否获取成功.

推荐使用 Redisson 库来直接实现该功能, 具体实现可以参照 Redisson 库.

总结

本文介绍了Redis分布式锁官方的推荐做法, 单机和多机部署都有适用. 真正实践还需要更深入的研究.

引用文献

官方文档 https://redis.io