MVCC(H2、Inoodb，CopyOnWrite, Clojure)

之前，研究H2源码的时候，重点了解了一下MvStore。结合它的文档和Inoodb的实现，发现它叫MVCC(Multi-Version Concurrency Control)，即多版本控制，同时它也叫乐观锁。后面发现它的理念在Java的CopyOnWriteList，Clojure的标识与状态分离，惊奇地发现它似乎无处不在，于是，试着对此进行总结。

相对这些名词“乐观锁”比较合其神，所谓乐观，与“悲观锁”对应。它们都是针对并发问题提出的。试想如果小D有一份文件，同时有任意个人同时去读它是没有问题的。他们可以围着一起看。但是要同时写呢？那就只能一个一个来写，于是就有了锁。普通的锁也叫“悲观锁”，大意是当需要去写这个文件时，其他人只能候着，也就是连看都不能看。这很讨厌，其他的人可能只想同时瞅一眼，但要采取这种策略只能候着。那能不能改呢？小D想了一种方法，就是给一份大家看，给另一份供人写，写的人也只能一个一个写，但是大家同时是可以看了。当有人去写好时，就把这份文件复制一份替换原来那份给人看的文件。这就是所谓的CopyOnWrite，也就是写了之后就复制。Java的CopyOnWriteList就是这样的思想。那么是不是还可以改进，可以更乐观点呢，于是小D想，干脆谁想用每人打印一份算了。这样你写自己在自己文件上写，这样每个文件就是一个版本，出现了多个版本，但这时又有问题了，文件只允许一个版本是有效的，于是，小D想了个办法，设置了一个东西叫版本号。开始是0，大家打印的都是0。有人修改之后，提交成功就变成了1。好多人同时修改，一拥而上。总有人是先修改的，于是那个人就提交成功了，剩下的人惊奇的发现他们的版本小于现有版本，数据作废，于是只能把新版数据拿回去重改。这样有了多个版本，这种策略就是MVCC。因为它对数据是乐观的，大家都可以同时改嘛，最后一致就可以了。所以也叫乐观锁。

这种乐观如果遇上“读多于写”，这是非常合适的。但如果“写”比较多，那可能出现不断有事务重复执行。数据库的很多应用中读都是远多于写。H2的MvStore，MySQL的InnoDB都实现了这种策略。而作为支持并发良好的Clojure，为了实现并发的控制，实现了Ref变量，也使用类似的策略，实现了除了D之外所有数据库ACI特性。各种MVCC的实现是不同的，下一步需要继续研究细节和应用。