悲观锁和乐观锁

悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。

悲观所的简单实现方式:
             select......for update
如:A 和 B 两个人同时执行下面的SQL:
             select * from student where id = 1 for update;
当A在执行,还未提交当前事务,此时,B不能执行该SQL,处于阻塞状态

优点:安全,在执行大量的修改数据操作的时候使用
缺点:效率较低,如果操作中查询居多,修改较少的情况,不建议使用悲观锁

乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
原理:
+----+---------+----------+------+----------+-----------+

| id | name | gender | age | height | version |

+----+---------+----------+------+----------+-----------+

| 1  | Jay     | male    | 29   | 1.88     | 1            |

+----+---------+----------+------+----------+-----------+
在表中添加一个int类型的列:version
在执行修改之前,先将当前数据的version查询出来: select version from student where id = 1

然后在修改的时候,在条件中增加version: update student set  name = 'lucy' ,version = version+ 1 where id = 1 and version = 1
此时,如果另一个并发的事务同时修改这条数据的时候,执行的SQL:
update student set  name = 'lily' ,version = version+ 1 where id = 1 and version = 1
因为前一个事务已经将version修改为2,  所以这条SQL执行返回的受影响的行数为0(表示修改失败),给用户相应的提示信息即可

优点: 相对于悲观所而言,乐观锁执行的效率更高
缺点: 当执行大量的修改操作的时候,会经常出现修改失败的情况,用户体验不好
建议在执行查询多,修改少的时候使用

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值