分布式锁(Redission)

分布式锁:

使用场景:

通常对于一些使用率高的服务,我们会进行多次部署,可能会部署在不同的服务器上,但是他们获取和操作的数据仍然是同一份。为了保证服务的强一致性,我们需要对线程进行加锁,但是因为我们部署在了不同的服务器上,而互斥锁只针对加锁的那台服务器,不会去限制别的服务器,所以是不能实现强一致性的要求的。(比如在8080的线程1获取完库存后,8081的线程1也进行了获取,此时8080的线程1对内存进行了扣除,按理来说已经没有库存了,但是8081的线程1获取的时候还是有的,还会继续扣除,这样就会出现问题)

这个时候我们就要使用分布式锁来解决问题了,分布式锁可以实现不同服务器上的监控,只要有一个线程获取了锁,其他的线程(包括其他服务器上的线程)都无法继续获取锁。

那么分布式锁怎么使用呢?通常我们使用redis的时候,会通过redis中的redission来实现分布式锁。

Redission:

redission实现分布式锁有三个重点:

watch dog:

我们知道,获取了锁之后如果不去释放锁,那么别的线程就都无法去使用相关的资源,那么如果加锁的线程因为某些原因终止了,没有去执行释放锁的命令怎么办呢?也许我们可以去设置锁的时间,到时间了就立马释放锁?这种方法理论可行,但是实际上每个线程需要花费的时间是无法确定的,如果时间少了加锁就没有意义,时间久了又占用资源。如果有一个旁观者,它可以告诉我们线程是否结束,如果结束了就释放锁,如果没结束就给锁加时就好了。watch dog就可以实现这个功能。

在某个线程加锁的同时,会生成一个新的线程来启动watch dog监控,如果加锁线程没有结束watch dog会每隔(releaseTime/3)的时间做一次续期(releaseTime默认30s),如果线程结束了,我们可以发送释放锁的指令来停止watch dog续期锁。

下面是redission的代码实现,这里有一个要注意的地方,如果我们在trylock的时候设置了锁自动释放时间,redission就会认为我们可以自己控制什么时候释放锁,就不会使用watch dog来帮助我们。

重试机制:

当有线程获取锁后,另外的线程会尝试循环获取锁,不过这个次数不是无限制的,存在一个阈值。

LUA脚本:

加锁、设置过期时间等操作都是基于lua脚本完成,可以保证代码的原子性。

除此之外,redission生成的分布式锁还有一些特点

可重录:

什么意思呢?就是在同一个线程中可以多次进行加锁(同一把锁),而每加一把锁,锁的value +1,每释放一把锁,锁的value -1。举个例子,在add1方法中,我们拿了一个“heimalock”锁,此时这个lock的记录如下

因为生成了锁,value为1,在add1方法中我们又调用了add2方法,add2方法同样也拿了一个“heimalock”锁,此时并不会创建新的锁,而是将value +1变成了2,此时这个lock的记录如下

释放锁其实就是value -1,不再过多赘述。

主从一致性:

redission不能实现,但是redission提供了redlock(红锁)来实现,只不过效率太低,如果要实现主从一致性,建议使用zookeeper

  • 23
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Dak2n

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值