redis与zookeeper分布式锁对比

本文对比了Redis和Zookeeper实现分布式锁的区别,包括数据结构、线程阻塞方式、唤醒机制以及锁的高可用性。Redis利用Redisson的Hash数据结构和信号量,而Zookeeper依赖临时有序节点和等待唤醒机制。Zookeeper保证强一致性,适合可靠性要求高的场景,而Redis以最终一致性换取高性能,适用于追求速度的场景。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

主要区别

这里讲的分布式锁实现,redis是基于redisson实现,zk是基于curatorFramework实现;

1)实现的数据结构不同

redis的分布式锁是利用redis的hash数据结构,大key存储的锁名称,小key存储uuid-线程id,value存储重入次数;通过客户端往redis服务器发送lua脚本,实现redis上hash结构锁信息的更新;另外会定时复位超时时间,默认超时时间设置为30s,每10s后,若发现锁依旧被原线程持有,则复位超时时间;

zk的分布式锁是利用存储在zk上的临时有序节点,每个线程会依次在zk上创建一个临时有序节点,每个节点监听其上一个节点,没有获得锁的线程会利用synchronized的wait方法实现等待,当锁被释放时,会删除临时顺序节点,只会触发后一顺序节点去获取锁,理论上不存在竞争,只排队,非抢占,公平锁,先到先得;

2)没有获得锁的线程阻塞的方式不同

redis上是通过semaphore信号量,使没有获得锁的线程阻塞,state初始化为0,意味着所有线程都无法获得信号量,都将阻塞;

zk是通过synchronized,使没有获得锁的线程全部进入等待状态;

3)阻塞的线程被唤醒的方式不同

redis基于自带的发布订阅模式,当锁被释放时,会发布主题,从而订阅该主题的线程会唤醒semphore上阻塞的自己,继续循环获取锁;

zk是基于synchronized的wait和notify机制,以及监听watch机制,以及最小序号的节点获得锁规则;被唤醒后,继续循环直到拿到锁;

4)锁的高可用

zk具有强一致性,虽然牺牲了一定的性能,但能保证高可用,所以对追求可靠性较高的场景,可使用zk实现分布式锁;
redis具有最终一致性,特别是在redis主从架构时,只要master上锁的元数据更新了,就立即返回给客户端ok,后边会慢慢同步给slave,牺牲了可靠,对于追求性能的场景,可使用redis实现分布式锁;

具体源码分析见我的以前文章,链接如下:

用redis实现分布式锁
用zookeepe实现分布式锁

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

orcharddd_real

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

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

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

打赏作者

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

抵扣说明:

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

余额充值