科普文：软件架构数据库系列之【关系型数据库和非关系型数据库的MVCC实现原理方式梳理】

概叙

科普文：软件架构数据库系列之【MySQL引擎Innodb的MVCC特性】-CSDN博客

前面提到MySQL Innodb引擎的MVCC特性。我们都知道为了避免读写操作在并发时的阻塞问题（一般是写阻塞读），数据库系统都会用MVCC(Multiversion Concurrency Control多版本并发控制)来解决这个问题，而且无论是关系型数据库（Oracle、MySQL、PostgreSQL、SQL Server等），还是NoSQL数据库Mongodb都实现了MVCC。

关系数据库管理系统使用MVCC(Multiversion Concurrency Control多版本并发控制)来避免写操作堵塞读操作的并发问题，MVCC也就是通过使用数据的多个版本保证并发读写不冲突的一种机制。

非关系数据库管理系统MongoDB的MVCC(Multiversion Concurrency Control多版本并发控制)通过“快照”机制实现，允许在不加锁的情况下进行读写操作。在MongoDB中，每个写操作都会创建一个新的文档版本，而读操作会在一个或多个版本之间进行。

MVCC是一种解决读写阻塞的指导思想，不同的数据库有不同的实现，这也是数据库系统让人头疼的地方，关系数据库表面看上去很简单方便，使用标准的SQL语句操作让人很放心，但是随着系统规模增加，并发用户增加，数据库会出现性能降低的现象，这时我们可能需要从外部的微调进入到内部原理的深入研究，而每个数据库内部实现并发的原理都是不同的，如果我们拥有多个不同的数据库，那么需要不同的调校方法，这时作为生产系统的核心数据库开始变得不那么让人放心，本文提供了市面上几种流行数据库的内部MVCC不同的实现。

MVCC的两种不同实现方式

　　第一种实现方式是将数据记录的多个版本保存在数据库中，当这些不同版本数据不再需要时，垃圾收集器回收这些记录。这个方式被PostgreSQL和Firebird/Interbase采用，SQL Server使用的类似机制，所不同的是旧版本数据不是保存在数据库中，而保存在不同于主数据库的另外一个数据库tempdb中/

　　第二种实现方式只在数据库保存最新版本的数据，但是会在使用undo时动态重构旧版本数据，这种方式被Oracle和MySQL/InnoDB使用。

关系型数据库实现MVCC

MVCC： 即多版本并发控制，主要是为了提高数据库的读写性能，让数据库在读写的时候不用去加锁。mvcc 主要是处理读请求，这个读指的是快照读，而不是当前读，快照读就是普通的 select 查询。而当前读，其实就是一种悲观锁，要靠加锁实现，比如我们执行 update 或 delete 的时候，你需要先把数据读出来，然后再进行修改操作。比如 select xx for update, 这种排他锁，还有 select xxx lock in share mode 共享锁，这种加锁的方式就是当前读，是需要用锁来保证数据的强一致性。快照读是用 mvcc 实现的，他的目的是读写数据行的时候，不用去竞争锁，提升数据库的并发性能。

数据库的事务有 acid 的特性，原子性用 undo log 实现，持久性是 redo log，而隔离性则是通过加锁和 mvcc 实现。 mysql 事务有 4 中隔离级别: 读未提交，读已提交，可重复读，串行化。一般常用的是读已提交，可重复读这两种。读已提交，可重复读 他们的快照读都是基于 mvcc 实现的。

MVCC常见的几个概念：

（1）undo log
（2）版本链（隐藏字段）
id = 1 这条记录，经过了多次修改。 修改的历史版本都保存在了 undo log 里。数据库里的每行记录实际上包含一个回滚指针 ( 这是一个隐藏字段 )，指向上一个版本记录，如果你想得到 name=”张三“ 的记录，需要通过版本链多次回滚才行。
（3）Readview 可见性
readview 其实就是一次快照（相当于python 的 一个 class 对象），但是有个问题，当查询 select id=1 的时候，我应该读哪个版本呢，难道总是读最新吗？ readview 的作用就是让你知道，你要选择读哪个快照版本。
readview 有一些参数：
m_ids: 表示在生成 Readview 时当前系统中活跃（指还未commit 的事务）的读写事务的 事务id 列表。
min_trx_id: 表示在生成 readview 时当前系统中活跃的读写事务最小的 事务id，也就是 m_ids 中最小的值。
max_trx_id: 表示生成 readview 时系统中应该分配下一个事务的 id 值。
create_trx_id: 表示生成 readview 的事务的 事务id。也就是谁生成了这个 readview。（我自己的事务 id。相当于是 自己记录自己。 ）
eg：当前实例中 show proceeelist 查看活跃的事务列表是 m_ids = [2，3，4, 5] ，那么 min_trx_id=2，max_trx_id=6。
readview 视图如何判断版本链中的哪个版本可用呢？他有4 种判断逻辑

