原文地址：http://wangneng-168.iteye.com/blog/2067746
超时时间、重试次数、重试时间间隔的配置也比较重要，因为默认的配置的值都较大，如果出现hbase集群或者RegionServer以及ZK关掉，则对应用程序是灾难性的，超时和重新等会迅速占满web容器的链接，导致web容器停止服务，关于socket的超时时间，有两种：1：建立连接的超时时间；2：读数据的超时时间。
可以配置如下几个参数：
1. hbase.rpc.timeout：rpc的超时时间，默认60s，不建议修改，避免影响正常的业务，在线上环境刚开始配置的是3秒，运行半天后发现了大量的timeout error，原因是有一个region出现了如下问题阻塞了写操作：“Blocking updates … memstore size 434.3m is >= than blocking 256.0m size”可见不能太低。
2. ipc.socket.timeout：socket建立链接的超时时间，应该小于或者等于rpc的超时时间，默认为20s
3. hbase.client.retries.number：重试次数，默认为14，可配置为3
4. hbase.client.pause：重试的休眠时间，默认为1s，可减少，比如100ms
5. zookeeper.recovery.retry：zk的重试次数，可调整为3次，zk不轻易挂，且如果hbase集群出问题了，每次重试均会对zk进行重试操作，zk的重试总次数是：hbase.client.retries.number * zookeeper.recovery.retry，并且每次重试的休眠时间均会呈2的指数级增长，每次访问hbase均会重试，在一次hbase操作中如果涉及多次zk访问，则如果zk不可用，则会出现很多次的zk重试，非常浪费时间。
6. zookeeper.recovery.retry.intervalmill：zk重试的休眠时间，默认为1s，可减少，比如：200ms
7. hbase.regionserver.lease.period：scan查询时每次与server交互的超时时间，默认为60s，可不调整。
RPC的重试间隔策略：
public static long getPauseTime(final long pause, final int tries) {
int ntries = tries;
// RETRY_BACKOFF[] = { 1, 1, 1, 2, 2, 4, 4, 8, 16, 32, 64 }
if (ntries >= HConstants.RETRY_BACKOFF.length) {
ntries = HConstants.RETRY_BACKOFF.length - 1;
}
long normalPause = pause * HConstants.RETRY_BACKOFF[ntries];
long jitter = (long)(normalPause * RANDOM.nextFloat() * 0.01f); // 1% possible jitter
return normalPause + jitter;
}
ZK的重试间隔策略：
// RetryCounter类
//休眠时间随着重试次数呈2的指数级增长，第一次重试的休眠时间是配置参数的2倍
public void sleepUntilNextRetry() throws InterruptedException {
int attempts = getAttemptTimes();
long sleepTime = (long) (retryIntervalMillis * Math.pow(2, attempts));
timeUnit.sleep(sleepTime);
}
// retriesRemaining，默认值为maxReties，每次重试后减1
public int getAttemptTimes() {
return maxRetries-retriesRemaining+1;
}
