ZooKeeper中的乐观锁与悲观锁

本文探讨了ZooKeeper中的乐观锁删除机制,通过节点的版本号cversion实现并发控制,避免数据冲突。乐观锁在保持高性能的同时,避免了悲观锁的锁竞争问题。同时,提到了Redis中类似的概念,都是利用版本号进行乐观锁的实现。对比两者,乐观锁在高并发场景下展现出更好的性能优势。
摘要由CSDN通过智能技术生成

ZooKeeper中的乐观锁删除:

如图:

分析乐观锁与悲观锁:

所谓乐观锁删除,其实就是我们乐观的认为并发的请求数不多从而不上锁的方案 但说是不上锁 其

实也会有一种锁的方式。这种锁的方式就是使用zookeeper节点

的版本号cversion,可以允许你有多个线程并发进来请求一个节点上的数据,但是不允许删除。

如何控制不允许删除?当多个并发线程进行请求获取一个节点上的数据之后,获取到的版本号

cverion的值是一致的,但是当其中一个线程进行set操作进行修改节点对应的值时,此时这个节点

对应的版本号cverion的值就会+1.那么此时其他并发的线程使用版本号进行删除的时候,就会删除

失败。

与之对应的就是悲观锁,悲观锁其实就是悲观的认为并发请求数过大,我们必须进行上锁,这样的

话,只有当获取到锁的线程才可以进行执行请求到资源,其他的

线程必须进行等待。

悲观锁与乐观锁对比:

悲观锁上锁之后,性能降低。乐观锁恰恰的保留的性能。

后续:

redis中的乐观锁和悲观锁同理,也是给定一个version版本号

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
悲观锁乐观锁和分布式锁是常用的并发控制机制,它们在解决并发访问的问题上有一些区别: 1. 悲观锁: - 基于数据库的锁机制,如行锁或表锁,通过加锁来保证在操作期间数据不会被其他事务修改。 - 悲观锁认为在并发环境下,数据很可能会被其他事务修改,因此在操作前先加锁以防止并发冲突。 - 当一个事务获取到悲观锁后,其他事务需要等待锁的释放才能进行操作,因此可能会带来较高的性能开销。 - 适用于并发冲突较多、对数据一致性要求较高的场景。 2. 乐观锁: - 通过在数据表增加一个版本号或时间戳字段,在更新操作时检查版本号或时间戳来解决并发更新问题。 - 乐观锁认为并发冲突的概率较低,因此不主动加锁,而是在更新时检查数据是否已被其他事务修改,如果已被修改则不执行更新操作。 - 当检测到并发冲突时,可以通过重试操作或者回滚事务来处理,以确保数据的一致性。 - 适用于并发冲突较少、对性能要求较高的场景。 3. 分布式锁: - 在分布式系统,用于保证在不同节点或进程间的并发操作的一致性。 - 通过协调多个节点或进程之间的锁状态,确保只有一个节点或进程可以获得锁并执行关键操作,其他节点或进程需要等待。 - 分布式锁可以基于数据库、缓存或者第三方组件实现,常用的实现方式有基于ZooKeeper的实现、Redis的实现等。 - 适用于分布式系统需要保证数据操作的原子性和一致性的场景。 总体来说,悲观锁乐观锁是在单个节点或进程内使用的并发控制机制,而分布式锁是用于跨节点或进程的分布式系统。具体使用哪种锁需要根据场景的需求和特点来选择,以达到最佳的并发控制效果。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值