MySQL中乐观锁实现(mvcc)
现在我们简单聊一下数据库中的悲观锁和乐观锁。
悲观锁
悲观锁正如其名称，比较悲观。总会认为：每当修改数据时，会有其他线程也会同时修改该数据。所以针对这种情况悲观锁的做法是：读取数据之后就加锁(eg: select…for update)，这样别的线程读取该数据的时候就需要等待当前线程释放锁，获得到锁的线程才能获得该数据的读写权限。从而保证了并发修改数据错误的问题。但是由于阻塞原因，所以导致吞吐量不高。悲观锁更适用于多写少读的情况。
场景: 同学A和同学B都要给你转500块钱(开心坏了吧，这样最终你能得到1000块钱)。
使用悲观锁的流程:
- 同学A获取到你的账户余额
balance = 0并对该条记录加锁。 - 同学B获取你的账户余额。由于同学A已经对这条记录加锁了，所以同学B需要等同学A转帐完成(释放锁)才能获得余额。
- 同学A转账完成并释放锁，此时你的账户余额
balance=balance + 500 = 500 - 同学B获取到你的账户余额
balance = 500，并对该条记录加锁(如果你人缘好，此时同学C给你转账也是需要等待同学B转账完成才可以转账哦) - 同学B转账完成并释放锁(如果有同学C想给你转账，此时同学C就可以获得锁并转账了)。此时你的账户余额为
balance = balance + 500 = 1000 - 最终你开开心心的得到了1000块钱。
假设转账过程没有锁，我们看看会发生什么:
- 同学A获取到你的账户余额
balance_a = 0(没有加锁，此时同学B也可以获取到账户余额) - 同学B获取到你的账户余额
balance_b = 0 - 同学A转账完成，此时你的账户余额为
balance = balance_a + 500 = 500 - 同学B转账完成，此时你的账户余额为
balance = balance_b + 500 = 500 - 最终同学A和同学B都转了500，但是你最终只获得了500。这一定是不能接受的吧。
丢失的500块去哪里了呢？从第2步可以看到同学B获取到的账户余额是0，而不是同学A转帐之后的余额500。所以问题出在这里，这是高并发场景的常见问题。所以加锁是非常必须的。但是加了悲观锁，同学都要排队给我转账，对于没有耐心的同学就直接不转帐了，我岂不是错失了发财的好机会。那有什么好办法呢？答案就是下面的乐观锁。
悲观锁的实现
在 MySQL 中一般指排他锁，当事务在操作数据时将这部分数据进行锁定，直到操作完毕后再解锁，解锁后才能够由其它事务操作该部分数据。
MySQL 中的悲观锁大部分情况下依赖数据库的锁机制实现，一般使用 SELECT … FOR UPDATE 对选择的数据进行加锁处理，例如：
1 | //悲观锁查询 |
这条 SQL 语句锁定了 account 表中所有符合检索条件（name=”MAX”）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。
乐观锁
乐观锁顾名思义比较乐观，他只有在更新数据的时候才会检查这条数据是否被其他线程更新了(这点与悲观锁一样，悲观锁是在读取数据的时候就加锁了)。如果更新数据时，发现这条数据被其他线程更新了，则此次更新失败。如果数据未被其他线程更新，则更新成功。由于乐观锁没有了锁等待，提高了吞吐量，所以乐观锁适合多读少写的场景。
常见的乐观锁实现方式是：版本号version和CAS(compare and swap)。此处只介绍版本号方式。
要采用版本号，首先需要在数据库表中新增一个字段version，表示此条记录的更新版本，记录每变动一次，版本号加1。依旧使用上面转账的例子说明：
- 同学A获取到你的账户余额
balance = 0和版本号version_a = 0 - 同学B获取到你的账户余额
balance = 0和版本号version_b = 0 - 同学A转账完成
update table set balance = ${balance}, version = version + 1 and version = 0。(此时版本号为0，所以更新成功) - 同学B转账完成
update table set balance = ${balance}, version = version + 1 and version = 0。(此时版本号为1，所以更新失败，更新失败之后同学B再转一次即可) - 同学B重新转帐之后，你还是美滋滋的获得了1000。
乐观锁的实现
乐观锁相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以数据进行提交更新的时候，才会对数据是否冲突进行检测，如果冲突了，就返回用户错误的信息，让用户决定如何去做。一般都是使用版本号机制来实现 MySQL 数据库中的乐观锁。
版本号的实现方式有两种，一个是数据版本机制，一个是时间戳机制。
数据版本实现乐观锁
使用数据版本机制实现是 MySQL 乐观锁实现的最常用的方式，何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 version 字段来实现。当读取数据时，将 version 字段的值一同读出，数据每更新一次，对 version 的值加 1。当我们提交更新时，判断数据库表对应的当前版本信息与第一次取出来的 version 值进行比对，如果数据库表当前版本号与第一次取出来的 version 值相等，则予以更新，否则认为是过期数据。
如上图所示，如果更新操作顺序执行，则数据的版本（version）依次递增，不会产生冲突。但是如果有发生不同的业务操作对同一版本的数据进行修改，那么先提交的操作（图中 B）会把数据 version 更新为 2，当 A 在 B 之后提交更新时发现数据的 version 已经被淘汰了，那么 A 的更新操作就会失败。
时间戳机制实现乐观锁
使用时间戳机制实现乐观锁原理类似，同样是在需要乐观锁控制的 table 中增加一个字段，名称无所谓，字段类型时间 timestamp，和上面的 version 类似，也是在更新提交时检查当前数据库中的时间戳和自己更新前提取到的时间戳进行对比，如果一致则 OK，否则就是版本冲突。
MVCC是解决了什么问题
众所周知，在MYSQL中，MyISAM使用的是表锁，InnoDB使用的是行锁。而InnoDB的事务分为四个隔离级别，其中默认的隔离级别REPEATABLE READ需要两个不同的事务相互之间不能影响，而且还能支持并发，这点悲观锁是达不到的，所以REPEATABLE READ采用的就是乐观锁，而乐观锁的实现采用的就是MVCC。正是因为有了MVCC，才造就了InnoDB强大的事务处理能力。
总结
悲观锁：读取时加锁，更新完释放锁，在此过程中会造成其他线程阻塞，导致吞吐量低，适用于多写场景。
乐观锁：不加锁，只有在更新时验证数据是否被其他线程更新，吞吐量较高，适用于多读场景。
