redis的分布式锁
redis的分布式锁是通过利用redis的原子操作和特性来实现的。在分布式环境中,多个应用程序或服务可能同时访问共享资源,为了保证数据的一致性和避免冲突,可以使用分布式锁来进行同步控制。
以下是一种常见的使用redis实现分布式锁的方式:
- 获取锁:当一个应用程序需要获取锁时,它可以通过执行以下操作在redis中设置一个特定的键值对:
set lock_key unique_value nx px lock_timeout
这里的lock_key是锁的唯一标识,unique_value是唯一的值,可以是随机生成的uuid,nx表示只有当键不存在时才会设置成功,px表示设置键的过期时间。通过设置过期时间,即使获取锁的应用程序崩溃或异常退出,锁也会在一段时间后自动释放,避免出现死锁。
- 释放锁:当应用程序完成对共享资源的操作后,它可以通过执行以下操作释放锁:
if get lock_key == unique_value then delete lock_key end
应用程序首先获取锁的当前值,然后比较是否与自己持有的唯一值相等,如果相等则删除该键,表示释放锁。这样可以确保只有持有锁的应用程序才能释放锁,避免误释放其他应用程序的锁。
需要注意的是,分布式锁并不是绝对安全和可靠的。在高并发的环境中,可能存在竞争条件和死锁等问题。因此,在实际使用中,需要考虑更复杂的场景和解决方案。
误删问题
遇到下面的情况的话,会出现redis分布式锁的误删问题
这种情况下。线程1
首先获取锁,但是发生了阻塞,于是线程2
拿到了执行权,在线程2
执行的过程中,线程1
苏醒了,继续执行,到后面,线程1
执行到了删除锁的操作,此时就会把本应该属于线程2
的锁删除,这样子就造成了误删问题
解决方法
就是在每个线程释放锁的时候,去判断一下当前这把锁是否属于自己,如果属于自己,则不进行锁的删除,假设还是上边的情况,线程1卡顿,锁自动释放,线程2进入到锁的内部执行逻辑,此时线程1反应过来,然后删除锁,但是线程1,一看当前这把锁不是属于自己,于是不进行删除锁逻辑,当线程2走到删除锁逻辑时,如果没有卡过自动释放锁的时间点,则判断当前这把锁是属于自己的,于是删除这把锁。
代码实现
public class simpleredislock implements ilock { private string name; private stringredistemplate stringredistemplate; public simpleredislock(string name, stringredistemplate stringredistemplate) { this.name = name; this.stringredistemplate = stringredistemplate; } private static final string key_prefix = "lock:"; //使用uuid,在获取锁的时候存入线程标识 private static final string id_prefix = uuid.randomuuid().tostring(true) + "-"; @override public boolean trylock(long timeoutsec) { // 获取线程标示 string threadid = id_prefix + thread.currentthread().getid(); // 获取锁 boolean success = stringredistemplate.opsforvalue() .setifabsent(key_prefix + name, threadid, timeoutsec, timeunit.seconds); return boolean.true.equals(success); //这里不能是return success;否则 因为public后面的boolean是基本类型,而boolean是引用类型,如果直接返回success,是一个自动拆箱的过程,可能回发生空指针异常 } @override public void unlock() { // 获取线程标示 string threadid = id_prefix + thread.currentthread().getid(); // 获取锁中的标示 string id = stringredistemplate.opsforvalue().get(key_prefix + name); // 判断标示是否一致 if(threadid.equals(id)) { // 释放锁 stringredistemplate.delete(key_prefix + name); } } }
原子性问题
上面我们解决了误删问题
在误删问题的情况下,遇到下面的情况的话,会出现redis分布式锁的原子性问题
这种情况下,线程1先执行一段,线程1先判断锁标识,判断成功,标识是属于线程1的,后面就在线程1正准备删除锁释放的过程中,突然线程1的锁过期了,线程1发生阻塞
这个时候线程2开始执行,在线程2执行过程中,线程1阻塞结束了,会执行删除锁的操作,相当于判断锁标识并没有起到作用(因为之前一句判断过了),于是就把线程2的锁给删除掉了,又一次发生了误删操作
这个时候线程3趁虚而入,执行业务
这就是删锁时的原子性问题,之所以有这个问题,是因为判断锁标识和删除锁是2个动作,这2个动作中间产生了阻塞
那么我们就要让这2个操作一起执行,中间不能出现间隔
lua脚本
redis提供了lua脚本功能,在一个脚本中编写多条redis命令,确保多条命令执行时的原子性。lua是一种编程语言,它的基本语法大家可以参考网站:https://www.runoob.com/lua/lua-tutorial.html,这里重点介绍redis提供的调用函数,我们可以使用lua去操作redis,又能保证他的原子性,这样就可以实现拿锁比锁删锁是一个原子性动作了,作为java程序员这一块并不作一个简单要求,并不需要大家过于精通,只需要知道他有什么作用即可。
这里重点介绍redis提供的调用函数,语法如下:
redis.call('命令名称', 'key', '其它参数', ...)
例如,我们要执行set name jack,则脚本是这样:
# 执行 set name jack redis.call('set', 'name', 'jack')
例如,我们要先执行set name rose,再执行get name,则脚本如下:
# 先执行 set name jack redis.call('set', 'name', 'rose') # 再执行 get name local name = redis.call('get', 'name') # 返回 return name
写好脚本以后,需要用redis命令来调用脚本,调用脚本的常见命令如下:
例如,我们要执行 redis.call(‘set’, ‘name’, ‘jack’) 这个脚本,语法如下:
如果脚本中的key、value不想写死,可以作为参数传递。key类型参数会放入keys数组,其它参数会放入argv数组,在脚本中可以从keys和argv数组获取这些参数:
利用java代码调用lua脚本改造分布式锁
接下来我们来回一下我们释放锁的逻辑:
释放锁的业务流程是这样的
1、获取锁中的线程标示
2、判断是否与指定的标示(当前线程标示)一致
3、如果一致则释放锁(删除)
4、如果不一致则什么都不做
如果用lua脚本来表示则是这样的:
最终我们操作redis的拿锁比锁删锁的lua脚本就会变成这样
-- 这里的 keys[1] 就是锁的key,这里的argv[1] 就是当前线程标示 -- 获取锁中的标示,判断是否与当前线程标示一致 if (redis.call('get', keys[1]) == argv[1]) then -- 一致,则删除锁 return redis.call('del', keys[1]) end -- 不一致,则直接返回 return 0
lua脚本本身并不需要大家花费太多时间去研究,只需要知道如何调用,大致是什么意思即可,所以在笔记中并不会详细的去解释这些lua表达式的含义。
我们的redistemplate中,可以利用execute方法去执行lua脚本,参数对应关系就如下图
代码实现
我们先写入lua这个脚本
-- 比较线程标示与锁中的标示是否一致 if(redis.call('get', keys[1]) == argv[1]) then -- 释放锁 del key return redis.call('del', keys[1]) end return 0
然后我们来调用这个脚本
下面是完整代码
public class simpleredislock implements ilock { private string name; private stringredistemplate stringredistemplate; public simpleredislock(string name, stringredistemplate stringredistemplate) { this.name = name; this.stringredistemplate = stringredistemplate; } private static final string key_prefix = "lock:"; private static final string id_prefix = uuid.randomuuid().tostring(true) + "-"; private static final defaultredisscript<long> unlock_script; static { unlock_script = new defaultredisscript<>(); unlock_script.setlocation(new classpathresource("unlock.lua")); unlock_script.setresulttype(long.class); } @override public boolean trylock(long timeoutsec) { // 获取线程标示 string threadid = id_prefix + thread.currentthread().getid(); // 获取锁 boolean success = stringredistemplate.opsforvalue() .setifabsent(key_prefix + name, threadid, timeoutsec, timeunit.seconds); return boolean.true.equals(success); //这里不能是return success;否则 因为public后面的boolean是基本类型,而boolean是引用类型,如果直接返回success,是一个自动拆箱的过程,可能回发生空指针异常 } @override public void unlock() { // 调用lua脚本 stringredistemplate.execute( unlock_script, collections.singletonlist(key_prefix + name), id_prefix + thread.currentthread().getid()); } }
在技术的道路上,我们不断探索、不断前行,不断面对挑战、不断突破自我。科技的发展改变着世界,而我们作为技术人员,也在这个过程中书写着自己的篇章。让我们携手并进,共同努力,开创美好的未来!愿我们在科技的征途上不断奋进,创造出更加美好、更加智能的明天!
以上就是解决redis分布式锁的误删问题和原子性问题的详细内容,更多关于redis分布式锁误删和原子性问题的资料请关注代码网其它相关文章!
发表评论