undo log实现事务的原子性以及MVCC解析

undo log实现事务的原子性以及MVCC解析

事务并发带来的问题

事务并发往往会带来一些不可预知的问题，一般可以包括**「脏读」、「幻读」、「不可重复读」和「丢失更新」**。

脏读

脏读是指事务A未提交的数据被事务B读取，事务A回滚，事务B读到的数据是脏数据。

幻读

幻读是指事务A查询一次数据后，事务B增加或减少了几条数据，事务A再次查询发现和之前查到的数据条数不一致，就好像出现了幻觉一样。

不可重复读

不可重复读是事务A两次查询期间事务B修改了数据，导致事务A两次读取的数据不一致。

丢失更新

丢失更新指的是事务A和事务B同时写一个数据，那么先写的更新就会丢失，还有一种情况是两个事务同时更新一条数据，某一事务回滚导致另一事务的更新也丢失。

事务隔离级别

事务有四种隔离级别，由低到高分别是**「读未提交」、「读已提交」、「可重复读」和「可串行化」**。

• 读未提交(READ UNCOMMITTED)：读未提交是最低的隔离级别，不同事务之间可以读取未提交的数据，因此可能产生脏读、不可重复读和幻读。

• 读已提交(READ COMMITTED)：读已提交的级别略高于读未提交，事务之间只能读取已经提交的数据，可能产生不可重复读和幻读的问题。

• 可重复读(REPEATABLE READ)：可重复读对同一字段多次读取的结果一致，可以防止脏读和不可重复读，但还是会产生幻读的问题。

• 可串行化(SERIALIZABLE)：可串行化是最高级别的事务隔离级别，是完全串行化执行事务，可以有效防止幻读、不可重复读和脏读。

MVCC

mvcc是什么

MVCC (MultiVersion Concurrency Control) 叫做多版本并发控制。理解为：事务对数据库的任何修改的提交都不会直接覆盖之前的数据，而是产生一个新的版本与老版本共存，使得读取时可以完全不加锁。

有点抽象是吗，再来详细解释一下。同一行数据会有多个版本，某事务对该数据的修改并不会直接覆盖老版本，而是产生一个新版本和老版共存。然后在该行追加两个虚拟的列，列就是进行数据操作的事务的ID（created_by_txn_id），是一个单调递增的ID；还有一个deleted_by_txn_id，将来用来做删除的。

那么在另一个事务在读取该行数据时，由具体的隔离级别来控制到底读取该行的哪个版本。同时，在读取过程中完全不加锁，除非用select * xxx for update强行加锁。

譬如read committed级别，每次读取，总是取事务ID最大的那个就好了。

对于Repeatable read，每次读取时，总是取事务ID小于等于当前事务的ID的那些数据记录。在这个范围内，如果某一数据有多个版本，则取最新的。

MVCC在mysql中的实现依赖的是undo log与read view

undo log记录某行数据的多个版本的数据；read view用来判断当前版本数据的可见性。

mysql就是用MVCC来实现读写分离不加锁的。

那么MVCC里多出来的那些版本的数据最终是要删除的，支持MVCC的数据库套路一般差不多，都会有一个后台线程来定时清理那些肯定没用的数据。只要一个数据的deleted_by_txn_id不为空，并且比当前还没结束的事务ID最小的一个还小，该数据就可以被清理掉了。在PostgreSQL中，该清理任务叫“vacuum”，在Innodb中，叫做“purge”。

隔离级别

隔离级别目的很明确，管理多个并发读写请求的访问顺序，包括串行和并行，要在并发性能和读取数据的正确性上做个权衡。

其中的两个隔离级别Serializable和 Read Uncommited几乎用不上，这里不谈。

Read Committed

能读到其他事务已提交的内容，这是Springboot默认的隔离级别。一个事务在他提交之前的所有修改，对其他事务不可见。提交后，其他事务就能读到了。在很多场景下这种逻辑是可以接受的。

在这个隔离级别下，读取数据不加锁而是使用MVCC机制，读取版本号最高的就行了，写入数据就是排他锁。该级别会产生不可重复读和幻读问题。

不可重复读就是在一个事务内多次读取的结果不一样，这个很容易理解，上面讲MVCC时也说了，该级别每次select时都会去读取最新的版本，所以同一个事务内，也就是代码前面一行select了，后面又select了，可能会select到不同的值。因为这两次select过程中，有其他事务对select的行进行了事务提交，就会被select出来最新的。

幻读，即一个事务能够读取到插入的新数据。会出现幻读也是一样的道理，第一次select时还没值，再次select时又有值了。

Repeatable Read

这个级别名字就是可重复读，这是mysql默认的隔离级别。

为什么能重复读，前面讲MVCC时也说了，这个级别下，一旦读到某个版本，后续都是这个版本了，好比是一次快照，就不关心其他事务对该行数据的提交了，它只认第一次读取时的版本号。

这个级别在一些场景下很重要，如

 数据备份：
         例如数据库S从数据库M中复制数据，但是M又不停的在修改数据。S需要拿到M的一个数据快照，但又不能停M。
 数据合法性校验：
         例如有两张表，一张记录了当时的交易总额，另一张记录了每个交易的金额。那么在读取数据时，如果没有快照的存在，交易总额就可能和当时的交易总额对不上。

该级别依然会出现幻读的问题，repeatable是可以出现幻读的，一个事务虽然不能读取其他事务对现有数据的修改，但是能够读取到插入的新数据。

即便是MVCC也解决不了幻读的问题，这里有一篇讲的原因。

写前提困境

尽管在MVCC的加持下Read Committed和Repeatable Read都可以得到很好的实现。但是对于某些业务代码来讲，在当前事务中看到/看不到其他的事务已经提交的修改的意义不是很大。这种业务代码一般是这样的：

先读取一段现有的数据

在这个数据的基础上做逻辑判断或者计算；

将计算的结果写回数据库。

这样第三步的写入就会依赖第一步的读取。但是在1和3之间，不管业务代码离得有多近，都无法避免其他事务的并发修改。换句话说，步骤1的数据正确是步骤3能够在业务上正确的前提，这样其实与MVCC都没什么关系了，因为我们想象中的要操作的数据和实际值并不一样，无论怎么步骤3的结果其实都不对了。

无论你用哪种隔离，你都无法解决第一步读取的数据和第三步操作之间，别的事务对它的修改。

解决方法：

结论

虽然上面写了很多，也很复杂，貌似不上锁怎么都难以解决写前提困境。而事实上，我们几乎不用考虑这样的场景，极少有可能说多个客户端同时操作同一条数据，又刚好碰上需要抉择read committed还是Repeatable read的困境。

结论很简单，不管他就好，你几乎没机会碰到这样的选择困境。