HBase源代码分析之MemStore的flush发起时机、推断条件等详情（二）
在《HBase源代码分析之MemStore的flush发起时机、推断条件等详情》一文中，我们具体介绍了MemStore flush的发起时机、推断条件等详情。主要是两类操作。一是会引起MemStore数据大小变化的Put、Delete、Append、Increment等操作，二是会引起HRegion变化的诸如Regin的分裂、合并以及做快照时的复制拷贝等。相同会触发MemStore的flush流程。同一时候。在《HBase源代码分析之compact请求发起时机、推断条件等详情（一）》一文中，我们讲到了针对compact。在HRegionServer内部存在一个工作线程compactionChecker，它会周期性的工作。以检查是否达到可以发起compact请求的条件。那么，回过头来，我们再看MemStore flush，它是不是也存在一个后台工作线程。可以周期性的工作，以检查是否达到可以发起flush请求的条件呢？本文，我们就之前《HBase源代码分析之MemStore的flush发起时机、推断条件等详情》一文，做一个关于MemStore flush后台检查线程等内容的补充。
在HRegionServer中，有一个和合并检查线程compactionChecker一样的Chore--periodicFlusher，它也是类似于compactionChecker的后台工作线程。它负责周期性的检查MemStore，查看是否达到发起MemStore flush的条件。其定义例如以下：
/* * Check for flushes * 检查刷新请求 */ Chore periodicFlusher;它也是一个继承自Chore的工作线程。关于Chore的介绍。在《HBase源代码分析之compact请求发起时机、推断条件等详情（一）》一文中我已经讲过了。这里不再做介绍。
而periodicFlusher的初始化。自然同compactionChecker一样，也是在HRegionServer的initializeThreads()方法中完毕的，代码例如以下：
this.periodicFlusher = new PeriodicMemstoreFlusher(this.threadWakeFrequency, this);非常easy，构造一个PeriodicMemstoreFlusher对象，并且其工作频率也是通过HRegionServer的threadWakeFrequency决定的。
那么这个periodicFlusher究竟是什么样的实现类，其工作原理是什么样子的呢？莫慌，让我为大家一一道来。
首先看下PeriodicMemstoreFlusher的定义、成员变量与构造方法。代码例如以下：
static class PeriodicMemstoreFlusher extends Chore {
final HRegionServer server;
final static int RANGE_OF_DELAY = 20000; //millisec
final static int MIN_DELAY_TIME = 3000; //millisec
public PeriodicMemstoreFlusher(int cacheFlushInterval, final HRegionServer server) {
// cacheFlushInterval为flush的时间间隔
super(server.getServerName() + "-MemstoreFlusherChore", cacheFlushInterval, server);
this.server = server;
}
} 通过成员变量和构造方法。我们能够看到，比較重要的就是线程中HRegionServer的实例server以及线程工作频率。另外它还提供了两个定值MIN_DELAY_TIME与RANGE_OF_DELAY，有什么用呢。继续看它的chore()方法：
@Override
protected void chore() {
// 循环HRegionSever上的onlineRegions
for (HRegion r : this.server.onlineRegions.values()) {
// HRegion为null的话直接跳过
if (r == null)
continue;
// 调用HRegion上的shouldFlush()方法，推断能否够进行flush
if (r.shouldFlush()) {
// 获取RegionServer上的MemStoreFlusher类型的memstore内存刷新管理对象
FlushRequester requester = server.getFlushRequester();
if (requester != null) {
// 随机延迟时间：20s内的一个随机时间+3s的基础时间
long randomDelay = RandomUtils.nextInt(RANGE_OF_DELAY) + MIN_DELAY_TIME;
LOG.info(getName() + " requesting flush for region " + r.getRegionNameAsString() +
" after a delay of " + randomDelay);
//Throttle the flushes by putting a delay. If we don't throttle, and there
//is a balanced write-load on the regions in a table, we might end up
//overwhelming the filesystem with too many flushes at once.
// 通过设置一个延迟时间控制flush。防止Region上多个flush同一时间并发进行
requester.requestDelayedFlush(r, randomDelay);
}
}
}
}
} 通过chore()方法我们知道，periodicFlusher线程周期性的对HRegionServer上全部在线Region进行检測，调用其shouldFlush()方法进行检測，假设该Region须要flush memstore，获取RegionServer上的MemStoreFlusher类型的memstore内存刷新管理对象，发起flush请求。
须要注意的是。该flush请求携带一个固定加随机的延迟时间，其算法为：
long randomDelay = RandomUtils.nextInt(RANGE_OF_DELAY) + MIN_DELAY_TIME;MIN_DELAY_TIME就是我们上面提到的固定值3秒，然后再加上一个20s内的一个随机数。为什么要这么做呢？试想下。假设马上提交一个flush请求，或者在3秒后马上提交一个flush请求，是不是非常easy就产生一个风暴。引起系统性能瓶颈呢？
关于怎样提交一个flush请求。前面的文章已经介绍过了，不再赘述。
这里我们介绍下HRegion的shouldFlush()方法，代码例如以下：
/**
* Should the memstore be flushed now
* memstore如今是否应该被flush
*/
boolean shouldFlush() {
// This is a rough measure.
// 这里是一个粗略的測量
// 上次flush之后。sequenceId的增长超过flushPerChanges。即发起一次flush
// 次数限制通过參数hbase.regionserver.flush.per.changes配置。默觉得30000000（3千万）
// 也就是该Region上数据的修改次数，不管增、改、删等，超过一定的次数，即发起一次flush
// 意味着会兼顾HRegion上的写请求及时flush到磁盘上
if (this.lastFlushSeqId > 0
&& (this.lastFlushSeqId + this.flushPerChanges < this.sequenceId.get())) {
return true;
}
// hbase.regionserver.optionalcacheflushinterval參数小于等于0，不会触发flush
//
if (flushCheckInterval <= 0) { //disabled
return false;
}
long now = EnvironmentEdgeManager.currentTime();
//if we flushed in the recent past, we don't need to do again now
// 时间间隔未超过hbase.regionserver.optionalcacheflushinterval配置的时间间隔
// 默觉得3600000ms，即1小时
if ((now - getLastFlushTime() < flushCheckInterval)) {
return false;
}
//since we didn't flush in the recent past, flush now if certain conditions
//are met. Return true on first such memstore hit.
// 检測每一个列簇，当当中一个列簇超过flushCheckInterval没有flush时。发起flush
for (Store s : this.getStores().values()) {
if (s.timeOfOldestEdit() < now - flushCheckInterval) {
// we have an old enough edit in the memstore, flush
return true;
}
}
return false;
} 推断的逻辑比較清晰，概括例如以下：
1、首先。上次flush之后。sequenceId的增长超过flushPerChanges。即发起一次flush：
次数限制flushPerChanges是通过參数hbase.regionserver.flush.per.changes配置，默觉得30000000（3千万），这个sequenceId的增长该Region上数据的修改次数，不管增、删、改或者append、increment等，它是对HRegion数据变动的一个考虑，即便是MemStore不大。数据变动的频繁了，也须要进行flush。以减少宕机后拆分日志的工作量；
2、再看參数hbase.regionserver.optionalcacheflushinterval:
參数小于等于0。不会触发flush，时间间隔未超过參数l配置的时间间隔的话，也不会触发flush。这个參数默觉得3600000ms，即1小时；
3、当超过參数配置的时间间隔。再检測每一个列簇，当当中一个列簇超过flushCheckInterval没有flush时。发起flush。也就是说它有足够久的数据没有被flush。
以上就是HRegionServer内部PeriodicMemstoreFlusher工作线程periodicFlusher的所有内容。
同一时候。在上面针对每一个HRegion的循环，以及后面针对每一个HStore的推断，我们能够发现，flush还是以Region为最小单位进行的。
即便是某个列簇下MemStore过大或者过旧，另外一个MemStore还比較小或者比較新的话，它还是跟着那个过大或者过旧的列簇一起flush。这也是HBase饱受诟病的列簇不能过多的原因之中的一个。
在HBase1.1.2版本号中，有对于MemStore flush的改进，改成了以HStore，即列簇为单位进行。
此乃后话，我们以后再做分析。
