首先明确分布式锁应该具备什么特性:获取锁的业务无论正常与否,都必须能释放锁,这样才能避免死锁;锁应该具有高可用性。
我们来看看redis是怎么来实现锁的的。
redis主要是通过setnx、get、getset、del命令来完成加锁,抢锁和释放锁的操作的,这里我用两个客户端来模拟下加锁的过程。下面有实际操作的截图。
1、客户端1使用setnx获取到锁,并设置锁的当前时间。设置超时时间就是为了业务挂了,锁不能释放成为死锁。
执行命令
setnx lock 0
为了方便举例,我们假定锁的当前时间是从0秒开始的,超时时间为3秒。如果结果返回为1,表明加锁成功,可以执行业务逻辑了。
2、当第一秒钟客户端2使用setnx获取锁,执行命令
setnx lock 1
返回值为0,则加锁失败。
3、客户端2接收到加锁时间的回应后,会去查看锁是否超时。执行命令
get lock
返回值为加锁的时间,假设现在时间已经到第4秒了,客户端会使用返回的时间0加上超时时间3小于当前时间4,锁已经超时了。
4、客户端2使用getset命令去获取锁。
getset lock 4
这时候返回的是前一次加锁的时间,如果这个时间是0,证明加锁成功,因为和前一次get的值相同。如果不同,说明锁已经被别人抢占了,加锁失败,继续重复步骤3和4。
5、业务执行完成后,判断下锁是否超时,没有超时,不用管了。如果没有超时,调用del命令释放锁即可。
redis存在的问题
1、redis如果是单机的话是有单点问题的,不满足高可用性。redis集群因为是ap模型,是不能保证一致性的,官方提供了redlock算法来解决这个问题,但是至少需要3个master-slave节点才能完成,成本也较大。redlock相当于是来实现一致性协议的。
2、锁的超时时间设定问题,太长太短都不合适,太长了如果服务挂掉了会一直阻塞业务,太短了有可能业务还没执行完成就释放了。当然可以用官方提供redisson解决。
可以关注我,我在文章里面还分享了zk,etcd怎么实现分布式锁的。
Redis分布式锁的原理是什么?如何续期?
分布式锁的需求产生
分布式锁的需求是伴随着应用分布式部署而来的,在单体应用,且只部署一台服务器的情况下,通过java的同步锁即可实现。同步锁,即是一个原子性的操作。
那么当应用进行了分布式部署,应用有多个服务,这个时候应用服务端就没有一个可提供原子性操作的地方了,Redis性能高,且是单线程,因此可提供一个原子性操作的地方,利用它,就可以实现分布式锁。
用场景说话,使用Redis分布式锁的场景如下图所示:
如下图所示,随后会根据场景说明分布式锁及续期相关问题的来龙去脉。
- 图中序号1:进来一个请求,这个请求要求我们保存一个“订单A”;
- 图中序号2:2.1 步,请求进来,首先去尝试设置一个Redis 值,他的键就是订单号“订单A”,如果尝试成功,则代表我这个线程是第一次设置,相当于我拿到了这个锁;如果尝试失败,那么,可以抛出异常或者等待一段时候后再次重试,这里可以根据业务场景的不同采取不同的策略。这里的关键是在Redis中的操作是单线程的,因此该操作是原子性的。2.2步,为了防止应用服务意外中断,Redis中的数据一直存活,消耗资源,需要设置一个超时时间。(如果为了严谨,可以将2.1, 2.2 两步封装成一个lua脚本部署在Redis服务器上)
- 图中序号3:情况A,这个时候是当Redis的key还未失效,程序就已经执行完成,且删除了Redis中的数据,一切正常;情况B:就是需要续期的场景,如果要避免这个场景的出现,可以将Redis key的失效时间设置长一点,可以应对大多数业务。如果要彻底解决,可以在应用端添加一个Redis锁的注册中心,然后起一个监听线程去监听这个注册中心,发现有锁还在被持有,但是Redis 已经快过期了,则修改相应key的失效时间,进行续期。
Java语言如何正确实现Redis分布式锁?
和大家分享我的经验,如何用redis提供的一个简单接口,轻松实现redis分布式锁。
在开始之前,我先简单介绍下redis的性能。
高效的Redis
Redis本身是单线程的,这样带来的好处是能够提高读写效率。多线程通常来说会有上下文切换带来的时间损耗,而redis通过绑定单个CPU到某块内存,实现了上下文切换的最小开销,因此这种场景反而比多线程还要高效。
不安全的Redis
但是,如果有不同的节点同时要对Redis中的同一个数据进行操作,由于是来自不同Redis服务器,就会发生线程不安全的情况。
举例有两个功能函数X和Y(也可以看做是两个服务器节点),二者功能相同,都要执行读取Redis中变量P,并且对其加一的操作。如果是线程安全的,那么X和Y分别执行完之后,P的值应该比原来增加2,但是由于函数XY互相独立,那就可能发生下面这种情况:
1 X读取P
2 Y读取P
3 X将P+1写回Redis
4 Y将P+1写回Redis
执行结束后,P的值却变成了P+1,而不是P+2。
这就是线程不安全导致的结果。
redis的分布式锁
那么如何用Redis来避免上面的情况呢。
Redis对外开放了一个非常厉害的api,目前经常被大家用来做分布式锁,是绝对的线程安全,这个函数就是SET key field value加上NX参数。这个NX参数可是了不得,通常来说,set函数是不管field字段是否存在,只要写入成功就会返回1,但是如果增加了NX参数,那么如果field值在redis中已经存在,就会返回nil,否则才返回1。因此可以通过这个函数来执行加锁操作,如果返回值不为nil,则加锁成功,否则代表有其他线程在操作数据,当前请求需要等待。
不仅如此,为了避免死锁,SET还有一个参数为EX,即EX毫秒后,field会自动清空。
此外,还有PX,XX参数,具体含义见如下文档。
以上就是我在工作中总结的防止redis并发的方式,如果你有其他想法,欢迎在下方评论区与我沟通。
我是苏苏思量,来自BAT的java开发工程师,每天分享技术见闻,欢迎关注我,与我共同进步。