HBase源码分析之MemStore的flush发起时机、判断条件等详情(二)

  1. 云栖社区>
  2. 博客>
  3. 正文

HBase源码分析之MemStore的flush发起时机、判断条件等详情(二)

柏辰爸爸 2016-03-07 17:04:00 浏览1229
展开阅读全文

        在《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);
        很简单,构造一个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请求,是不是很容易就产生一个风暴,引起系统性能瓶颈呢?

        关于如何提交一个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,即列簇为单位进行。此乃后话,我们以后再做分析。







网友评论

登录后评论
0/500
评论
柏辰爸爸
+ 关注