扫码订阅《 》或入驻星球,即可阅读文章!

GOLANG ROADMAP

阅读模式

  • 沉浸
  • 自动
  • 日常
首页
Go学习
  • Go学院

    • Go小课
    • Go小考
    • Go实战
    • 精品课
  • Go宝典

    • 在线宝典
    • B站精选
    • 推荐图书
    • 精品博文
  • Go开源

    • Go仓库
    • Go月刊
  • Go下载

    • 视频资源
    • 文档资源
Go求职
  • 求职服务

    • 内推互助
    • 求职助力
  • 求职刷题

    • 企业题库
    • 面试宝典
    • 求职面经
Go友会
  • 城市
  • 校园
推广返利 🤑
实验区
  • Go周边
消息
更多
  • 用户中心

    • 我的信息
    • 推广返利
  • 玩转星球

    • 星球介绍
    • 角色体系
    • 星主权益
  • 支持与服务

    • 联系星主
    • 成长记录
    • 常见问题
    • 吐槽专区
  • 合作交流

    • 渠道合作
    • 课程入驻
    • 友情链接
author-avatar

GOLANG ROADMAP


首页
Go学习
  • Go学院

    • Go小课
    • Go小考
    • Go实战
    • 精品课
  • Go宝典

    • 在线宝典
    • B站精选
    • 推荐图书
    • 精品博文
  • Go开源

    • Go仓库
    • Go月刊
  • Go下载

    • 视频资源
    • 文档资源
Go求职
  • 求职服务

    • 内推互助
    • 求职助力
  • 求职刷题

    • 企业题库
    • 面试宝典
    • 求职面经
Go友会
  • 城市
  • 校园
推广返利 🤑
实验区
  • Go周边
消息
更多
  • 用户中心

    • 我的信息
    • 推广返利
  • 玩转星球

    • 星球介绍
    • 角色体系
    • 星主权益
  • 支持与服务

    • 联系星主
    • 成长记录
    • 常见问题
    • 吐槽专区
  • 合作交流

    • 渠道合作
    • 课程入驻
    • 友情链接
  • 面试宝典系列

    • MySQL面试题汇总
  • 宝典内容

    • 1.主键 超键 候选键 外键是什么?
    • 2.数据库事务的四个特性及含义?
    • 3.视图的作用,视图可以更改么?
    • 4.drop,delete与truncate的区别?
    • 5.索引的工作原理及其种类?
    • 6.连接的种类?
    • 7.数据库范式?
    • 8.数据库优化的思路?
    • 9.存储过程与触发器的区别
    • 10.解释 SQL 的 left join 和 right join?
    • 11.Mysql索引用的是什么算法?
    • 12.Mysql的存储引擎?
    • 13.Mysql事务隔离级别
    • 14.Mysql高可用方案有哪些?
    • 15.Mysql中utf8和utf8mb4区别?
    • 16.Mysql中乐观锁和悲观锁区别?
    • 17.Mysql索引主要是哪些?
    • 18.Mysql联合索引最左匹配原则?
    • 19.聚簇索引和非聚簇索引区别?
    • 20.如何查询一个字段是否命中了索引?
    • 21.Mysql中查询数据什么情况下不会命中索引?
    • 22.Mysql中的MVCC是什么?
    • 23.Mvcc和Redolog和Undolog以及Binlog有什么不同?
    • 24.Mysql读写分离以及主从同步?
    • 25.InnoDB的关键特性?
    • 26.Mysql如何保证一致性和持久性?
    • 27.为什么选择B+树作为索引结构?
    • 28.InnoDB的行锁模式?
    • 29.哈希(hash)比树(tree)更快,索引结构为什么要设计成树型?
    • 30.为什么索引的key长度不能太长?
    • 31.Mysql的数据如何恢复到任意时间点?
    • 32.Mysql为什么加了索引可以加快查询?
    • 33.Explain命令有什么用?

扫码订阅《 》或入驻星球,即可阅读文章!

16.Mysql中乐观锁和悲观锁区别?


GOLANG ROADMAP
Mysql中乐观锁和悲观锁区别?
  • 悲观锁(Pessimistic Lock)

悲观锁顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。

传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。

  • 乐观锁(Optimistic Lock),

乐观锁顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。

乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

乐观锁的特点先进行业务操作,不到万不得已不去拿锁。即“乐观”的认为拿锁多半是会成功的,因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。

乐观锁在数据库上的实现完全是逻辑的,不需要数据库提供特殊的支持。一般的做法是在需要锁的数据上增加一个版本号,或者时间戳,然后按照如下方式实现:

1. SELECT data AS old_data, version AS old_version FROM …;
2. 根据获取的数据进行业务操作,得到new_data和new_version
3. UPDATE SET data = new_data, version = new_version WHERE version = old_version
if (updated row > 0) {
    // 乐观锁获取成功,操作完成
} else {
    // 乐观锁获取失败,回滚并重试
}
1
2
3
4
5
6
7
8

乐观锁是否在事务中其实都是无所谓的,其底层机制是这样:在数据库内部update同一行的时候是不允许并发的,即数据库每次执行一条update语句时会获取被update行的写锁,直到这一行被成功更新后才释放。

因此在业务操作进行前获取需要锁的数据的当前版本号,然后实际更新数据时再次对比版本号确认与之前获取的相同,并更新版本号,即可确认这之间没有发生并发的修改。如果更新失败即可认为老版本的数据已经被并发修改掉而不存在了,此时认为获取锁失败,需要回滚整个业务操作并可根据需要重试整个过程。

两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。

但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。