分布式锁在很多应用场景下是非常有效的手段,比如当运行在多个机器上的不同进程需要访问同一个竞争资源的时候,那么就会涉及到进程对资源的加锁和释放,这样才能保证数据的安全访问。分布式锁实现的方案有很多,比如基于ZooKeeper实现、或者基于Mysql实现等等,今天我们来一起看看如何基于Redis实现分布式锁服务。
对于分布式锁的目标,我们必须首先明确三点:
理解了上面我们列出的三个点,我们来分析一下一般的基于Redis实现的分布式锁:
使用Redis实现锁最简单的办法是创建一个key,且这个key通常有有限的存活时间,这一点可以利用Redis的过期时间特性,所以锁最终会被释放掉,当客户端需要释放资源的时候,客户端delete这个key即可。
So far so good!但是有个单点问题,假如Redis master挂掉怎么办,因此我们需要加个slave,当master挂掉的时候可以切换到slave。这又带来了新的问题,由于Redis的复制是异步的,因此我们不能保证同时只有一个客户端获得锁。
这个模型有很显然的竞态:
在特定条件下这种情况是会发生的,当出现多个客户端同时获得锁的时候,我们就认为可以这种锁方案是不可靠的。
为了后面更好的了解分布式锁的实现,我们先来看看如何基于Redis单例实现锁服务。我们可以用下面方法获得锁:
SET resource_name my_random_value NX PX 30000
上面的命令在只有当key不存在的时候会执行成功(NX选项),同时会设置过期时间为30000ms(PX选项)。key的值会被设置为my_random_value。这个值在多个客户端和锁中必须是唯一的,我们使用random value是为了方便安全地释放锁,看看下面的脚本:
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end
只有当key存在且值是预期的值的时候才会删除key。这种方式可以避免误删除其他客户端创建的锁。例如,当客户端获取锁之后执行一个很长时间的逻辑,一直过了锁的过期时间,这个时候锁会被自动释放掉,而另外一个客户端又获取了这个锁,前一个客户端终于执行完了逻辑执行,回头释放锁,删除key,其实这个时候释放的已经是另外一个客户端持有的锁了。使用DEL是不安全的,因为客户端有可能误删其他客户端持有的锁。上面脚本的方法的好处是每次获得锁的时候加上一个随机的签名,当释放锁的时候去看看是不是自己持有的锁,这个时候就不会误删。
现在我们学会了如何在Redis单例上获取锁和释放锁,那么接下来我们看看如何在Redis集群上获取锁和释放锁。
在分布式环境下,假设我们有N个master,这些节点都是独立的,因此我们没有配置复制策略。上面我们已经学会了如何在单机环境下获取锁和释放锁,我们假设的更具体一些,N=5,为了能获取锁,客户端的步骤为:
这篇文章主要介绍Redis实现分布式锁的基本方法,然后分别介绍通过Redis单例和Redis集群实现分布式锁的方法。
《Redis官方文档》
原文链接:https://my.oschina.net/andylucc/blog/677797
原文:https://www.cnblogs.com/hongmoshui/p/10598824.html