HBase的Flush操作的触发条件：
1)Manual调用，HRegionInterface#flushRegion，可以被用户态org.apache.hadoop.hbase.client.HBaseAdmin调用flush操作实现，该操作会直接触发HRegion的internalFlush。
2)HRegionServer的一次更新操作，使得整个内存使用超过警戒线。警戒线是globalMemStoreLimit, RS_JVM_HEAPSIZE * conf.getFloat(“hbase.regionserver.global.memstore.upperLimit”)，凡是超过这个值的情况，会直接触发FlushThread，从全局的HRegion中选择一个，将其MemStore刷入hdfs，从而保证rs全局的memstore容量在可控的范围。
RS上HRegion的选择算法：
步骤1：RS上的Region，按照其MemStore的容量进行排序。
步骤2：选出Region下的Store中的StoreFile的个数未达到hbase.hstore.blockingStoreFiles，并且MemStore使用最多的Region。— bestFlushableRegion
步骤3:选出Region下的MemStore使用最多的Region。— bestAnyRegion
步骤4：如果bestAnyRegion的memstore使用量超出了bestFlushableRegion的两倍，这从另外一个角度说明，虽然当前bestAnyRegion有超过blockingStoreFiles个数的文件，但是考虑到RS内存的压力，冒着被执行Compaction的风险，也选择这个Region，因为收益大。否则，直接使用bestFlushableRegion。
指定的Region写入hdfs的过程：
步骤1：获得updatesLock的写锁，阻塞所有对于该Region的更新操作。由此，可知Flush操作会阻塞Region区域内Row的更新操作(Put、Delete、Increment)，因为在阻塞更新操作期间，涉及到Memstore的snapshot操作，如果不做限制，那么很可能一个put操作的多个KV，分别落在kvset和snapshot当中，从而与hbase保证row的原子性相悖。
步骤2：mvcc推进一次写操作事务。每个Region维护了一个mvcc对象(Multi Version
Consistency Control)，用来控制读写操作的事务性。
步骤3：从HLog中获取一个新的newSeqNum，更新HLog的lastSeqWritten。由于此时该Region的更新操作会暂停，因此，会暂时删除lastSeqWritten记录的<RegionName,lastSeqNum>，写入<”snp”+RegionName, newSeqNum>到lastSeqWritten中。这里的lastSeqWritten是HLog用来存储每个Regiond到当前时刻最后一次提交操作的SeqNum。
步骤4：为Region下的每个Store的MemStore执行snapshot操作。
如上图所示，HRegion上Store的个数是由Table中ColumnFamily的个数确定，每个Store是由一个MemStore和数个StoreFile(HFile)文件组成，在正常的更新操作过程中，更新的内容会写入MemStore里的kvset结构中。HRegion执行Flush操作，实际上是把MemStore的内容全部刷入hdfs的过程。虽然，目前更新操作已经通过加写锁阻塞，可是读操作仍然可以继续，因此，在memstore执行snapshot的过程中，通过reference，snapshot会指向kvset，然后给kvset指向一个全新的内存区域。代码如下：
步骤5：释放updatesLock的写锁，此时该HRegion可以接收更新操作。
步骤6：更新mvcc读版本到当前写版本号。
这里有一个小插曲，在更新操作时，mvcc. completeMemstoreInsert 的操作在updatesLock的范围之外，这样在多线程高并发情况下，就存在已经写入MemStore的kvset当中，但是事务还未完成提交的情况。该场景相关代码如下：
从4358行，我们可以清晰看到，通过updatesLock保证了更新操作写入了MemStore的kvset，但假定Flush线程在其它更新线程4363行之后，获得了updatesLock写锁，并执行了snapshot操作。那么，这里的mvcc就会出现读写的事务号不一致的情况，因此，在Region的Flush线程就需要使用waitForRead(w)，等待更新到目前写版本号。
步骤7：将Store内的snapshot写成一个StoreFile临时文件。
步骤8：重命名storefile文件，更新Store里文件和Memstore状态。
在步骤8完成之前，整个Hregion的读请求，是和之前没有影响的。因为在读请求过程中，StoreScanner对于kvset和snapshot进行进行同步读取，即使kvset切换成snapshot，scan的操作仍然可以继续，这部分的内容是由MemStoreScanner来控制。
在读过程中，Store里的scanner有两部份,一个是StoreFileScanner，另外一个是MemStoreScanner，它们都继承了KeyValueScanner接口，并通过StoreScanner中的KeyValueHeap封装起来。于此类似，在RegionScannerImpl也是通过一个KeyValueHeap把每个Store的StoreScanner封装起来，从而直接提供对外的服务。
读到这里，可能细心的工程师们，就会有一个疑问：Flush操作对于读的影响究竟有没有呢？
有影响，但比较小。在步骤8以前那些阶段，MemStoreScanner做到了对于kvset与snapshot的自由切换。
如上所示，如果kvset被重置，那么theNext将不再等于kvsetNextRow，从而切换成开始从snapshot迭代器中获取数据。
因此，在步骤1~7之间，对于读服务影响不大。但是在步骤8操作最后一步时，需要把生成storefile更新到可用的Store中的StoreFile列表，并清除snapshot的内容。
于是，此时ChangedReaderOberver就开始起作用了。
// Tell listeners of the change in readers.
notifyChangedReadersObservers();
这里最为关键的是，将storescanner用来封装全部StoreFileScanner和MemStoreScanner的heap清空，它会触犯的作用是在执行next()操作时，会触发resetScannerStack操作，会重新加载Store下的所有Scanner，并执行seek到最后一次更新的key。这个过程会使得flush操作对于某些next操作变得突然顿一下。