关于Redis分布式锁

最新推荐文章于 2024-04-08 09:46:04 发布

原创最新推荐文章于 2024-04-08 09:46:04 发布 · 150 阅读

1 ·

CC 4.0 BY-SA版权

cache 专栏收录该内容

3 篇文章

订阅专栏

关于Redis分布式锁

参考：https://redis.io/topics/distlock

关于分布式锁的一些设计要点：

安全性保证：互斥，在任何一个时刻，只有一个客户端能获取锁。
可靠性A：不会发生死锁，最终会获取到锁，即使持有锁的客户端宕机。
可靠性B：容错，只要集群中的大多数redis节点正常，客户端应该都可以获取和释放锁。

基于master-slave架构实现的分布式锁与存在的问题

使用如下命令获取锁，resource_name不存在的时候，设置key为resource_name，过期时间为30s

SET resource_name value NX PX 30000

使用del resource_name释放锁

del resource_name

这种实现方式会存在一个问题，问题是由于redis复制是异步复制的

Client A在master上获取到锁
master在将这个key复制到slave前宕机了
slave升级为master，slave这台机器上没有key为resource_name的数据
Client B在新的master获取key为resource_name的锁，违反了安全性的保证

使用单节点正确获取分布式锁的实现

获取锁命令：

SET resource_name my_random_value NX PX 30000

释放锁命令：

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

这个key的值设为“my_random_value”。这个值必须在所有获取锁请求的客户端里保持唯一。基本上这个随机值就是用来保证能安全地释放锁，我们可以用下面这个Lua脚本来告诉Redis：删除这个key当且仅当这个key存在而且值是我期望的那个值。

这个很重要，因为这可以避免误删其他客户端得到的锁，举个例子，一个客户端拿到了锁，被某个操作阻塞了很长时间，过了超时时间后自动释放了这个锁，然后这个客户端之后又尝试删除这个其实已经被其他客户端拿到的锁。所以单纯的用DEL指令有可能造成一个客户端删除了其他客户端的锁，用上面这个脚本可以保证每个客户单都用一个随机字符串’签名’了，这样每个锁就只能被获得锁的客户端删除了。

key值的超时时间，也叫做”锁有效时间”。这个是锁的自动释放时间，也是一个客户端在其他客户端能抢占锁之前可以执行任务的时间，这个时间从获取锁的时间点开始计算。所以现在我们有很好的获取和释放锁的方式，在一个非分布式的、单点的、保证永不宕机的环境下这个方式没有任何问题。接下来我们看看无法保证这些条件的分布式环境下我们该怎么做。

redis官网提供了Redlock算法的解决方案

在分布式版本的算法里我们假设我们有N个Redis master节点，这些节点都是完全独立的，我们不用任何复制或者其他隐含的分布式协调算法。我们已经描述了如何在单节点环境下安全地获取和释放锁。因此我们理所当然地应当用这个方法在每个单节点里来获取和释放锁。在我们的例子里面我们把N设成5，这个数字是一个相对比较合理的数值，因此我们需要在不同的计算机或者虚拟机上运行5个master节点来保证他们大多数情况下都不会同时宕机。一个客户端需要做如下操作来获取锁：

1.获取当前时间（单位是毫秒）。

2.轮流用相同的key和随机值在N个节点上请求锁，在这一步里，客户端在每个master上请求锁时，会有一个和总的锁释放时间相比小的多的超时时间。比如如果锁自动释放时间是10秒钟，那每个节点锁请求的超时时间可能是5-50毫秒的范围，这个可以防止一个客户端在某个宕掉的master节点上阻塞过长时间，如果一个master节点不可用了，我们应该尽快尝试下一个master节点。

3.客户端计算第二步中获取锁所花的时间，只有当客户端在大多数master节点上成功获取了锁（在这里是3个），而且总共消耗的时间不超过锁释放时间，这个锁就认为是获取成功了。

4.如果锁获取成功了，那现在锁自动释放时间就是最初的锁释放时间减去之前获取锁所消耗的时间。

5.如果锁获取失败了，不管是因为获取成功的锁不超过一半（N/2+1)还是因为总消耗时间超过了锁释放时间，客户端都会到每个master节点上释放锁，即便是那些他认为没有获取成功的锁。