Redis 分布式锁

最新推荐文章于 2025-11-11 05:00:00 发布

原创最新推荐文章于 2025-11-11 05:00:00 发布 · 484 阅读

0 ·

CC 4.0 BY-SA版权

redis 专栏收录该内容

18 篇文章

订阅专栏

参考：

Redis单节点实现

当resource_name不能存在时才能获取到锁，同时设置超时时间防止出现死锁。这时my_random_value是为了再删除时当前客户端的锁不会被其他客户端删除。
获取锁：

  SET resource_name my_random_value NX PX 30000

删除Lua脚本：

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

注意事项
如果客户端A获取到锁，但是执行时间超过了过期时间，那么key会被自动释放，此时其他客户端也可以获取到锁。
所以不要在获取锁后执行复杂耗时的操作。

集群环境下

上面的实现在集群环境下的问题：
在Redis主从结构的情况下，如果客户端A从master获取到锁，但是master还没有来得及同步给slave时crash掉了，那么slave会提升为主节点此时客户端B依然可以从新的master中获取到锁。

Redlock 算法

为了使用 Redlock，需要提供多个 Redis 实例，这些实例之前相互独立没有主从关系。同很多分布式算法一样，redlock 也使用「大多数机制」。

加锁时，它会向过半节点发送 set(key, value, nx=True, ex=xxx) 指令，只要过半节点 set 成功，那就认为加锁成功。释放锁时，需要向所有节点发送 del 指令。不过 Redlock 算法还需要考虑出错重试、时钟漂移等很多细节问题，同时因为 Redlock 需要向多个节点进行读写，意味着相比单实例 Redis 性能会下降一些。…

Redlock 使用场景
如果你很在乎高可用性，希望挂了一台 redis 完全不受影响，那就应该考虑 redlock。不过代价也是有的，需要更多的 redis 实例，性能也下降了，代码上还需要引入额外的 library，运维上也需要特殊对待，这些都是需要考虑的成本，使用前请再三斟酌。