大数据技术-HBase：HBase并发版本控制MVCC

hbase为用户提供了一致的且易于理解的数据模型，同时保证高性能。这篇文章将向大家介绍下hbase数据模型保证和与传统关系数据库之间的区别，接着说下并发写控制的必要性，介绍了一个简单的并发控制方案。最后我们讨论读写并发控制讨论了MVCC。

为了理解hbase并发控制，我们首先需要理解为什么hbase需要并发控制，换句话说，hbase的什么属性需要引入并发控制。hbase是基于row级别的ACID事务性，ACID是指：

1 Atomicity：事务的所有操作要么全部成功要不全部失败；

2 Consistency：仅有有效的数据才能写入数据库；

3 Isolation：多个事务执行的时候相互之间不会产生影响彼此的执行；

4 Durability：一旦事务被提交，数据便被持久化了

如果你有使用关系数据库的经验，这些术语您应该比较熟悉。传统数据库对于数据库中所有数据提供了ACID语义。基于性能考量，hbase仅仅提供行级别的ACID。如果您不是很熟悉这些术语，不用担心。下面通过例子解释下：

write和write-write同步

考量两个蝙蝠写入hbase的操作，涉及两个列{company，role}：

从之前的一篇介绍hbase写路径的文章中，我们知道hbase将执行以下两步操作，在写的时候：

1. 写入WAL;

2.更新memstore，将每个数据cell写入

现在我们假设没有并发控制的情况下将可能发生以下的执行顺序：

最后，我们可能得到以下的状态：

这样却违反了隔离性的要求，所以的确是需要进行并发控制的。最简单的解决方案是在每行上面加锁。这样步骤变为下面：

0 获得行锁；

1 写WAL；

2更新memstore；

3释放行锁

read-write同步

目前为止，我们已经为写引入行锁保证ACID。而在读的时候是否也需要呢，下面让我们考虑一下的情况：

假设我们没有进行并发控制读，这时正好也发生两次写。读如果正好开始于"Waiter"被写入memstore，这个读操作将读到这样的数据：

因此我们需要并发控制处理read-write同步。最简单的方式是用read也去获取row锁。但是这个却会引起性能的急剧下降。实际上hbase引入了Multiversion Concurrency Control（MVCC）避免read获取锁的的方案。MVCC以下方式：

对于写：

w1 获取到行锁后，每个写操作立刻被分配一个write number；

w2 每个数据cell存储自己的write number；

w3 写操作完成以后要申明其已经完成了

对于读

r1 每个写操作首先被分配一个读时间戳，叫做read point；

r2 每个read point被分配一个最大的大于所有已完成write number的整数；

r3 对于read r将会返回数据cell，其满足所有的write number是小于或者等于read point r的最大值

每个写呗分配一个write number（step w1），每个数据cell附带一个write number写入memstore（step w2， e.g. "Cloudera[wn=1]"），，每个写完成通过完成且write number（step w3）

现在我们考虑下图4的读场景， read开始于step"Restaurant [wn=2]"之后，但在step“Waiter[wn=2]”之前。根据规则r1和r2，read point被分配为1，根据r3，它将会读取write number1的数据：

现在我们将所有整合下，具体步骤：

0 获取row lock；

0a 获取新的write number；

1 写入wal；

2 更新memstore

2a完成write number

3释放row lock