hbase虚拟分布式模式需要几个节点，HBase之超时机制

客户端超时设置对整个系统的稳定性以及敏感性至关重要，一旦没有超时设置或超时时间设置过长，服务器端的长时间卡顿必然会引起客户端阻塞等待，进而影响上层应用。好在HBase提供了多个客户端参数设置超时，主要包括 hbase.rpc.timeout / hbase.client.operation.timeout/ hbase.client.scanner.timeout.period

一 hbase.rpc.timeout

表示一次RPC请求的超时时间，如果某一次RPC请求超过该值，客户端就会主动关闭socket，此时服务器端就会捕获到如下的异常：

hbase虚拟分布式模式需要几个节点？上述异常经常发生在大量高并发读写业务或者服务器端发生了比较严重的Full GC等场景下，导致某些请求无法得到及时处理，超过了时间间隔。该值默认大小为60000ms，即1min。

二 hbase.client.operation.timeout

参数表示HBase客户端发起一次数据操作直至得到响应之间总的超时时间，数据操作类型包括get、append、increment、delete、put等。很显然，hbase.rpc.timeout表示一次RPC的超时时间，而hbase.client.operation.timeout则表示一次操作的超时时间，有可能包含多个RPC请求

三 hbase.client.scanner.timeout.period

hbase并发性能。hbase.client.operation.timeout参数规定的超时基本涉及到了HBase所有的数据操作，唯独没有scan操作。然而scan操作却是最有可能发生超时的，也因此是用户最为关心的。HBase当然考虑到了这点，并提供了一个单独的超时参数进行设置：hbase.client.scanner.timeout.

period

publicList<String> scan(StringtableName,String startRow, StringstopRow,String family, Stringqualifier) throws IOException{

       if (StringUtils.isBlank(tableName)) {

              System.err.println("table isblank!");

             return null;

       }

       if (StringUtils.isBlank(family)) {

              System.err.println("family isblank!");

             return null;

       }

       if (StringUtils.isBlank(qualifier)) {

              System.err.println("qualifieris blank!");

             return null;

       }

       Scanscan = newScan(Bytes.toBytes(startRow), Bytes.toBytes(stopRow));

       TableNametn= TableName.valueOf(tableName);

       Table table = this.conn.getTable(tn);

       ResultScanner scanner = table.getScanner(scan);

       List<String> valList = new ArrayList<String>();

       Stringdata = null;

       for (Result : scanner) {

             byte[] arr =result.getValue(Bytes.toBytes(family), Bytes.toBytes(qualifier));

             data = Bytes.toString(arr);

             valList.add(data);

       }

       table.close();

       return valList;

}

很多人都会误认为一次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异常

hbase 时序数据库。四 scan 请求是怎么拆分的呢？

一次scan请求的RPC次数主要和两个因素相关，一个是本次scan的待检索条数，另一个是单次RPC请求的数据条数，很显然，两者的比值就是RPC请求次数。

redis数据超时机制，一次scan的待检索条数由用户设置的条件决定，比如用户想一次获取某个用户最近一个月的所有操作信息，这些信息总和为10w条，那一次scan总扫瞄条数就是10w条。为了防止一次scan操作请求的数据量太大，额外提供了参数maxResultSize对总检索结果大小进行限制，该参数表示一次scan最多可以请求的数据量大小，默认为-1，表示无限制。

hbase时间戳？单次RPC请求的数据条数由参数caching设定，默认为100条。因为每次RPC请求获取到数据都会缓存到客户端，因此该值如果设置过大，可能会因为一次获取到的数据量太大导致客户端内存oom；而如果设置太小会导致一次大scan进行太多次RPC，网络成本高。

五 在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：