之前我们使用的定时任务都是只部署在了单台机器上,为了解决单点的问题,为了保证一个任务,只被一台机器执行,就需要考虑锁的问题,于是就花时间研究了这个问题。到底怎样实现一个分布式锁呢?
阅读这篇文章你可以了解到:
锁的本质就是互斥,保证任何时候能有一个客户端持有同一个锁,如果考虑使用redis来实现一个分布式锁,最简单的方案就是在实例里面创建一个键值,释放锁的时候,将键值删除。但是一个可靠完善的分布式锁需要考虑的细节比较多,我们就来看看如何写一个正确的分布式锁。
所以我们直接基于 redis 的 setNX (SET if Not eXists)命令,实现一个简单的锁。直接上伪码
锁的获取:
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
几个细节需要注意:
KEYS[1]) == ARGV[1]
,在这里 KEYS[1]
是从redis里面取出来的value,ARGV[1]
是上文生成的my_random_value
。之所以进行以上的判断,是为了保证锁被锁的持有者释放。我们假设不进行这一步校验:
造成这个问题的关键,在于客户端B持有的锁,被客户端A释放了。get
,判断,del
三个步骤。如果不能保证三个步骤的原子性,分布式锁就会有并发问题。注意了以上细节,一个单redis节点的分布式锁就达成了。
在这个分布式锁中还是存在一个单点的redis。也许你会说,Redis是 master-slave的架构,发生故障的时候切换到slave就好,但是Redis的复制是异步的。
这样由于Master的宕机,造成了同时多人持有锁。如果你的系统可用接受短时时间内,有多人持有锁。这个简单的方案就能解决问题。
但是如果解决这个问题。Redis的官方提供了一个Redlock的解决方案。
为了解决,Redis单点的问题。Redis的作者提出了RedLock的解决方案。方案非常的巧妙和简洁。 RedLock的核心思想就是,同时使用多个Redis Master来冗余,且这些节点都是完全的独立的,也不需要对这些节点之间的数据进行同步。
假设我们有N个Redis节点,N应该是一个大于2的奇数。RedLock的实现步骤:
对于释放锁的实现就很简单了。想所有的Redis节点发起释放的操作,无论之前是否获取锁成功。
同时需要注意几个细节:
了解了Redis分布式的实现以后,其实觉得大多数的分布式系统其实原理很简单,但是为了保证分布式系统的可靠性需要注意很多的细节,琐碎异常。 RedLock算法实现的分布式锁就是简单高效,思路相当巧妙。 但是RedLock就一定安全么?我还会写一篇文章来讨论这个问题。敬请大家期待。