Redis 分布式锁

概念

在⼀个分布式的系统中，也会涉及到多个节点访问同⼀个公共资源的情况，此时就需要通过锁来做互斥控制，避免出现类似于 "线程安全" 的问题。但 C++ 的 std::mutex 只能在当前进程中⽣效, 在分布式的这种多个进程多个主机的场景下就⽆能为力了，此时就需要使⽤到分布式锁。
分布式锁本质上就是使⽤⼀个公共的服务器, 来记录加锁状态。这个公共的服务器可以是 Redis, 也可以是其他组件(⽐如 MySQL 或者 ZooKeeper 等), 还可以是我们⾃⼰写的⼀个服务。

Redis 分布式锁的基础实现

例如，在一个买票系统中，我们引⼊⼀个 Redis , 作为分布式锁的管理器。此时, 如果买票服务器1 尝试买票, 就需要先访问 Redis, 在 Redis 上设置⼀个键值对. ⽐如 key 就是⻋次, value 随便设置个值 (⽐如 1)。如果这个操作设置成功, 就视为当前没有节点对该⻋次加锁, 就可以进⾏数据库的读写操作. 操作完成之后, 再把 Redis 上刚才的这个键值对给删除掉。
如果在买票服务器1 操作数据库的过程中, 买票服务器2 也想买票, 也会尝试给 Redis 上写⼀个键值对, key 同样是⻋次. 但是此时设置的时候发现该⻋次的 key 已经存在了, 则认为已经有其他服务器正在持有锁, 此时服务器2 就需要等待或者暂时放弃。
Redis 中提供了 setnx 操作, 正好适合这个场景. 即: key 不存在就设置, 存在则直接失败。但这样的方案仍存在缺陷。

引入过期时间

当服务器1 加锁之后, 开始处理买票的过程中, 如果服务器1 意外宕机了, 就会导致解锁操作 (删除该 key) 不能执⾏. 就可能引起其他服务器始终⽆法获取到锁的情况.
为了解决这个问题, 可以在设置 key 的同时引⼊过期时间. 即这个锁最多持有多久, 就应该被释放。即可以使⽤ set ex nx 的⽅式, 在设置锁的同时把过期时间设置进去.
注意! 此处的过期时间只能使⽤⼀个命令的⽅式设置. 如果分开多个操作, ⽐如 setnx 之后, 再来⼀个单独的 expire, 由于 Redis 的多个指令之间不存在关联, 并且即使使⽤了事务也不能保证这两个操作都⼀定成功, 因此就可能出现 setnx 成功, 但是expire 失败的情况. 此时仍然会出现⽆法正确释放锁的问题.

引入校验 id

对于 Redis 中写⼊的加锁键值对, 其他的节点也是可以删除的. ⽐如服务器1 写⼊⼀个 "001": 1 这样的键值对, 服务器2 是完全可以把 "001" 给删除掉的.
为了解决上述问题, 我们可以引⼊⼀个校验 id. ⽐如可以把设置的键值对的值, 不再是简单的设为⼀个 1, ⽽是设成服务器的编号. 形如 "001": "服务器 1". 这样就可以在删除 key (解锁)的时候, 先校验当前删除 key 的服务器是否是当初加锁的服务器, 如果是, 才能真正删除; 不是, 则不能删除.逻辑⽤伪代码描述如下:

cpp 复制代码

String key = [要加锁的资源 id];
String serverId = [服务器的编号];
// 加锁, 设置过期时间为 10s
redis.set(key, serverId, "NX", "EX", "10s");
// 执⾏各种业务逻辑, ⽐如修改数据库数据. 
doSomeThing();
// 解锁, 删除 key. 但是删除前要检验下 serverId 是否匹配. 
if (redis.get(key) == serverId) {
 redis.del(key);
}

但是很明显, 解锁逻辑是两步操作 "get" 和 "del", 这样做并⾮是原⼦的，这样仍然存在问题

引入 lua

为了使解锁操作原⼦, 可以使⽤ Redis 的 Lua 脚本功能。
Lua 的语法类似于 JS, 是⼀个动态弱类型的语⾔. Lua 的解释器⼀般使⽤ C 语⾔实现. Lua 语法简单精炼, 执⾏速度快, 解释器也⽐较轻量(Lua 解释器的可执⾏程序体积只有 200KB 左右). 因此 Lua 经常作为其他程序内部嵌⼊的脚本语⾔. Redis 就⽀持 Lua 作为内嵌脚本.
使⽤ Lua 脚本完成上述解锁功能

Lua 复制代码

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

通过 eval 命令执行 Lua 脚本：

bash 复制代码

redis-cli eval 
"if redis.call('get',KEYS[1]) == ARGV[1] then
    return redis.call('del',KEYS[1])
else return 0
end;" 
1 lock_key client_id
#脚本中键的数量 脚本中要解锁的键key 与key对应的value，检验id

在 C++ 中使用 redis-plus-plus 调用 eval：

cpp 复制代码

#include <iostream>
#include <sw/redis++/redis++.h>
#include <string>

using namespace sw::redis;

bool unlock(Redis& redis, const std::string& lock_key, const std::string& client_id) {
    // Lua 脚本
    std::string lua_script = R"(
if redis.call('get',KEYS[1]) == ARGV[1] then
    return redis.call('del',KEYS[1])
else return 0
end;
)";

    // 调用 EVAL 命令
    int result = redis.eval(lua_script, {lock_key}, {client_id});
    return result == 1;
}