【1】trx_id == create_trx_id： 可以访问这个版本; # trx_id 指的就是如下图中的每条记录的事务 ID。 trx_id == create_trx_id 意味着，这条记录是我自己本身（当前 session）生成的事务（readview），我读取我自己创建的这条记录，当然是可读的。别人不可读是为了阻塞，我自己不可能阻塞我自己，没有意义。
【2】trx_id < min_trx_id：可以访问这个版本。说明，我这个 trx_id 就不是一个活跃的 id ，他已经commit 了 。
【3】trx_id > max_trx_id: 不可以访问这个版本。因为 该 readview 还没有生成。
【4】min_trx_id <= trx_id <= max_trx_id : 如果 trx_id 在 m_ids 中，那么是不可以访问这个版本的，在 m_ids 列表里 说明当前事务是活跃事务。

MVCC 是针对 RC 和 RR 隔离级别的：

RC 和 RR 级别 本质的区别是他俩 生成 readview 的时机不同：
【1】RC 中 以每个 select 的查询为单位（update, delete 的查询也算），每次 select 都会生成一个新的 readview，如果一个事务执行的过程中执行了多次 select，那么事务执行的过程中就要生成多个 readview 。本质是一个事务生成了多了 readview 。 RC 有不可重复读的问题。
【2】RR 生成 readview 是以事务为单位的。比如一个事务有三个 select 语句，但是只会生成一个 readview，后面两个 select 使用的 readview 和 第一个一样，他不会再继续生成 readview，所以在可重复读级别下， readview 是以事务为级别的 ，一个事务只会生成一个 readview。RR 级别就是用这个方法解决了不可重复读的问题。

Eg: 我现在开启了一个事务，包含了两个 select 动作，在执行第一个 select 的时候生成了这个 readview，第一个 select 查询到的是 name=“张三”，那么就算另一个 session 的 update 事务 commit 了，我这个事务的第二个 select 查询用到的依然是 第一个 select 的 readview name = “张三”，第一次生成的 readview 是什么样，之后的这个 readview 就是什么样，直到我这个事务执行完毕。 RR 虽然解决了不可重复的问题，但还是存在 幻读的问题，所以要加锁（ 间隙锁 + next key lock ）解决幻读的问题。 幻读只是在 RR 级别才会出现的。

我们知道 快照读是通过 mvcc 实现的，当前读都是通过加锁实现的：快照读是如何解决幻读的问题呢？
RR 级别因为事务开始的时候只会生成一分 readview，那么外界再怎么对这个数据进行增加，都对我这个readview 视图没有影响，我读的还是我第一次生成的视图，外部的数据再怎么更新，新增，对于我这个视图都没有影响，这种方式解决了幻读的问题。
当前读是通过 间隙锁 + next key lock 实现，间隙锁是锁住了一段范围。RR 级别默认开启了间隙锁。

下面看看具体数据库实现机制。

PostgreSQL的MVCC

　　在PostgreSQL中，当一行记录被更新时，该行数据的新版本(称为tuple)将被创建并插入表中，之前版本提供一个指针指向新版本，之前版本被标记为"expired"过期，但是还保留在数据库直到垃圾收集器回收掉。

为了支持多版本，每个tuple有以下附加数据记录：

• xmin – 插入更新记录和创建这个tuple的事务的ID
• xmax – 删除记录或创建这个tuple新版本或删除记录的事务。这个字段初始是null.

事务状态是保存在 $Data/pg_clog的CLOG中. 这个表包含每个事务状态信息的两个字节，可能的状态有in-progress, committed, 或  aborted。 当一个事务结束后，PostgreSQL并不会将数据库记录的改变undo回滚的，它只是在CLOG标记事务为aborted . 一个PostgreSQL表可能包含许多这样aborted退出事务的数据。

一个称为Vacuum 清理流程会提供expired过期/aborted退出的记录版本的垃圾回收，Vacuum 清理器也会删除被垃圾回收的tuple相关的索引项。

一个tuple的xmin是有效且xmax无效时，它是可见的。 “Valid有效” 意味着 “或者是 committed 或代表当前事务”. 为了避免反复操作CLOG 表, PostgreSQL 在tuple中维持状态标识，以表示tuple是否是“known committed” 或 “known aborted”.

Oracle的MVCC

　　Oracle是在回滚段(也就是‘undo log’)中保存旧版本， 一个事务ID并不是一个顺序数字，而是由一系列数字组成，这些数字指向回滚段的头部事务槽 (slot)。 回滚段能让新事务能重用存储，重用被已经提交或退出的旧事务使用过的事务槽，这种自动重用机制使得Oracle使用有限的回滚段可以管理大量的事务。

回滚段的头部块是用作一个事务表，这里保存着事务的状态，称为System Change Number或 SCN, Oracle并不是存储页面中的每个记录的事务ID， 而是通过保存页面中每行记录的唯一事务ID的数组阵列节约空间使用， 只保存记录的数组偏移量offset，和每个事务ID保存在一起的是一个指针，指向该页事务创建的最后undo记录，不仅表记录是这种方式存储，索引记录也是使用同样技术，这是Oracle和PostgreSQL主要区别之一.

