微信搜索superit|邀请体验:大数据, 数据管理、OLAP分析与可视化平台 | 赞助作者:赞助作者

getset原子性 redis_redis,zookeeper,etcd是怎样实现分布式锁的

go aide_941 3℃ 0评论

前面我们介绍了下锁的基本概念,这篇文章主要介绍下Redis、Zookeeper、etcd怎么来实现分布式锁。

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解决。

zookeeper
zookeeper是基于顺序临时节点和watch机制实现分布式锁的

1、创建持久化节点/lock。

create /lock 0

2、server1来获取锁,在lock目录下创建有序的临时节点

create -s -e /lock/ 0

3、server1查看lock下面的子节点,自己的序号是不是最小的,这时候只有一个节点肯定是最小的,则获取成功

4、server2这时候也来获取锁,创建有序的临时节点

create -s -e /lock/ 0

5、server2发现自己的节点序号不是最小,则获取失败,是最小则获取成功。并监听比自己小的前一个节点。

6、当上一个节点被删除的时候,会通知当前节点,这时候重复5步骤。

zk总结
zk采用zab协议保证一致性,并且不用设置超时时间了,如果服务加锁挂掉了,临时节点也会自动删除。

当然也可用使用Apache开源的 curator框架, 自带了分布式锁解决方案,原理和上述差不多。

zk加锁释放锁都是通过动态创建节点、销毁节点来实现的,性能消耗较大。

http://curator.apache.org/
etcd
etcd调用可以通过restful API的方式进行,这些需要通过prevExist实现分布式锁,如果prevExist为true, 则这是一个更新请求,如果prevExist的值是false,则是一个创建请求。

1、server1获取锁,设置超时时间是3秒

http://127.0.0.1:2379/v2/keys/locks?value=xxx&ttl=3&prevExist=false

2、为了防止业务还没有执行完,锁释放,所以每隔1秒需求重新设置下值。这个就是锁续租约。

http://127.0.0.1:2379/v2/keys/locks?value=xxx&ttl=3&prevExist=true

3、server2这时候去获取锁,则会失败

http://127.0.0.1:2379/v2/keys/locks?value=xxx&ttl=3&prevExist=false

4、server2可以监听lock的变化。当lock目录有变化的时候就会接到通知,然后重复步骤3。

这里要注意watch事件不能太多。

http://127.0.0.1:2379/v2/keys/lock?wait=true

etcd总结
上面这个是etcd2的实现,etcd3本身已经支持分布式锁了,key增加Revision了,客户端可以判定自己key对应的Revision是不是最小来获取锁,机制和zk获取最小值类似,但是etcd3可能还不够成熟。

etcd使用raft协议,相比paxos协议会容易理解些。

总结
以上就是redis、zk、etcd怎么实现分布式锁的过程了。

每个方案都有可行的,还是看公司整体情况选择使用哪种方案。

只要能保持读取和修改状态是原子性操作都能当锁使用,但是分布式锁需要明确的几个条件:获取锁的业务无论正常还是异常,都需要保证可以释放,否则会出现死锁的情况,还有就是锁释放后需要及时让等待锁的一方知道,方便再次获取锁。

欢迎关注我,后续会持续分享架构方面文章,谢谢

相关资源:Redis实现分布式锁的几种方法总结_redissetnx原子性实现-其它代码…
————————————————
版权声明:本文为CSDN博主「许多的小兵器」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_31094177/article/details/112335430

转载请注明:SuperIT » getset原子性 redis_redis,zookeeper,etcd是怎样实现分布式锁的

喜欢 (0)or分享 (0)

您必须 登录 才能发表评论!