HBase-遇到的问题

rowlock release problem with thread interruptions in batchMutate

在region server的log中有大量的WARN日志:

 WARN org.apache.hadoop.hbase.regionserver.HRegion: Failed getting lock in batch put, 

row=0001558252

搜索关键字"Failed getting lock in batch put"整个hbase代码中只有一个地方出现了这个关键字

 

1.HRegionServer#multi()接收到multi操作，找到某个region对其操作

这里会创建mutation操作，和对应的锁，锁是用RowLock获得的，默认锁id是-1，如果是-1则返回null，这样构造出的Pair对的first就是mutation，second就是null了，再将构造好的值传给HRegion#batchMutate()处理

List> mutationsWithLocks =
     Lists.newArrayListWithCapacity(mutations.size());
 for (Action a : mutations) {
   Mutation m = (Mutation) a.getAction();

   Integer lock;
   try {
     lock = getLockFromId(m.getLockId());
   } catch (UnknownRowLockException ex) {
     response.add(regionName, a.getOriginalIndex(), ex);
     continue;
   }
   mutationsWithLocks.add(new Pair(m, lock));
 }
 this.requestCount.addAndGet(mutations.size());
 OperationStatus[] codes =
     region.batchMutate(mutationsWithLocks.toArray(new Pair[]{}));

 2.HRegion#batchMutate()再调用HRegion#doMiniBatchMutation()

  这个函数很长，第一步是批量获得锁操作

while (lastIndexExclusive < batchOp.operations.length) {
        boolean shouldBlock = numReadyToWrite == 0;
        Integer acquiredLockId = null;
        try {
          acquiredLockId = getLock(providedLockId, mutation.getRow(),
              shouldBlock);
        } catch (IOException ioe) {
          LOG.warn("Failed getting lock in batch put, row="
                  + Bytes.toStringBinary(mutation.getRow()), ioe);
        }
 ....
}

 3.HRegion#getLock()函数是一个分支，通过debug来看，走的是if，因为lockid是null，在第一步里面有说明

public Integer getLock(Integer lockid, byte [] row, boolean waitForLock)
throws IOException {
  Integer lid = null;
  if (lockid == null) {
    lid = internalObtainRowLock(row, waitForLock);
  } else {
    if (!isRowLocked(lockid)) {
      throw new IOException("Invalid row lock");
    }
    lid = lockid;
  }
  return lid;
}

 4.最后调用HRegion#internalObtainRowLock(final byte[] row, boolean waitForLock)

while (true) {
   CountDownLatch existingLatch = lockedRows.putIfAbsent(rowKey, rowLatch);
   if (existingLatch == null) {
     break;
   } else {
     // row already locked
     if (!waitForLock) {
       return null;
     }
     try {
       if (!existingLatch.await(this.rowLockWaitDuration,
                       TimeUnit.MILLISECONDS)) {
         throw new IOException("Timed out on getting lock for row="
             + Bytes.toStringBinary(row));
       }
     } catch (InterruptedException ie) {
       // Empty
     }
   }
 }

internalObtainRowLock()函数的开头会创建一个readLock()，在函数结束后会释放这个readLock()

lockedRows是一个ConcurrentHashMap，当第一次调用putIfAbsent()时候，由于map中还没有这个key，所以返回的CountDownLatch为null，于是直接返回了。

可以看到lockedRows的key就是rowkey，所有之前这个map中存在了相同的rowkey，但是没有被remove掉，之后又有请求要操作相同的key就会等待，如果等待30秒(rowLockWaitDuration值为30秒)则会抛出异常，之后向上抛被HRegion#batchMutate()捕获并打印日志，也就是日志中出现的 Failed getting lock in batch put

这个锁只对于Put和Delete操作，Get操作不受锁的影响

 

这个函数有一个waitForLock参数，如果为false，则不会等待直接返回

在第二步中有一个中有一个重试次数，如果不为0则传到internalObtainRowLock()函数时变量waitForLock就为false，但是不会做这个重试。而是直接返回了，所以每次再有新的请求时，都会用waitForLock=true去调用这个函数，所以也就阻塞了，而且HRegion#batchMutate()有一个循环判断，这个循环也没有退出来，也就不是不停的调用HRegion#doMiniBatchMutation()，不停的重试，获取锁。

如果锁住rowkey的这个进程卡主了或者其他原因导致lockedRows中一直有这个rowkey，那么这个重试循环就不会退出导致死循环，所以日志会会出现大量的Failed getting lock in batch put

WARN org.apache.hadoop.hbase.regionserver.HRegion: Failed getting lock in batch put, row=0001558252

这个是因为有一个Delete或Put操作，已经将rowkey锁住了，之后又有Delete或Put操作这个rowkey触发了一个CountDownLatch等待超时抛出的异常。

参考：

HBASE-7711

RegionServer stuck in internalObtainRowLock forever - HBase 0.94.7

How to improve my configuration of HBase version cdh4.4.0