ZK分布式锁

zk分布式锁

1. 锁的类型实现

独占锁:用znode来看做一把锁,通过create znode来实现。只有创建成功的才拥有这把锁。

时序锁:在znode的节点下面创建一些临时有序的节点。通过父节点distribute_lock来维持一份sequence,保证子节点创建时序,形成全局时序。

2. redis锁和zk锁的区别redis的优点:

优点:

  1. 速度快
    缺点:
  2. 在分布式情况下,redis主设置了key,但是没有同步的情况下,主挂了。导致其他线程也能正常上锁了。

zk锁的优点:
1. 锁失效实现简单,临时的节点绑定的是client端,只要client端锻炼自动失效,不需要实现过期时间然后不需要关心业务时间。
2. 锁不需要去循环轮询的方式去查看是不是可以获取锁,可以通过watch来实现。采用监听通知的模型。

缺点:
​ 频繁的删除节点,性能不如redis

### Redisson与Zookeeper分布式锁机制对比 #### Redisson分布式锁实现 Redisson提供了多种类型的分布式锁,其中最常用的是基于Redis的单节点锁定算法。这种锁通过条件设置(如果不存在则设置)来获取锁,并通过原子删除(仅当值匹配时才删除)释放锁[^1]。 ```java RLock lock = redisson.getLock("anyLock"); lock.lock(); try { // 执行业务逻辑 } finally { lock.unlock(); } ``` 这种方式简单易懂,在大多数情况下能够满足需求。然而需要注意的是,这些锁只是尽力而为的最佳实践,并不完全可靠,可能会偶尔失败。因此建议在代码中清晰记录这一点并考虑其适用场景。 #### Zookeeper分布式锁实现 相比之下,Zookeeper实现了更为严格的分布式协调服务。它利用`znode`版本号作为围栏令牌(fencing token),确保每次写入操作都携带一个严格单调递增的令牌。这使得即使在网络分区或其他异常条件下也能保持数据一致性[^2]。 创建临时顺序节点以构建分布式互斥锁: ```java InterProcessMutex mutex = new InterProcessMutex(client, "/examples/locks"); mutex.acquire(); try { // 执行业务逻辑 } finally { mutex.release(); } ``` 这里的关键在于存储服务器会主动验证令牌的有效性,拒绝任何使令牌回退的操作请求。只要锁服务能生成严格单调增加的令牌,则此方法就是安全可靠的。 #### 两者之间的差异 - **可靠性**: Zookeeper由于采用了更复杂的协议设计以及更强的一致性保障措施,在面对复杂网络环境下的表现更加稳定;而Redisson虽然也具备一定的容错能力,但在极端情况下可能无法保证绝对的安全性。 - **性能开销**: 单纯从效率角度来看,采用简单的SETNX(SET If Not eXists)指令实现加解锁过程显然要比维护整个集群状态要轻量得多。所以对于那些不需要极高一致性的应用场景来说,使用Redisson可能是更好的选择。 - **配置难度**: 设置和管理一个多副本组成的Zookeeper群集相对较为繁琐一些,涉及到更多参数调整和技术细节处理;相反地,只需要连接到一台Redis实例就可以轻松部署起一套基本可用的Redisson方案来了。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值