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客户端超时,感谢原作者分享。