HBase 客户端是一个有点混乱的层，其中包含意外的嵌套重试、嵌套连接池等。混合在一起的是与 Zookeeper 整体的连接。重要的是要意识到客户端直接处理
HBase 客户端是一个有点混乱的层，其中包含意外的嵌套重试、嵌套连接池等。混合的是与 Zookeeper 整体的连接。
重要的是要认识到客户端直接处理与 RegionServer 的所有通信，服务器端没有代理。因此，客户端需要进行服务发现和缓存以及必要的连接和线程管理。因此，一些复杂性是可以理解的：客户端是
集群的一部分。
另请参阅此博客文章。在 HBASE-5682 之前，客户端在无法访问集群时可能永远无法恢复。在 HBASE-4805 和 HBASE-6326 之前，出于良心，客户端无法在长时间运行的 ApplicationServer 中使用。
任何客户端库的一个重要方面就是我所说的“异常时间” ”。如果出现问题，客户端应该（至少作为一个选项）快速失败，并让具有必要语义上下文的调用应用程序决定如何处理这种情况。
不幸的是，HBase 和 Zookeeper 客户端没有设计时考虑到了这一点。
各种超时包括：
- ZK 会话超时 (zookeeper.session.timeout)
- RPC 超时 (hbase.rpc) .timeout)
- RecoverableZookeeper 重试计数和重试等待 (zookeeper.recovery.retry、zookeeper.recovery.retry.intervalmill)
- 客户端重试计数和等待 (hbase.client.retries.number, hbase.client.pause)
在某些错误路径中，这些重试循环是嵌套的，因此在默认设置中，如果 ZK 和 HBase 都关闭，客户端将在 20 分钟后抛出异常！应用程序没有机会以任何有意义的方式对中断做出反应。
HBASE-6326 修复了一个问题，其中 .META. -ROOT- 查找将被嵌套，每次都会导致 ZK 超时 N^2 次（N 是客户端重试次数，默认为 10），它本身将由 RecoverableZookeeper 重试（默认为 3）。
其中一些设置的默认值针对各种服务器端组件进行了优化。如果网络“闪烁”五秒钟，RegionServer 不应自行中止。因此，180 秒的会话超时是有意义的。
对于在无状态 ApplicationServer 内运行的客户端，设计目标是不同的。五秒的短超时似乎是合理的。快速检测到故障，应用程序可以做出反应（可能通过受控重试）。
通过上述各种 jiras 中的修复，现在可以（在 HBase 0.94 中）设置各种重试计数和超时到较低的值并获得相当短的时间跨度，之后客户端将向调用应用程序线程报告连接错误。
这实际上是当 HBaseClient（HTable 等）在 ApplicationServer 内用于 HBase 请求时应该执行的操作在调用线程中是同步的（例如从 HBase 提供数据的 Web 服务器）。
原文地址：HBase客户端超时，感谢原作者分享。
