上篇博文结合一起线上问题介绍了HBase客户端基于退避算法的重试机制，并分析得出在某些场景下如果重试策略设置不当会导致长时间的业务阻塞。除了重试机制外，业务童鞋最关心的就是超时机制了。客户端超时设置对整个系统的稳定性以及敏感性至关重要，一旦没有超时设置或超时时间设置过长，服务器端的长时间卡顿必然会引起客户端阻塞等待，进而影响上层应用。好在HBase提供了多个客户端参数设置超时，主要包括 hbase.rpc.timeout / hbase.client.operation.timeout / hbase.client.scanner.timeout.period。然而这些参数官方并没有给出具体的介绍，导致开发人员并不真正理解这些参数的含义。接下来本文分别对这三个参数进行介绍，应用童鞋可以根据自己的实际情况对这三个参数进行设置。
hbase.rpc.timeout
从字面意思就可知道，该参数表示一次RPC请求的超时时间。如果某次RPC时间超过该值，客户端就会主动关闭socket。此时，服务器端就会捕获到如下的异常：
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:197)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:384)
at org.apache.hadoop.hbase.ipc.RpcServer.channelRead(RpcServer.java:2246)
at org.apache.hadoop.hbase.ipc.RpcServer$Connection.readAndProcess(RpcServer.java:1496)
....
2016-04-14 21:32:40,173 WARN [B.DefaultRpcServer.handler=125,queue=5,port=60020] ipc.RpcServer: RpcServer.respondercallId: 7540 service: ClientService methodName: Multi size: 100.2 K connection: 10.160.247.139:56031: output error
2016-04-14 21:32:40,173 WARN [B.DefaultRpcServer.handler=125,queue=5,port=60020] ipc.RpcServer: B.DefaultRpcServer.handler=125,queue=5,port=60020: caught a ClosedChannelException, this means that the server was processing a request but the client went away. The error message was: null
上述异常经常发生在大量高并发读写业务或者服务器端发生了比较严重的Full GC等场景下，导致某些请求无法得到及时处理，超过了时间间隔。该值默认大小为60000ms，即1min。
hbase.client.operation.timeout
该参数表示HBase客户端发起一次数据操作直至得到响应之间总的超时时间，数据操作类型包括get、append、increment、delete、put等。很显然，hbase.rpc.timeout表示一次RPC的超时时间，而hbase.client.operation.timeout则表示一次操作的超时时间，有可能包含多个RPC请求。举个例子说明，比如一次Put请求，客户端首先会将请求封装为一个caller对象，该对象发送RPC请求到服务器，假如此时因为服务器端正好发生了严重的Full GC，导致这次RPC时间超时引起SocketTimeoutException，对应的就是hbase.rpc.timeout。那假如caller对象发送RPC请求之后刚好发生网络抖动，进而抛出网络异常，HBase客户端就会进行重试，重试多次之后如果总操作时间超时引起SocketTimeoutException，对应的就是hbase.client.operation.timeout。
hbase.client.scanner.timeout.period
看到这里为止，很多细心的童鞋都会发现，hbase.client.operation.timeout参数规定的超时基本涉及到了HBase所有的数据操作，唯独没有scan操作。然而scan操作却是最有可能发生超时的，也因此是用户最为关心的。HBase当然考虑到了这点，并提供了一个单独的超时参数进行设置：hbase.client.scanner.timeout.period。这个参数理解起来稍微有点复杂，需要对scan操作本身有比较全面的理解，这可能也是很多业务用户并不了解的地方。
首先，我们来看一个最简单的scan操作示例：
public static void scan() {
HTable table=(HTable) getHTablePool().getTable("tb_stu");
Scan scan=new Scan();
scan.setMaxResultSize(10000);
scan.setCacheing(500);
ResultScanner rs = table.getScanner(scan);
for (Result r : rs) {
for (KeyValue kv : r.raw()) {
System.out.println(String.format("row:%s, family:%s, qualifier:%s, qualifiervalue:%s, timestamp:%s.”,
Bytes.toString(kv.getRow()),
Bytes.toString(kv.getFamily()),
Bytes.toString(kv.getQualifier()),
Bytes.toString(kv.getValue()),
kv.getTimestamp()));
｝
｝
}
很多人都会误认为一次scan操作就是一次RPC请求，实际上，一次请求大量数据的scan操作可能会导致多个很严重的后果：服务器端可能因为大量io操作导致io利用率很高，影响其他正常业务请求；大量数据传输会导致网络带宽等系统资源被大量占用；客户端也可能因为内存无法缓存这些数据导致OOM。基于此，HBase会将一次大的scan操作根据设置条件拆分为多个RPC请求，每次只返回规定数量的结果。上述代码中foreach(Result r ：rs)语句实际上等价于Result r = rs.next()，每执行一次next()操作就会调用客户端发送一次RPC请求，参数hbase.client.scanner.timeout.period就用来表示这么一次RPC请求的超时时间，默认为60000ms，一旦请求超时，就会抛出SocketTimeoutException异常。
讲到这里，就借用宝地引申地讲讲另外两个相关的问题：
1. 上文提到一次大的scan操作会被拆分为多个RPC请求，那到底会拆分为多少个呢？
一次scan请求的RPC次数主要和两个因素相关，一个是本次scan的待检索条数，另一个是单次RPC请求的数据条数，很显然，两者的比值就是RPC请求次数。
一次scan的待检索条数由用户设置的条件决定，比如用户想一次获取某个用户最近一个月的所有操作信息，这些信息总和为10w条，那一次scan总扫瞄条数就是10w条。为了防止一次scan操作请求的数据量太大，额外提供了参数maxResultSize对总检索结果大小进行限制，该参数表示一次scan最多可以请求的数据量大小，默认为-1，表示无限制。
单次RPC请求的数据条数由参数caching设定，默认为100条。因为每次RPC请求获取到数据都会缓存到客户端，因此该值如果设置过大，可能会因为一次获取到的数据量太大导致客户端内存oom；而如果设置太小会导致一次大scan进行太多次RPC，网络成本高。
具体使用可以参考上文代码示例。
2. 经常有业务童鞋问道，在scan过程中RegionServer端偶尔抛出leaseException，是怎么回事？
看到leaseException就会想到租约机制，的确，HBase内部在一次完整的scan操作中引入了租约机制。为什么需要租约机制？这和整个scan操作流程有莫大的关系，上文讲到，一次完整的scan通常会被拆分为多个RPC请求，实际实现中，RegionServer接收到第一次RPC请求之后，会为该scan操作生成一个全局唯一的id，称为scanId。除此之外，RegionServer还会进行大量的准备工作，构建整个scan体系，构造需要用到的所有对象，后续的RPC请求只需要携带相同的scanId作为标示就可以直接利用这些已经构建好的资源进行检索。也就是说，在整个scan过程中，客户端其实都占用着服务器端的资源，此时如果此客户端意外宕机，是否就意味着这些资源永远都不能得到释放呢？租约机制就是为了解决这个问题。RegionServer接收到第一次RPC之后，除了生成全局唯一的scanId之外还会生成一个携带有超时时间的lease，超时时间可以通过参数hbase.regionserver.lease.period配置，一旦在超时时间内后续RPC请求没有到来（比如客户端处理太慢），RegionServer就认为客户端出现异常，此时会将该lease销毁并将整个scan所持有的资源全部释放，客户端在处理完成之后再发后续的RPC过来，检查到对应的lease已经不存在，就会抛出如下leaseExcption：
org.apache.hadoop.hbase.regionserver.LeaseException: lease '-8841369309248784313’ does not exist
at org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:230)
at org.apache.hadoop.hbase.regionserver.HRegionServer.next(HRegionServer.java:1847)
at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.hadoop.hbase.ipc.HBaseRPC$Server.call(HBaseRPC.java:570)
at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1039)
写在最后
一旦发生超时异常，很多童鞋的第一反应是会将超时时间设长。可以负责任的说，这样的处理是盲目的，不仅不能从本质上解决问题，还会使得整个系统处于特别不敏感的状态，在某些异常情况下，客户端就会因为超时时间设置太长而一直阻塞，进而导致上层业务长时间卡顿。因此在大多数情况下都不建议将超时时间设大，推荐的方法是找到超时的原因，分析超时原因是否可以避免。
文章最后再说说如何设置超时，用户可以通过修改配置文件hbase-site.xml来设置这几个参数，也可以通过代码的方式进行设置，如下所示：
Confiuration conf = HBaseConfiguration.create();
conf.setInt("hbase.rpc.timeout",20000);
conf.setInt("hbase.client.operation.timeout”,30000);
conf.setInt("hbase.client.scanner.timeout.period",20000);
HTable table = new HTable(conf,"tableName");
…