当一个Oracle事务启动时，它会标记一个当前事务状态SCN. 当读取一个表或一个索引页时，Oracle使用SCN数字来决定该页是否包含不应该让当前事务知晓的事务影响效果， Oracle通过寻找相联的回滚段头部来检查该事务的状态，但是为了节约时间，第一次是真正查询事务，查询完成它的状态会被记录在该页中以避免后来再次查询，如果该页被发现包含不可见事务的影响，Oracle通过undoing每个这样的事务影响来重新创建该页的旧版本。它扫描和每个事务有关的记录，将这些事务效果应用到该页，直至那些所有事务效果应用完成后被移除，以该方式创建的新页再用于访问其中的tuple。

Oracle中的记录头：
一个记录头部不会增长，总是有固定大小，对于非集群的表，记录头部是3个字节，一个字节被用于存储标识，一个字节用于显示记录是否被锁住(比如它被更新了但是没有确认提交committed), ，一个字节用于列计数。

MySQL的MVCC

科普文：软件架构数据库系列之【MySQL引擎Innodb的MVCC特性】-CSDN博客

SQL Server的MVCC

　　在SQL Server数据库内部使用记录版本实现快照隔离和读取提交，只有需要此项的数据库才会必须开启并且会产生相应的成本开销。

当一个记录被修改或删除时，使用copy-on-write机制能够有效地启动版本，Row versioning–based 事务能够有效地“view看到” 数据的从过去到现在的的前后一致的各种版本。

记录版本Row version保存在版本存储中，其驻留在主数据库之外的tempdb数据库中，  更特别地，当一张表或索引中一个记录被修改，新记录将携带上执行修改的事务的 ”sequence_number”. 记录的旧版本将被拷贝到版本存储中, 新记录包含一个指针指向版本存储中的这个旧记录，如果多个长运行 long-running事务存在，并且需要多个 ”版本versions”, 在版本存储中的记录也许包含指向该记录更早版本的指针。

SQL Server的版本存储清除：
SQL Server自动管理版本存储的大小，维持一个清除线程来确保版本存储中记录版本数量不至于太长，超过需要，对于在快照隔离下运行的查询，版本存储保留记录版本直到修改数据的事务完成，并且事务包含的任何需要修改数据的语句全部完成，对于在Read Committed 快照隔离下运行的SELECT语句 ，一个特别的记录版本就再也不需要了，一旦SELECT语句执行完成就被移除。

如果tempdb已经没有空闲空间， SQL Server会调用清除功能，增加文件的大小，当然前提是假设我们配置文件是自动增长的，  如果磁盘已经没有空间，文件不能自动增长， SQL Server会停止产生版本，如果这种情况发生，任何需要读取版本的快照查询因为空间限制将失败。

SQL Server中记录头
4 字节
- 两字节记录元数据(记录类型)
- 两字节向前指向记录中的NULL 位图bitmap. 这是记录(固定长度列)实际大小的差值offset.

版本标记Versioning tag – 这是一个14-byte结构，包含时间戳加一个指向tempdb中版本存储的指针，这里时间戳是 trasaction_seq_number, 当需要支持一个版本操作时，加入版本信息到记录中时的时间。

下图是各个数据库的对比总结：

 

非关系型数据库实现MVCC 

MongoDB的MVCC

在MongoDB4.0中， 不管有没有显式地调用一个事务， CRUD操作都会默认地给这些操作创建一个事务， 这是通过WriteUnitOfWork来实现的。WriteUnitOfWork类是一个wrapper类只是设定和取消一些标记， 真正的实现是在WiredTigerRecoveryUnit里面实现的, 它封装了server端的事务的使用。
在CRUD下， 都需要通过一个key记过cursor找到btree里面相应的内存页上面的KV值， 这里的cursor需要先通过recover unit得到相应的wiredtiger session类, 此时recover unit会创建一个新的事务并且指定该事务的read_timestamp。

WiredTigerRecoveryUnit::_txnOpen()主要是用来打开一个新的事务， 并且指定该事务的read_timestamp， 默认情况下， 这个时间点是没有设定的， 该如何告诉wiredtiger层从那个snapshot里面读取哪？
在MongoDB里面， 可以通过指定ReadSource来实现。ReadSource可以有如下的选择：

MongoDB的多版本并发控制（MVCC）通过“快照”机制实现，允许在不加锁的情况下进行读写操作。在MongoDB中，每个写操作都会创建一个新的文档版本，而读操作会在一个或多个版本之间进行。

MVCC在MongoDB中的工作方式如下：

1. 写操作：当插入或更新文档时，MongoDB会创建一个新版本的文档，并保留旧版本的文档，以便支持并发读取。

2. 读操作：查询可以在多个版本之间进行，MongoDB会根据读操作开始时的数据视图提供一致的结果。

3. 删除操作：删除操作会标记文档为删除，而不是立即删除文档。

MongoDB的MVCC通过以下机制实现：

• 时间戳：每个文档都有一个_id字段，其中包含一个时间戳，表示文档版本的创建时间。

• 标记删除：删除操作不会立即删除文档，而是标记文档为删除状态，在后台清理标记为删除的文档。

由于MongoDB的MVCC实现细节在内核级别进行，因此并没有公开的API来直接管理MVCC。不过，开发者可以通过正常的读写操作来利用这个机制，确保数据的并发一致性。