浅谈乐观锁的设计

港控/mmm° 2022-12-15 11:26 113阅读 0赞

# **前言** #

大家对 乐观锁  这三个字眼应该不陌生吧？

为什么今天我想谈谈乐观锁的设计呢？

关于数据库的乐观锁使用， 是不是很多人一看到乐观锁就会想到  Version 字段 （版本标识）。

*ps: 其实不是非要新增版本字段*

# **正文** #

乐观锁 ， Optimistic Concurrency Control （乐观并发控制），简称 OCC 。

乐观锁不是一种真正的 ‘ 锁 ’，而是一种实现锁效果的 设计思想：

乐观地 认为 并发的操作对数据 不会产生冲突，所以没有使用 真正的 ‘锁’ 去对数据加锁；

而是选择在提交数据的时候，去检测数据是否冲突了？

发现冲突就采取 处理操作，例如报错、重试、停止等等。

### **设计** ###

基于数据库使用展开介绍

### **  使用版本标识  version 字段** ###

也就是在 表内 增加一个字段  version 。

每次写操作如果时成功的，都需要 将 version 版本值 +1 ，

例如原来 某条数据的 version值为  1， 如果修改了，那么 version就需要变成 version+ 1   ， 也就是 2.

然而在并发场景，大量的写操作不免会发生冲突。

所以当我们 读取 数据 且 需要做更新操作时。 我们的 设计流程时这样的：

1. 读取数据，把数据里的version值 取出作为  更新前标识 值  version-before。

2.做业务逻辑计算等等 ....

3. 更新数据操作 ，更新时， 将之前的 标识 值    version-before 与 数据库里面的  version值  做匹对， 检测是否一致。

**如果一致**， 那么意味着 这时段内，没有其他写操作修改过数据， 那么我们可以提交成功。

**如果不一致**，那么意味着 发生了写写冲突， 也就是我们此刻需要更新的数据，已经被修改过了。那么我们可以根据业务场景，采取处理措施 （报错记录、重试流程、停止等等）。

ps： 注意了，这里的读取，检测，更新  这些操作都是务必保证 **操作的原子性 **，连贯执行，也就是处于同个事务内。

mysql语句的写法举例：

update proinfo  set proNum = proNum + 10 , version = version + 1 where version = \#\{version\} and proId = \#\{proId\}

![20201016151922232.png][]

只要where 后的 version 条件不成立，那么就是更新不成功，也就是 检测到了 ‘冲突’  。

那么前言里，我提到 使用乐观锁，不一定非要新增版本 version字段。

我们还可以使用 updateTimestamp  这种字段值。

我想，大家接触过很多项目，是不是看到很多老项目的表内都会有个 更新时间（时间戳）的字段，

但是好像业务里又没有用。

其实，这种字段，可以用来实现 乐观锁。

精确到毫秒或者更细， 每次操作，读取数据前把 时间戳的值 保存，然后更新提交的时候， 将这时间戳和数据库内的时间戳 值做匹对，原理也是一样的。时间戳字段可以自己传入，也可以是通过mysql函数默认获取更新。

update proinfo set proNum = proNum + 10 , updateTimestamp = unix\_timestamp(now())                                                        where  updateTimestamp = \#\{updateTimestamp\} and  proId = \#\{proId\}

（可能有人会反驳，如果时间戳一模一样呢？ 我不多说、）

为什么需要提这个呢。 因为我想传达的是， 乐观锁，要理解这种 乐观控制的设计思想，灵活去运用。

而不是固化，看到千篇一律地加字段 version，就跟着加。

有时候有些老项目，不是说加个字段那么回事，也许会引发一些杂七杂八的问题。

那么我们大可去根据实际情况去设计乐观锁。

那么最后也简单地说下这个数据库使用乐观锁设计，

1.最好是 读多写少的场景下使用，因为写的操作少了，也就更乐观了。

2. 在发现冲突时， 咱们的处理操作要慎重设计， 特别是写操作并发特别多的情况，采取 无限制地重试？ 短时间会不会适得其反？

思想很重要，不是只顾着去套模式，因为掌握了这种思想，也许你不单单在使用乐观锁的时候你才用得上。

