基于Redis实现的分布式锁-[setnx命令、Redission]

redis用作分布式锁

通过setnx命令,由于redis的单线程的,用了命令之后,只能有一个客户端对某一个key设置

值,在没有过期或删除key的时候是其他客户端是不能设置这个key的

reids用作消息队列:list类型的数据类型、而后还有优化过的stream数据类型

redission的分布式锁

解决了setnx命令锁的缺陷,比如说不好控制锁的失效时间和等待时间

1.在redisson中需要手动加锁,并且可以控制锁的失效时间和等待时间,当锁住的一个业务还没有执行完成的时候,在redisson中引入了一个看门狗机制,就是说每隔一段时间就检查当前业务是否还持有锁,如果持有就增加加锁的持有时间,当业务执行完成之后需要使用释放锁就可以了

2.在高并发下,一个业务有可能会执行很快,先客户1持有锁的时候,客户2来了以后并不会马上拒绝,它会自旋不断尝试获取锁,如果客户1释放之后,客户2就可以马上持有锁,性能也得到了提升。

重入性:

redission实现的分布式锁是可重入的,为了避免死锁的产生。在存储数据的时候采用的hash结构,大key可以按照自己的业务进行定制,其中小key是当前线程的唯一标识,value是当前线程重入的次数

不能解决主从一致性问题:

当线程1加锁成功后,master节点数据会异步复制到slave节点,此时当前持有Redis锁的master节点宕机,slave节点被提升为新的master节点,假如现在来了一个线程2,再次加锁,会在新的master节点上加锁成功,这个时候就会出现两个节点同时持有一把锁的问题。

红锁解决这个问题,它的主要作用是,不能只在一个redis实例上创建锁,应该是在多个redis实例上创建锁,并且要求在大多数redis节点上都成功创建锁,红锁中要求是redis的节点数量要过半。这样就能避免线程1加锁成功后master节点宕机导致线程2成功加锁到新的master节点上的问题了。

但是,如果使用了红锁,因为需要同时在多个节点上都添加锁,性能就变的很低了,并且运维维护成本也非常高,所以,我们一般在项目中也不会直接使用红锁,并且官方也暂时废弃了这个红锁

Redission使用Redis作为底层存储和通信的基础,在实现分布式锁时,它主要依赖于Redis的原子性和特定数据结构的支持。下面是Redission实现分布式锁的具体原理: 1. RedisSETNX命令Redission使用RedisSETNX命令(SET if Not eXists)来实现分布式锁SETNX命令可以在键不存在时将键的值设置为指定的值,如果键已经存在,则什么都不做。这意味着只有一个客户端可以成功地将键设置为指定值,其他客户端将无法获得锁。 2. 锁的持有者:获取到锁的客户端被视为锁的持有者,其他客户端则处于等待状态。 3. 锁的有效期:为了避免锁的持有者在发生故障时一直持有锁而无法释放,Redission为每个获取到的锁设置了一个有效期。默认情况下,锁的有效期是30秒,如果在有效期内没有手动释放锁,Redission将自动释放锁。 4. 锁的续约:在某些情况下,锁的持有者可能需要延长锁的有效期,以避免在某些复杂业务场景下出现问题。Redission提供了锁的续约机制,允许持有锁的客户端在锁的有效期内延长锁的持有时间。 5. 锁的释放:当锁的持有者完成业务逻辑后,需要手动释放锁。Redission使用Redis的DEL命令来删除锁的键,以释放锁。 总结起来,Redission实现分布式锁的原理是通过RedisSETNX命令实现对锁的获取,并使用锁的有效期和续约机制来保证锁的自动释放和防止死锁。通过这种方式,Redission提供了一个简单而强大的分布式锁实现,可以在分布式环境中实现线程安全和互斥访问的控制。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值