hbase HTablePool－实现原理-概览

 一。流程图

 
 二。原理

在使用HTable前要建立一个HTablePool实例。明白这个可以考虑为table的factory：get 或close,或close pool都可以。这个实例会同时建立一个内部object:PoolMap,其实不是真正的map，只是一个wrapper而已。这个map包含以table为key，相对应key为values的Pool，这种pool三种类型，详细见上图。可以说这个map是对三种pool的一个proxy:get table ,close table etc.相应的操作会直接在相应pool中进行，如Resuable#get(),因为这些pool都已经实现了base class:Pool<Table>

 

再来看这三种类型pool的特点:

pool	features	适用
Resuable	重用池，内部利用一个queue，在close放到tail,get时取头部	一般情况都可以，避免因不同线程使用不同数量htable造成过载。
ThreadLocal	线程本地池，就是一个线程只出来一个htable	如果明确有些线程使用htables多，其它少
RoundRobin	轮转，内部使用一个按maxsize arry,每次get时根据计数返回对应htable 由于这方式需要在使用前必须实例化maxsize对象,现在已经在94.2中没有使用	N/A

 

 再之，如果在建立Htablepool时使用不变的Configuration，那么最终所有的htable共享HConnection，因为建立connection是依据config所zk，hbase master等信息建立的。所以如果不是在cross cluster情况下不建议使用multi config。由于HConnection中也存在一个zkclient，所以如果只有一个HConnection也意味着共享了zk client。

所以在通常情况下，若干个rowkeys进行访问时，出现Thread:RS  = M:N，如果所有rows在同一RS下，那么将出现Ｎ＝１，即会阻塞访问。

刚开始使用时不清楚此机制，所以我们一直自己建立threadpool来并发访问，看来这是没必要的。#1

 

 在HTablePool#getTAble()时，返回了一个封装了HTable的PooledTable，目的是为了可以在close（）时可以进行干预：供PoolMap post process。以便进行回推还是按照maxsize直接抛弃。而对PooledHTable的使用时，直接使用组合方式（内嵌）的HTable，所以对客户端而言是透明的。

HTable内在threadpool，所以在进行访问时相同RS的会直接打包到一个caller下便于直接访问。所以如果同一次访问的rowkyes很大而且刚好命中在同一ＲＳ，那么使用#1处理方式很有必要。

 

 由于使用HTablePool建立的HTable默认是autoFlush=true，所以在执行过程中没有必要立即调用flushCommits()，因为在close()时会默认执行了。另外如果对数据没有严格的安全要求，也可以不必总调用close()来结束操作，可以在系统完毕后再利用一个shutdown hook即可。这样对提高整体入库速度是有提高的。

 

 怎样保证Pool是线程安全?除了ThreadLocal外,ResulablePool已经extends了ConcurrentLinkedQueue;RoundRobin extends CopyOnWriteArrayList,故在二者上的操作其实基本上是直接访问parent的methods,所以是安全的.

 

 

 

Ref:

hbase HTablePool学习－2

HTablePool的实现分析

[HBase] HTable &&　HTablePool