登录
首页 >  数据库 >  MySQL

数据库中的悲观锁和乐观锁

来源:SegmentFault

时间:2023-01-23 17:48:09 325浏览 收藏

哈喽!今天心血来潮给大家带来了《数据库中的悲观锁和乐观锁》,想必大家应该对数据库都不陌生吧,那么阅读本文就都不会很困难,以下内容主要涉及到MySQL、数据库、悲观锁、乐观锁,若是你正在学习数据库,千万别错过这篇文章~希望能帮助到你!

现在我们简单聊一下数据库中的悲观锁和乐观锁。

悲观锁

悲观锁正如其名称,比较悲观。总会认为:每当修改数据时,会有其他线程也会同时修改该数据。所以针对这种情况悲观锁的做法是:读取数据之后就加锁
(eg: select...for update)
,这样别的线程读取该数据的时候就需要等待当前线程释放锁,获得到锁的线程才能获得该数据的读写权限。从而保证了并发修改数据错误的问题。但是由于阻塞原因,所以导致吞吐量不高。悲观锁更适用于多写少读的情况。

在这里插入图片描述

场景: 同学A和同学B都要给你转500块钱(开心坏了吧,这样最终你能得到1000块钱)。

使用悲观锁的流程:

  1. 同学A获取到你的账户余额
    balance = 0
    并对该条记录加锁。
  2. 同学B获取你的账户余额。由于同学A已经对这条记录加锁了,所以同学B需要等同学A转帐完成(释放锁)才能获得余额。
  3. 同学A转账完成并释放锁,此时你的账户余额
    balance=balance + 500 = 500
  4. 同学B获取到你的账户余额
    balance = 500
    ,并对该条记录加锁(如果你人缘好,此时同学C给你转账也是需要等待同学B转账完成才可以转账哦)
  5. 同学B转账完成并释放锁(如果有同学C想给你转账,此时同学C就可以获得锁并转账了)。此时你的账户余额为
    balance = balance + 500 = 1000
  6. 最终你开开心心的得到了1000块钱。

假设转账过程没有锁,我们看看会发生什么:

  1. 同学A获取到你的账户余额
    balance_a = 0
    (没有加锁,此时同学B也可以获取到账户余额)
  2. 同学B获取到你的账户余额
    balance_b = 0
  3. 同学A转账完成,此时你的账户余额为
    balance = balance_a + 500 = 500
  4. 同学B转账完成,此时你的账户余额为
    balance = balance_b + 500 = 500
  5. 最终同学A和同学B都转了500,但是你最终只获得了500。这一定是不能接受的吧。

在这里插入图片描述

丢失的500块去哪里了呢?从第2步可以看到同学B获取到的账户余额是0,而不是同学A转帐之后的余额500。所以问题出在这里,这是高并发场景的常见问题。所以加锁是非常必须的。但是加了悲观锁,同学都要排队给我转账,对于没有耐心的同学就直接不转帐了,我岂不是错失了发财的好机会。那有什么好办法呢?答案就是下面的乐观锁

乐观锁

乐观锁顾名思义比较乐观,他只有在更新数据的时候才会检查这条数据是否被其他线程更新了(这点与悲观锁一样,悲观锁是在读取数据的时候就加锁了)。如果更新数据时,发现这条数据被其他线程更新了,则此次更新失败。如果数据未被其他线程更新,则更新成功。由于乐观锁没有了锁等待,提高了吞吐量,所以乐观锁适合多读少写的场景。

常见的乐观锁实现方式是:版本号version和CAS(compare and swap)。此处只介绍版本号方式。

要采用版本号,首先需要在数据库表中新增一个字段version,表示此条记录的更新版本,记录每变动一次,版本号加1。依旧使用上面转账的例子说明:

  1. 同学A获取到你的账户余额
    balance = 0
    和版本号
    version_a = 0
  2. 同学B获取到你的账户余额
    balance = 0
    和版本号
    version_b = 0
  3. 同学A转账完成
    update table set balance = ${balance}, version = version + 1 and version = 0
    。(此时版本号为0,所以更新成功)
  4. 同学B转账完成
    update table set balance = ${balance}, version = version + 1 and version = 0
    。(此时版本号为1,所以更新失败,更新失败之后同学B再转一次即可)
  5. 同学B重新转帐之后,你还是美滋滋的获得了1000。

总结

悲观锁:读取时加锁,更新完释放锁,再此过程中会造成其他线程阻塞,导致吞吐量低,适用于多写场景。

乐观锁:不加锁,只有在更新时验证数据是否被其他线程更新,吞吐量较高,适用于多读场景。

到这里,我们也就讲完了《数据库中的悲观锁和乐观锁》的内容了。个人认为,基础知识的学习和巩固,是为了更好的将其运用到项目中,欢迎关注golang学习网公众号,带你了解更多关于mysql的知识点!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表