前言
大家对 乐观锁 这三个字眼应该不陌生吧？
为什么今天我想谈谈乐观锁的设计呢？
关于数据库的乐观锁使用， 是不是很多人一看到乐观锁就会想到 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}
只要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 无锁算法 大家了解过么？
可以去了解下，再回来 看看 文中说的 数据库里乐观锁的设计思想。
该篇浅谈就到这，神神叨叨习惯了，说的东西可能没营养可能有营养，就到这吧。
