hbase锁机制

博文说明：1、研究版本hbase0.94.12；2、贴出的源代码可能会有删减，只保留关键的代码。

 

  hbase的锁是采用jdk的ReentrantReadWriteLock类实现

 

  一、HRegion有两种锁：lock、updatesLock，这两种锁均是ReentrantReadWriteLock类的实例，基本上所有的region操作均需要获取lock的read共享锁，在获取了lock的read锁后，如果是增加或者删除等影响数据内容的操作则还需要获取updatesLock的read锁。

 

  1、HRegion的lock锁影响如下的操作： 

  其中关闭region的doClose方法需要持有lock的write锁，startBulkRegionOperation在进行跨列簇处理时也要求持有lock的writ锁，其它均只需持有lock的read锁，startBulkRegionOperation是在使用工具LoadIncrementalHFiles装载通过HFileOutputFormat输出的HFile文件到一个已经存在的表时执行的方法，因此执行该操作最好是在该region空闲时执行。

受lock锁影响的startRegionOperation()方法又影响如下操作：

   由以上两图可以分析出，一旦执行了region的关闭操作或者通过工具LoadIncrementalHFiles向已经存在的表装载跨列簇的数据时会阻塞，尤其是close方法，通过锁的实现可以确保当close发生时拒绝所有的region请求，避免出现关闭过程中再执行其它任何操作，而出现错误服务的问题。

 

2、HRegion的updatesLock影响如下操作： 

 

其中只有flush时执行的internalFlushcache方法需要持有updatesLock的write锁，由此可见，flush方法会阻塞所有的可能改动memstore内容的操作。

put等需要改动memstore内容的操作均需要持有read和updatesLock锁，以put方法为例说明，源代码如下：

public void put(Put put, Integer lockid, boolean writeToWAL) throws IOException {     startRegionOperation();  // 获取lock 锁     this.writeRequestsCount.increment();     this.opMetrics.setWriteRequestCountMetrics( this.writeRequestsCount.get());     try {       byte [] row = put.getRow(); Integer lid = getLock(lockid, row, true);       try {         internalPut(put, put.getClusterId(), writeToWAL);       } finally {         if(lockid == null) releaseRowLock(lid);       }     } finally {       closeRegionOperation(); // 释放lock 锁     }   }   private void internalPut(Put put, UUID clusterId, boolean writeToWAL) throws IOException {     lock( this.updatesLock.readLock()); // 获取updatesLock 锁     try {       checkFamilies(familyMap.keySet());       checkTimestamps(familyMap, now);       updateKVTimestamps(familyMap.values(), byteNow);       if (writeToWAL) {         addFamilyMapToWALEdit(familyMap, walEdit);         walEdit.addClusterIds(put.getClusterIds());         this.log.append(regionInfo, this.htableDescriptor.getName(),             walEdit, clusterId, now, this.htableDescriptor);       } else {         recordPutWithoutWal(familyMap);       }         long addedSize = applyFamilyMapToMemstore(familyMap, null);       flush = isFlushSize( this.addAndGetGlobalMemstoreSize(addedSize));     } finally {       this.updatesLock.readLock().unlock(); // 释放updatesLock 锁     }   }

 

二、MemStore有一个lock锁，该锁涉及如下的方法:

   其中snapshot和clearSnapshot方法要求持有lock的write锁，这两个方法均是在flush memstore期间调用，这两个flush的子过程中会产生的write排它锁会影响到对memstore的所有读写操作，而从hbase读取数据中的第一步就是读取memstore，可见flush memstore是一个比较重的过程，影响读写，而一个flush操作至少会flush整个region，在flush期间，整个region的服务性能均会下降，因此有合适的flush次数和region的大小对性能提升会有所帮助。flush的次数主要受如下配置项影响：

hbase.regionserver.global.memstore.upperLimit

hbase.regionserver.global.memstore.lowerLimit

hbase.hregion.memstore.flush.size

 

  可以适当调大以上3项配置，但是需要注意的是并不是越大越好，如果全局的lowerLimit和upperLimit过大，则会影响读的性能，如果局部的flush.size过大则会导致一次flush的时间过长，而且当数据写入分散到每个region比较均衡时，可能单个region的memstore均没有达到阀值而全局的memstore以及达到阀值，这会导致整个regionservice的写、删等修改memstore内存的操作阻塞，并且可能会多生成一些相对较小的storeFile文件，从而又导致增加compact的次数，compact也是比较消耗资源的操作。

已有 0 人发表留言，猛击->> 这里<<-参与讨论


ITeye推荐

• —软件人才免语言低担保 赴美带薪读研！—