MVCC

MVCC 是一种多版本并发控制机制，它使得大部分支持行锁的事务引擎，不再单纯的使用行锁来进行数据库的并发控制，取而代之的是把数据库的行锁与行的多个版本结合起来，只需要很小的开销,就可以实现非锁定读，从而大大提高数据库系统的并发性能。MVCC 主要是为 Repeatable-Read 事务隔离级别做的。在此隔离级别下，A、B 事务所示的数据相互隔离，互相更新不可见。

为了实现可串行化，同时避免锁机制存在的各种问题，我们可以采用基于多版本并发控制（Multiversion concurrency control，MVCC）思想的无锁事务机制。人们一般把基于锁的并发控制机制称成为悲观机制，而把 MVCC 机制称为乐观机制。这是因为锁机制是一种预防性的，读会阻塞写，写也会阻塞读，当锁定粒度较大，时间较长时并发性能就不会太好；而 MVCC 是一种后验性的，读不阻塞写，写也不阻塞读，等到提交的时候才检验是否有冲突，由于没有锁，所以读写不会相互阻塞，从而大大提升了并发性能。我们可以借用源代码版本控制来理解 MVCC，每个人都可以自由地阅读和修改本地的代码，相互之间不会阻塞，只在提交的时候版本控制器会检查冲突，并提示 merge。目前，Oracle、PostgreSQL 和 MySQL 都已支持基于 MVCC 的并发机制，但具体实现各有不同。

MVCC 的一种简单实现是基于 CAS（Compare-and-swap）思想的有条件更新（Conditional Update）。普通的 update 参数只包含了一个 keyValueSet’，Conditional Update 在此基础上加上了一组更新条件 conditionSet { … data[keyx]=valuex, … }，即只有在 D 满足更新条件的情况下才将数据更新为 keyValueSet’；否则，返回错误信息。这样，L 就形成了如下图所示的 Try/Conditional Update/(Try again) 的处理模式：

对于常见的修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个 version 字段，当前值为 1；而当前帐户余额字段(balance)为 100。

• 操作员 A 此时将其读出（version=1），并从其帐户余额中扣除 50 (100-50)。

• 在操作员 A 操作的过程中，操作员 B 也读入此用户信息（version=1），并从其帐户余额中扣除 20（100-20）。

• 操作员 A 完成了修改工作，将数据版本号加一（version=2），连同帐户扣除后余额（balance=50），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2。

• 操作员 B 完成了操作，也将版本号加一（version=2）试图向数据库提交数据（balance=80），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2，数据库记录当前版本也为 2，不满足提交版本必须大于记录当前版本才能执行更新的乐观锁策略，因此，操作员 B 的提交被驳回。这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员 A 的操作结果的可能。

从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销(操作员 A 和操作员 B 操作过程中，都没有对数据库数据加锁)，大大提升了大并发量下的系统整体性能表现。需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。