最后给大家留个小话题， CAS 无锁算法 大家了解过么？

可以去了解下，再回来 看看 文中说的 数据库里乐观锁的设计思想。

该篇浅谈就到这，神神叨叨习惯了，说的东西可能没营养可能有营养，就到这吧。

[20201016151922232.png]: /images/20221123/5b404fc52eee4b44a79dcb9c95af7ab2.png

发表评论取消回复

表情：

评论列表（有 0 条评论，113人围观）

还没有评论，来说两句吧...

相关阅读

相关浅谈 Java 并发下的乐观锁

引子各位少侠大家好！今天我们来聊聊 Java 并发下的乐观锁。在聊乐观锁之前，先给大家复习一个概念：原子操作：什么是原子操作呢？我们知道，原子（atom）指

淡淡的烟草味﹌/ 2023年01月03日 12:43/ 0 赞/ 191 阅读

相关浅谈Mysql共享锁、排他锁、悲观锁、乐观锁及其使用场景

转载自:[浅谈Mysql共享锁、排他锁、悲观锁、乐观锁及其使用场景][Mysql] Mysql共享锁、排他锁、悲观锁、乐观锁及其使用场景一、相关名词 |–表级锁（锁定整

墨蓝/ 2022年12月24日 09:59/ 0 赞/ 100 阅读

相关浅谈乐观锁的设计

前言大家对乐观锁这三个字眼应该不陌生吧？为什么今天我想谈谈乐观锁的设计呢？关于数据库的乐观锁使用，是不是很多人一看到乐观锁就会想到 Version

港控/mmm°/ 2022年12月15日 11:26/ 0 赞/ 114 阅读

相关原生锁Synchronized ，浅谈乐观锁与悲观锁

一、JVM对原生锁的优化自旋：一种优化是使用自旋锁，即在把线程进行阻塞操作之前先让线程自旋等待一段时间，可能在等待期间其他线程已经解锁，这时就无需再让线程执行阻塞操作，

梦里梦外;/ 2022年11月26日 04:58/ 0 赞/ 140 阅读

相关浅谈死锁

死锁：两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。 1、死锁的四个必要条件： ①　互斥条件在一段时

逃离我推掉我的手/ 2022年07月03日 14:54/ 0 赞/ 137 阅读

相关浅谈数据库锁机制

1、MYSQL锁类型 1) 共享锁共享锁的代号是S，共享锁的锁粒度是行或元组（多个行）。一个事务获取了共享锁之后，可以对锁定范围内的数据执行读操作。 2) 排它

约定不等于承诺〃/ 2022年07月03日 14:28/ 0 赞/ 184 阅读

相关浅谈死锁

什么死锁：是两个或者两个以上的进程由于竞争资源而造成的的一种相互等待的线性，如无外力作用，这些进程将永远不能再向前推进。陷入死锁状态的进程称为死锁进程，所占用的资源

蔚落/ 2022年06月14日 02:43/ 0 赞/ 248 阅读

相关浅谈乐观锁和悲观锁的机制

乐观锁： 1. 乐观锁是一种思想，具体实现是，表中有一个版本字段，第一次读的时候，获取到这个字段。处理完业务逻辑开始更新的时候，需要再次查看该字段的值是否和第一次的一样。如

女爷i/ 2022年06月01日 12:08/ 0 赞/ 179 阅读

相关浅谈死锁

　　说起死锁，首先我们就要知道死锁是怎么形成的。比如：两个工作进程在工作中都被阻塞，双方都希望对方能释放自己所需要的资源，但是因为无法获得相应的资源继续运行，从而也无法释放自己

╰+哭是因爲堅強的太久メ/ 2022年05月22日 00:19/ 0 赞/ 160 阅读

相关浅谈Mysql共享锁、排他锁、悲观锁、乐观锁及其使用场景

转自：https://blog.csdn.net/localhost01/article/details/78720727 Mysql共享锁、排他锁、悲观锁、乐观锁及其使用

谁践踏了优雅/ 2022年04月24日 14:52/ 0 赞/ 161 阅读