总结一下HBase各种级别的锁以及对读写的阻塞

[java]  view plain  copy

 

1.   /** 
2.    * @param put 
3.    * @param lockid 
4.    * @param writeToWAL 
5.    * @throws IOException 
6.    * @deprecated row locks (lockId) held outside the extent of the operation are deprecated. 
7.    */  
8.   public void put(Put put, Integer lockid, boolean writeToWAL)  
9.   throws IOException {  
10.     checkReadOnly();  
11.   
12.   
13.     // Do a rough check that we have resources to accept a write.  The check is  
14.     // 'rough' in that between the resource check and the call to obtain a  
15.     // read lock, resources may run out.  For now, the thought is that this  
16.     // will be extremely rare; we'll deal with it when it happens.  
17.     checkResources();  
18.     startRegionOperation();  
19.     this.writeRequestsCount.increment();  
20.     this.opMetrics.setWriteRequestCountMetrics(this.writeRequestsCount.get());  
21.     try {  
22.       // We obtain a per-row lock, so other clients will block while one client  
23.       // performs an update. The read lock is released by the client calling  
24.       // #commit or #abort or if the HRegionServer lease on the lock expires.  
25.       // See HRegionServer#RegionListener for how the expire on HRegionServer  
26.       // invokes a HRegion#abort.  
27.       byte [] row = put.getRow();  
28.       // If we did not pass an existing row lock, obtain a new one  
29.       Integer lid = getLock(lockid, row, true);  
30.   
31.   
32.       try {  
33.         // All edits for the given row (across all column families) must happen atomically.  
34.         internalPut(put, put.getClusterId(), writeToWAL);  
35.       } finally {  
36.         if(lockid == null) releaseRowLock(lid);  
37.       }  
38.     } finally {  
39.       closeRegionOperation();  
40.     }  
41.   }  

[java]  view plain  copy

 

1. private Integer internalObtainRowLock(final HashedBytes rowKey, boolean waitForLock)  
2.      throws IOException {  
3.    checkRow(rowKey.getBytes(), "row lock");  
4.    startRegionOperation();  
5.    try {  
6.      CountDownLatch rowLatch = new CountDownLatch(1);  
7.   
8.      // loop until we acquire the row lock (unless !waitForLock)  
9.      while (true) {  
10.        CountDownLatch existingLatch = lockedRows.putIfAbsent(rowKey, rowLatch);  
11.        if (existingLatch == null) {  
12.          break;  
13.        } else {  
14.          // row already locked  
15.          if (!waitForLock) {  
16.            return null;  
17.          }  
18.          try {  
19.            if (!existingLatch.await(this.rowLockWaitDuration,  
20.                            TimeUnit.MILLISECONDS)) {  
21.              throw new IOException("Timed out on getting lock for row=" + rowKey);  
22.            }  
23.          } catch (InterruptedException ie) {  
24.            // Empty  
25.          }  
26.        }  
27.      }  
28.   
29.      // loop until we generate an unused lock id  
30.      while (true) {  
31.        Integer lockId = lockIdGenerator.incrementAndGet();  
32.        HashedBytes existingRowKey = lockIds.putIfAbsent(lockId, rowKey);  
33.        if (existingRowKey == null) {  
34.          return lockId;  
35.        } else {  
36.          // lockId already in use, jump generator to a new spot  
37.          lockIdGenerator.set(rand.nextInt());  
38.        }  
39.      }  
40.    } finally {  
41.      closeRegionOperation();  
42.    }  
43.  }  

[java]  view plain  copy

 

1. // Lock row  
2. Integer lid = getLock(lockId, get.getRow(), true);  
3. ......  
4. // get and compare  
5. try {  
6.   result = get(get, false);  
7.   ......  
8.   //If matches put the new put or delete the new delete  
9.   if (matches) {  
10.     if (isPut) {  
11.       internalPut(((Put) w), HConstants.DEFAULT_CLUSTER_ID, writeToWAL);  
12.     } else {  
13.       Delete d = (Delete)w;  
14.       prepareDelete(d);  
15.       internalDelete(d, HConstants.DEFAULT_CLUSTER_ID, writeToWAL);  
16.     }  
17.     return true;  
18.   }  
19.   return false;  
20. } finally {  
21.   // release lock  
22.   if(lockId == null) releaseRowLock(lid);  
23. }  

checkAndPut在实际应用中非常有价值，我们线上生成Dpid的项目，多个客户端会并行生成DPID，如果有一个客户端已经生成了一个DPID，则其他客户端不能生成新的DPID，只能获取该DPID
代码片段：

[java]  view plain  copy

 

1. ret = hbaseUse.checkAndPut("bi.dpdim_mac_dpid_mapping", mac, "dim",  
2.         "dpid", null, dpid);  
3. if(false == ret){  
4.     String retDpid = hbaseUse.query("bi.dpdim_mac_dpid_mapping", mac, "dim", "dpid");  
5.     if(!retDpid.equals(ABNORMAL)){  
6.         return retDpid;  
7.     }  
8. }else{  
9.     columnList.add("mac");  
10.     valueList.add(mac);  
11. }  
12. 
    

为了保证并发操作时数据的一致性和性能，HBase中应用了各种各样高效的可重入锁，包括行级别的rowlock、mvcc，region级别的读写锁，store级别的读写锁，memstore级别的读写锁等等。

1、  行级别的锁RowLock

HBase中为了解决行级别在并发操作中的一致性问题，采用了Rowlock机制。保证只有同一个线程同时对该行做操作。当然rowlock有lease租约的概念，超过期限，自动释放该行锁

2、  MVCC

处于并发性能的考虑，Rowlock只在write数据时采用，对于读写并发操作，HBase采用了MVCC解决方案。

基本原理是writer操作会经过WAL、Memstore等一系列过程，首先在Rowlock操作后，立即分配一个writer number，每个cf column cell在store中都会带上这个writer number，在写操作结束即release lock前，会标记writer number已经结束；每个读操作在开始时(readpoint)会分配最大的处于结束的writer number，即最新的处于结束的writer number(memstore中的值可用存在写操作未结束的，这些值不可以读，所以在flush cache的时候必须等待memstore中所有的值都是写结束的)。详细的MVCC分析可以参见以前写的blog:http://blog.csdn.net/yangbutao/article/details/8998800

3、  Region级别的锁

在做更新操作时，需要判断资源是否满足要求，如果到达临界点，则申请进行flush操作，等待直到资源满足要求（参见Region中的checkResource）

Region update更新锁(updatesLock)，在internalFlushCache时加写锁，导致在做Put、delete、increment操作时候阻塞(这些操作加的是读锁)。

Region close保护锁(lock)，在Region close或者split操作的时(加写锁)，阻塞对region的其他操作(加读锁)，比如compact、flush、scan和其他写操作。

4、  Store级别的锁

flush过程包括，

        a 、prepare(基于memstore做snapshot)

        b、flushcache(基于snapshot生成临时文件)

        c、commit(确认flush操作完成，rename临时文件为正式文件名称，清除mem中的snapshot)

其中在flush过程的commit阶段，compact过程的completeCompaction阶段(rename临时compact文件名、清理旧的文件)，close store(关闭store)，bulkLoadHFile，会阻塞对store的写操作。

5、  MemStore级别的锁

对Store的写操作会调用Memstore的相关操作，在对memstore做snapshot以及清除snapshot的时候会阻塞其他操作(如add、delete、getNextRow)。