int main() {
    // 创建 Redis 客户端连接
    Redis redis("tcp://127.0.0.1:6379");

    // 锁的键名和客户端唯一标识
    std::string lock_key = "my_lock";
    std::string client_id = "unique_client_id";

    // 尝试解锁
    if (unlock(redis, lock_key, client_id)) {
        std::cout << "解锁成功" << std::endl;
    } else {
        std::cout << "解锁失败" << std::endl;
    }

    return 0;
}

引入 watch dog (看门狗)

上述⽅案仍然存在⼀个重要问题. 当我们设置了 key 过期时间之后 (⽐如 10s), 仍然存在⼀定的可能性, 当任务还没执⾏完, key 就先过期了. 这就导致锁提前失效.
把这个过期时间设置的⾜够⻓, ⽐如 30s, 是否能解决这个问题呢? 很明显, 设置多⻓时间合适, 是⽆⽌境的. 即使设置再⻓, 也不能完全保证就没有提前失效的情况. ⽽且如果设置的太⻓了, 万⼀对应的服务器挂了, 此时其他服务器也不能及时的获取到锁. 因此相⽐于设置⼀个固定的⻓时间, 不如动态的调整时间更合适.
所谓 watch dog, 本质上是加锁的服务器上的⼀个单独的线程, 通过这个线程来对锁过期时间进⾏ "续约".初始情况下设置过期时间为 10s. 同时设定看⻔狗线程每隔 3s 检测⼀次.
那么当 3s 时间到的时候, 看⻔狗就会判定当前任务是否完成.

如果任务已经完成, 则直接通过 lua 脚本的⽅式, 释放锁(删除 key).
如果任务未完成, 则把过期时间重写设置为 10s. (即 "续约")

这样就不担⼼锁提前失效的问题了. ⽽且另⼀⽅⾯, 如果该服务器挂了, 看⻔狗线程也就随之挂了,此时⽆⼈续约, 这个 key ⾃然就可以迅速过期, 让其他服务器能够获取到锁了.
以下为 cpp 定义的看门狗的类：

cpp 复制代码

#include <sw/redis++/redis++.h>
#include <thread>
#include <chrono>
#include <atomic>
#include <iostream>
#include <string>

using namespace sw::redis;

class RedisLockWatchdog {
public:
    RedisLockWatchdog(Redis& redis, const std::string& lock_key, int expire_time)
        : redis(redis), lock_key(lock_key), expire_time(expire_time), running(false) {}

    ~RedisLockWatchdog() {
        stop();
    }

    void start() {
        if (!running) {
            running = true;
            watchdog_thread = std::thread(&RedisLockWatchdog::run, this);
        }
    }

    void stop() {
        if (running) {
            running = false;
            if (watchdog_thread.joinable()) {
                watchdog_thread.join();
            }
        }
    }

private:
    Redis& redis;
    std::string lock_key;
    int expire_time;  // 锁的续期时间（秒）
    std::atomic<bool> running;
    std::thread watchdog_thread;

    void run() {
        while (running) {
            try {
                // 续期锁
                redis.expire(lock_key, expire_time);
                std::this_thread::sleep_for(std::chrono::seconds(expire_time / 2));
            } catch (const std::exception& e) {
                std::cerr << "Watchdog error: " << e.what() << std::endl;
                break;
            }
        }
    }
};

使用如下：

cpp 复制代码

int main() {
    // 创建 Redis 客户端
    Redis redis("tcp://127.0.0.1:6379");

    // 锁的键名和续期时间
    std::string lock_key = "my_lock";
    int expire_time = 10;  // 锁的过期时间为 10 秒

    // 启动看门狗
    RedisLockWatchdog watchdog(redis, lock_key, expire_time);
    watchdog.start();

    // 模拟任务执行
    std::cout << "Lock acquired, performing task..." << std::endl;
    std::this_thread::sleep_for(std::chrono::seconds(30));  // 模拟任务耗时 30 秒

    // 停止看门狗并释放锁
    watchdog.stop();
    return 0;
}

引入 Redlock 算法

实践中的 Redis ⼀般是以集群的⽅式部署的 (⾄少是主从的形式, ⽽不是单机). 那么就可能出现以下⽐较极端的⼤冤种情况:
服务器1 向 master 节点进⾏加锁操作. 这个写⼊ key 的过程刚刚完成, master 挂了; slave 节点升级成了新的 master 节点. 但是由于刚才写⼊的这个 key 尚未来得及同步给 slave 呢, 此时就相当于服务器1 的加锁操作形同虚设了, 服务器2 仍然可以进⾏加锁 (即给新的 master 写⼊ key. 因为新的 master 不包含刚才的 key).
为了解决这个问题, Redis 的作者提出了 Redlock 算法.
我们引⼊⼀组 Redis 节点. 其中每⼀组 Redis 节点都包含⼀个主节点和若⼲从节点. 并且组和组之间存储的数据都是⼀致的, 相互之间是 "备份" 关系. 加锁的时候, 按照⼀定的顺序, 写多个 master 节点. 在写锁的时候需要设定操作的 "超时时间". ⽐如 50ms. 即如果 setnx 操作超过了 50ms 还没有成功, 就视为加锁失败.

如果给某个节点加锁失败, 就⽴即再尝试下⼀个节点。当加锁成功的节点数超过总节点数的⼀半, 才视为加锁成功. 这样的话, 即使有某些节点挂了, 也不影响锁的正确性. 同理, 释放锁的时候, 也需要把所有节点都进⾏解锁操作. (即使是之前超时的节点, 也要尝试解锁, 尽量保证逻辑严密).
简⽽⾔之, Redlock 算法的核⼼就是, 加锁操作不能只写给⼀个 Redis 节点, ⽽要写个多个!! 分布式系统中任何⼀个节点都是不可靠的. 最终的加锁成功结论是 "少数服从多数的".