如果对上面的解释不理解也没关系，下面举例来说，我们通常在写入数据库时，会遇到写写同步和读写同步两种情况，分开说：

一、写写同步

假设有两个程序同时往HBase某表中同一行的同一个Family（Info）的两个Qualifier（Company、Role）写入数据，一般情况下，这两个写入请求会被HBase RegionServer接收后封装成两个Call，然后被两个Handler（线程）分别处理，即将请求中的数据写入列簇Company的MemStore中，对于MemStore来说，这些数据是被并发的线程写入的。

具体写入数据时是以KeyValue为数据单位的，对于上图中的数据来说，实际写入时有四个KeyValue，每个写入线程负责写入两个KeyValue，如果HBase没有相应的并发控制，则这四个KeyValue写入MemStore的顺序是无法预料的，可能会出现以下情况：

最终得到的结果是：

这样就得到了不一致的结果。显然我们需要对并发写操作进行同步。最简单的一种方案是在对某一行进行操作之前，首先显式对该行进行加锁操作，加锁成功后才进行相应操作，否则只能等待获取锁，此时，写入流程如下：

• (0) 获取行锁
• (1) 写WAL文件
• (2) 更新MemStore：将每个cell写入到memstore
• (3) 释放行锁

引入行锁的机制后，就可以避免并发情景下，对同一行数据进行操作（写入或更新）时出现数据交错的情况。

二、读写同步

假设我们没有为HBase的读操作引入任何的并发控制策略，在两次写入请求的同时，再发起一个读取请求，这三个请求都是针对同一行进行读写操作的，考虑如下情况：

如上图所示，如果读取请求正好在Waiter被写入MemStore之前被执行，最终得到的结果是：

可见需要对读和写也进行并发控制，不然会得到不一致的数据。最简单的方案就是读和写公用一把锁。这样虽然保证了ACID特性，但是读写操作同时抢占锁会互相影响各自的性能。

最简单的方案是和写入一样，在读取操作前后分别加入获取锁与释放锁的步骤，这样的话，性能一下子就下来了。HBase使用了一种mvcc的策略来避免读取的锁操作。

mvcc对于写操作：

• (w1) 获取行锁后，每个写操作都立即分配一个写序号
• (w2) 写操作在保存每个数据cell时都要带上写序号
• (w3) 写操作需要申明以这个写序号来完成本次写操作

对于读操作:

• (r1) 每个读操作开始都分配一个读序号，也称为读取点
• (r2) 读取点的值是所有的写操作完成序号中的最大整数(所有的写操作完成序号<=读取点)
• (r3) 对某个(row,column)的读取操作r来说，结果是满足写序号为“写序号<=读取点这个范围内”的最大整数的所有cell值的组合

使用了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) 释放行锁