mvcc (multiversion concurrency control)，即多版本并发控制技术，它使得大部分支持行锁的事务引擎，不再单纯的使用行锁来进行数据库的并发控制，取而代之的是，把数据库的行锁与行的多个版本结合起来，只需要很小的开销，就可以实现非锁定读，从而大大提高
mvcc (multiversion concurrency control)，即多版本并发控制技术，它使得大部分支持行锁的事务引擎，不再单纯的使用行锁来进行数据库的并发控制，取而代之的是，把数据库的行锁与行的多个版本结合起来，只需要很小的开销，就可以实现非锁定读，从而大大提高数据库系统的并发性能。
hbase正是通过行锁+mvcc保证了高效的并发读写。
为什么需要并发控制hbase系统本身只能保证单行的acid特性。acid的含义是：
原子性(atomicity)一致性(consistency)隔离性(isolation)持久性(durability)传统的关系型数据库一般都提供了跨越所有数据的acid特性；为了性能考虑，hbase只提供了基于单行的acid。
下面是一个hbase并发写的例子。
原始数据如下
从apache hbase write path一文可以知道hbase写数据是分为两步：
1. 写write-ahead-log(wal)文件
2. 写memstore：将每个cell[(row,column)对]的数据写到内存中的memstore
写写同步假定对写没有采取并发控制，并考虑以下的顺序：
最终得到的结果是：
这样就得到了不一致的结果。显然我们需要对并发写操作进行同步。
最简单的方式是提供一个基于行的独占锁来保证对同一行写的独立性。所以写的顺序是：
(0) 获取行锁(1) 写wal文件(2) 更新memstore：将每个cell写入到memstore(3) 释放行锁读写同步尽管对并发写加了锁，但是对于读呢？见下面的例子：
如果在上面的图中红线所示的地方进行读操作，最终得到的结果是：
可见需要对读和写也进行并发控制，不然会得到不一致的数据。最简单的方案就是读和写公用一把锁。这样虽然保证了acid特性，但是读写操作同时抢占锁会互相影响各自的性能。
mvcc算法hbase采用了mvcc算法来避免读操作去获取行锁。
对于写操作：
(w1) 获取行锁后，每个写操作都立即分配一个写序号(w2) 写操作在保存每个数据cell时都要带上写序号(w3) 写操作需要申明以这个写序号来完成本次写操作对于读操作:
(r1) 每个读操作开始都分配一个读序号，也称为读取点(r2) 读取点的值是所有的写操作完成序号中的最大整数(所有的写操作完成序号(r3) 对某个(row,column)的读取操作r来说，结果是满足写序号为“写序号在采用mvcc后的数据执行图：
注意到采用mvcc算法后，每一次写操作都有一个写序号(即w1步)，每个cell数据写memstore操作都有一个写序号(w2，例如：“cloudera [wn=1]”))，并且每次写操作完成也是基于这个写序号(w3)。
如果在“restaurant [wn=2]” 这步之后，“waiter [wn=2]”这步之前，开始一个读操作。根据规则r1和r2，读的序号为1。根据规则3，读操作以序号1读到的值是：
这样就实现了以无锁的方式读取到一致的数据了。
重新总结下mvcc算法下写操作的执行流程：
(0) 获取行锁(0a) 获取写序号(1) 写wal文件(2) 更新memstore：将每个cell写入到memstore(2a) 以写序号完成操作(3) 释放行锁本文是基于hbase 0.92. 在hbase 0.94中会有些优化策略，比如 hbase-5541 提到的。
英文原文：https://blogs.apache.org/hbase/entry/apache_hbase_internals_locking_and
参考：深入理解mvcc多版本并发控制
原文地址：hbase的行锁与多版本并发控制(mvcc), 感谢原作者分享。