HBase0.94在flush操作时候的一个漏洞

基于HBase0.94版本，在高并发写操作时，运行时偶尔出现丢失数据的情况，查看了HBase的日志，出现一下信息，

WARN org.apache.hadoop.hbase.regionserver.MemStore: Snapshot called again without clearing previous. Doing nothing. Another ongoing flush or did we fail last attempt?

这个问题是HBase在flush操作时的一个bug，HBase JIRA中有对应的patch，HBASE-7671(Flushing memstore again after last failure could cause data loss)

下面对出现这个问题的原因分析一下，

我们知道HBase在memstore达到一定阈值时会进行flush操作，flush主要包括三个过程，snapshot，flush cache，commit

snapshot是对memstore中的内存对象进行快照，在快照过程中需要阻塞write操作，snapshot完成后，重置内存中的对象。

flush cache过程基于snapshot生成tmp HFile，同时在HFile中的元数据中保存seqNum，这个seqNum是基于HLog的当前region最后完成的seqNum(写数据的HLog key value 对会带上seqNum)。

commit提交flush，把storeFile加入到Store中，并清除memstore snapshot(此时判断是否需要进行compact操作)(调用Store.updateStorefiles，会对store的lock加写锁，这样其他的写数据的操作就会堵塞<读锁>)；最后会向WAL确认完成本次的flush操作，把该seqNum写入到HLog中，这样表示小于该seqNum的操作都已经持久化到HFile中了，下次恢复从该位置恢复即可，便于Hlog的relay操作。

这个问题在于先前的flush cache过程因异常而snapshot未清理，后续flush在snapshot的过程中，发现当前memstore中存在snaoshot，那么就不再做snapshot了，该snapshot是基于先前的flush操作的，这样就会存在丢失后面flush的那部分数据(因最后给WAL确认的seqNum还是后面flush的那个seqNum，但实际是对先前的snapshot做操作)。

所以解决思路是在snapshot的开始的时候，若存在snapshot，则把该snapshot也加入到当前需要flush的内存区域中。