基于Redis Lua脚本实现的分布式锁

最近项目中需要用到一个分布式的锁,考虑到基于会话节点实现的zookeeper锁性能不够,于是想使用redis来实现一个分布式的锁。

简单的说,锁是一个单一的参考点,多个线程基于它来检查是否允许访问资源。例如,一个想写数据的线程,它必须先检查是否存在一个写锁。如果写锁存在,需要等待直到锁释放后它才能获取到属于它的锁并执行写操作。这样,通过锁就可以避免多个线程的同时写造成的数据冲突。

现代的操作系统提供了内置的函数来帮助程序员实现并发控制,例如 flock 函数。但是如果多线程的程序运行在多台机器上呢?如何在分布式系统下控制对资源的访问呢?


使用一个中心化的锁服务

首先,我们需要一个所有线程都可以访问到的地方来存储锁。这个锁只能存在于一个地方,从而保证只有一个权威的地方可以定义锁的建立和释放。

Redis是实现锁的一个理想的候选方案。作为一个轻量级的内存数据库,快速,事务性和一致性是选择redis作为锁服务的主要原因。


设计锁

锁本身是很简单的,就是redis数据库中一个简单的key。建立和释放锁,并保证绝对的安全,是这个锁的设计比较棘手的地方。有两个潜在的陷阱:

1)、应用程序通过网络和redis交互,这意味着从应用程序发出命令到redis结果返回之间会有延迟。这段时间内,redis可能正在运行其他的命令,而redis内数据的状态可能不是你的程序所期待的。如何保证程序中获取锁的线程和其他线程不发生冲突?

2)、如果程序在获取锁后突然crash,而无法释放它?这个锁会一直存在而导致程序进入“饿死”(原文成为“死锁”,感觉不太准确)。


建立锁

可能想到的最简单的方法是“用GET方法检查锁,如果锁不存在,就用SET方式设置一个值”。

这个方法虽然简单,但是不能保证独占锁。

回顾前面所说的第1个陷阱:因为在GET和SET操作之间有延迟,我们没法知道从“发送命令”到“redis服务器返回结果”之间的这段时间内是否有其他线程也去建立锁。当然,这些都在几毫秒之内,发生的可能性相当低。但是如果在一个繁忙的环境中运行着大量的并发线程和命令,重叠的可能性并不是微不足道的。

为了解决这个问题,应该用SETNX命令。SETNX消除了GET命令需要等待返回值得问题,SETNX只有在key不存在时才返回成功。这意味着只有一个线程可以运行SETNX命令,而其他线程会失败,然后不断重试,直到它们能建立锁。


释放锁

一旦线程成功执行了SETNX命令,它就建立了锁并且可以基于资源进行工作。工作完成后,线程需要通过删除redis的key来释放这个锁,从而允许其他线程能尽快的获取锁。


尽管如此,也有需要小心的地方!回顾前面说的第2个陷阱:如果线程crash了,它永远都不会删除redis的key,所以这个锁会一直存在,从而导致“饿死”现象。那么如何避免这个问题呢?


锁的存活时间


我们可以给锁加一个存活时间(TTL),这样一旦TTL超时,这个锁的key会被redis自动删除。任何由于线程错误而遗留下来的锁在一个合适的时间之后都会被释放,从而避免了“饿死”。这存粹是一个安全特性,更有效的方式仍然是确保尽量在线程里面释放锁。

可以通过PEXPIRE命令为Redis的key设置TTL,而且线程里可以通过MULTI/EXEC事物的方式在SETNX命令后立即执行,例如:

MULTI
SETNX lock-key
PEXPIRE 10000 lock-key
EXEC

尽管如此,这会产生另外一个问题。PEXPIRE命令没有判断SETNX命令的返回结果,无论如何都会设置key的TTL。如果这个地方无法获取到锁或有异常,那么多个线程每次想获取锁时,都会频繁更新key的TTL,这样会一直延长key的TTL,导致key永远都不会过期。为了解决这个问题,我们需要Redis在一个命令里面处理这个逻辑。我们可以通过Redis脚本的方式来实现。

注意-如果不采用脚本的方式来实现,可以使用Redis 2.6.12之后版本SET命令的PX和NX参数来实现。为了考虑兼容2.6.0之前的版本,我们还是采用脚本的方式来实现。

redis脚本


由于Redis支持脚本,我们可以写一个Lua脚本在Redis服务端运行多个Redis命令。应用程序通过一条eval sha命令就可以调用被Redis服务端缓存的脚本。这里强大的地方在于你的程序只需要运行一条命令(脚本)就可以以事物的方式运行多个redis命令,还能避免并发冲突,因为一个redis脚本同一时刻只能运行一次。


这是Redis里面一个设置带TTL的锁的Lua脚本:

--
	-- Set a lock
	--
	-- KEYS[1]   - key
	-- KEYS[2]   - ttl in ms
	-- KEYS[3]   - lock content
	local key     = KEYS[1]
	local ttl     = KEYS[2]
	local content = KEYS[3]
	  
	local lockSet = redis.call('setnx', key, content)
	  
	if lockSet == 1 then
	  redis.call('pexpire', key, ttl)
	end
  
return lockSet

还缺少一个释放锁的脚本,如果一直依赖TTL来释放锁,效率会很低。Redis的Set操作文档就提供了一个释放锁的脚本:

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

应用程序中只要加锁的时候指定一个随机数或特定的value作为key的值,解锁的时候用这个value去解锁就可以了。当然,每次加锁时的value必须要保证是唯一的。











评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值