客户端写请求

为了提高I/O效率，AsyncProcess会合并同一个HRegion对应的put请求，然后再一次把这些相同HRegion的put请求发送到指定HRegionServer上去。另外AsyncProcess也提供了各种同步的方法，如waitUntilDone等，方便某些场景下必须对请求进行同步处理。每个put和读请求一样，都是要通过访问hbase:meta表来查找指定的HRegionServer和HRegion，这个流程和读请求一致，可以参考文章的描述。

服务端写请求

当客户端把写请求发送到服务端时，服务端就要开始执行写请求操作。HRegionServer把写请求转发到指定的HRegion执行，HRegion每次操作都是以批量写请求为单位进行处理的。主要流程实现在HRegion.doMiniBatchMutation，大致如下：

经过以上步骤后，写请求就属于被提交的事务，后面的读请求就能读取到写请求的数据。这些步骤里面都包含了HBase的各种特性，主要是为了保证可观的写请求的性能的同时，也确保行级别的事务ACID特性。接下来就具体分析一下一些主要步骤的具体情况。

HRegion的updatesLock

步骤3中获取HRegion的updatesLock，是为了防止MemStore在flush过程中和写请求事务发生线程冲突。

首先要知道MemStore在写请求的作用。HBase为了提高读性能，因此保证存储在HDFS上的数据必须是有序的，这样就能使用各种特性，如二分查找，提升读性能。但由于HDFS不支持修改，因此必须采用一种措施把随机写变为顺序写。MemStore就是为了解决这个问题。随机写的数据写如MemStore中就能够在内存中进行排序，当MemStore大小超过阀值就需要flush到HDFS上，以HFile格式进行存储，显然这个HFile的数据就是有序的，这样就把随机写变为顺序写。另外，MemStore也是HBase的LSM树（Log-Structured Merge Tree）的实现部分之一。

在MemStore进行flush的时候，为了避免对读请求的影响，MemStore会对当前内存数据kvset创建snapshot，并清空kvset的内容，读请求在查询KeyValue的时候也会同时查询snapshot，这样就不会受到太大影响。但是要注意，写请求是把数据写入到kvset里面，因此必须加锁避免线程访问发生冲突。由于可能有多个写请求同时存在，因此写请求获取的是updatesLock的readLock，而snapshot同一时间只有一个，因此获取的是updatesLock的writeLock。

获取MVCC写序号

MVCC是HBase为了保证行级别的事务一致性的同时，提升读请求的一种并发事务控制的机制。MVCC的机制不难理解，可以参考这里。

MVCC的最大优势在于，读请求和写请求之间不会互相阻塞冲突，因此读请求一般不需要加锁（只有两个写同一行数据的写请求需要加锁），只有当写请求被提交了后，读请求才能看到写请求的数据，这样就可以避免发生“脏读”，保证了事务一致性。具体MVCC实现可以参考HBase的一位PMC Member的这篇文章。

WAL（Write-Ahead Logging） 与HLog

WAL是HBase为了避免遇到节点故障无法服务的情况下，能让其它节点进行数据恢复的机制。HBase进行写请求操作的时候，默认都会把KeyValue数据写入封装成WALEdit对象，然后序列化到HLog中，在0.98.8版本里采用ProtoBuf格式进行序列化WAL。HLog是记录HBase修改的日志文件，和数据文件HFile一样，也是存储于HDFS上，因此保证了HLog文件的可靠性。这样如果机器发生宕机，存储在MemStore的KeyValue数据就会丢失，HBase就可以利用HLog里面记录的修改日志进行数据恢复。

每个HRegionServer只有一个HLog对象，因此当前HRegionServer上所有的HRegion的修改都会记录到同一个日志文件中，在需要数据恢复的时候再慢慢按照HRegion分割HLog里的修改日志（Log Splitting）。