重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
这篇文章主要介绍“redis锁的用法”,在日常操作中,相信很多人在Redis锁的用法问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”Redis锁的用法”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
成都创新互联从2013年成立,是专业互联网技术服务公司,拥有项目成都网站建设、成都网站设计网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元仓山做网站,已为上家服务,为仓山各地企业和个人服务,联系电话:18982081108
对于分布式锁的实现,除了redis锁之外,还有很多,像zookeeper,memcache,数据库,chubby等。redis锁因为使用简单,所以被大家广泛使用。
本篇文章主要从以下几个方面来讲解redis锁:
1.redis锁使用的时候,有哪些问题2.这些问题会导致什么样子的后果3.应该如何解决这些问题
一、redis锁的实现
加锁命令:
SETNX key value:当键不存在时,对键进行设置操作并返回成功1,否则返回失败0。Key是锁的唯一标识,一般按业务来决定命名;Value 往往用来比较加锁的是哪一个线程或者哪一个消息,一般使用UUID.randomUUID().toString()方法生成。例如:setnx(key,1)
解锁命令:
DEL key通过删除键值对释放锁,以便其他线程可以通过 SETNX 命令来获取锁。例如:del(key)
锁超时:
EXPIRE key timeout设置 key 的超时时间,以保证即使锁没有被显式释放,锁也可以在一定时间后自动释放,避免资源被永远锁住。例如:expire(key,30),表示30s超时释放锁。
备注:
Redis 2.6.12以上版本为set指令增加了可选参数,伪代码如下:
set(key,1,30,NX),它将加锁和超时两个动作合并到了一起,利用原子性封装了起来。
二、redis锁解决的具体场景
场景1: 为什么redis锁需要设置超时?
原因分析:
1.redis与业务进程之间通常是使用网络通讯的方式进行数据加锁的,而网络通讯就存在丢包的情况。
再加上加锁和解锁是两个操作,这样就会存在锁永远不能释放的问题。
2.除此之外业务进程在加锁之后,也可能panic掉,没有办法去释放掉这个锁,导致分布式锁被永远挂住。
基于上面的两个原因:
分布式锁就需要一个超时时间来主动释放这个锁,防止分布式锁一直被挂住。
redis分布式锁的解决办法,1.通过加锁和超时两步操作来解决,不过我们最好使用set(key,1,30,NX)这种原子操作。2.使用setnx和expire两个操作的话,因为它们不是原子性操作,也会存在上面1和2的问题,进而导致锁被永远锁住,不过也不是没有办法,我们可以采用lua脚本在redis上面实现的方式来保证它们的原子性。
场景2: 锁超时释放了之后,加锁的业务又过来释放锁怎么办?
具体场景,进程1在超时释放了锁之后,进程2获取到了锁,后来进程1又释放锁,如此以来就有可能导致进程2没有完成就被进程1释放了锁。如下所示:
解决上面问题的关键点,在于我们在释放锁的时候,能够判断出来是不是当前加锁的进程发起的解锁操作。
一般是将进程id作为vlaue放到setnx中,在解锁之前先去判断一把这个锁是不是同一个进程的,
是就允许释放,不是就不允许解锁。
备注:这种操作其实是两步操作,判断锁,释放锁,它们并不是一个原子操作,
如此以来就存在一步操作完成,另一步没有被操作的情况。解决办法是,利用lua脚本实现锁的原子性。
场景3:锁超时释放之后,会不会存在两个业务同时处理加锁的代码的情况?
这个场景与场景2是一个问题的延伸,一旦我们在设置锁的超时时间过短,就会发生这个情况。
锁在被进程2拿走之后,进程1还没有执行代码结束,如此以来就会存在进程1和进程2同时操作那段公共代码的情况,这样就会出问题,也显然不是我们期望的场景。
对于这个场景的解决办法,往往有两个:
1.调整超时时间,让业务进程在这段时间之内一定可以执行完毕。2.启动守护进程,在业务进程没有执行完成的时候,主动的去调节这个超时时间,让锁的超时时间变长。
场景4:锁被使用之后,其他的业务如何才能获取这个分布式锁?
这个场景,是非常基本的场景,一旦锁被进程1获取之后,在释放锁之前,进程2是怎么知道何时才能够获取到锁呢?
这个解决办法有点像操作系统的轮询和信号量两种。
1.轮询的话,就需要进程2不停的去超时加锁,直到能够加锁成功位置,不过这种实现比较耗费服务器资源。2.类似信号量的方法,业务进程2将加锁消息进行订阅操作,而订阅模块会维护一个消息队列,等到锁释放之后,便从队列中取出进程2,告知锁已经释放的通知。进程2收到通知以后,就可以进行加锁操作了。
场景5:redis是集群的话,使用redis分布式锁会不会有问题?
为了保证redis的可用性,往往redis服务器会设置主从,主从服务器中的从服务器在检测到主服务器挂掉之后,就会重新选举一个作为主服务器,而redis锁是操作在主服务器上的。
一旦,发生下面的现象:
1.主服务器刚刚被进程1加锁完成,还没有来得及同步数据到从服务器就挂掉了。2.从服务器经过选举,选出了新的主服务器。3.进程2在新的主服务器上加锁成功。4.如此以来进程1和进程2都会同时操作那段公共代码,这样就会存在问题,算是加锁失败。
针对这种问题,我们其实没有太好的办法,不过还好这种数据的概率比较低。
Redis 分布式锁只能作为一种缓解并发的手段,要完全解决并发问题,仍需要数据库的防并发手段配合使用。
到此,关于“Redis锁的用法”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!