如何处理每小时 Bigtable 连接关闭？

Question

我有带有持久 Bigtable 客户端的 golang 服务。这些服务每秒对 Bigtable 进行数百次读/写操作。

从服务启动后的每一个小时，我都会遇到数百个这样的错误：

Retryable error: rpc error: code = Unavailable desc =
 the connection is draining, retrying in 74.49241ms

当这些错误发生时，错误之后是我不允许的处理时间增加。

我能够弄清楚 Bigtable 客户端正在使用 gRPC 连接池。

似乎 Bigtable gRPC 服务器的连接 maxAge 为 1 小时，这可以解释上述错误以及重新连接期间处理时间的增加。

maxAgeGrace 配置应该为完成当前操作提供额外的时间，并避免所有池连接同时终止。

我将连接池大小从默认的 4 增加到 12，但没有任何实际好处

考虑到我的流量会持续增长，如何防止处理时间在重新连接期间增加以及这些错误的发生？

Answer 1

云 bigtable 客户端使用 gRPC 连接池连接到 bigtable。Java 客户端为每个 HBase 连接使用一个通道池，每个通道池有多个 gRPC 连接。gRPC 连接每小时关闭一次（或在 15 分钟不活动后），底层 gRPC 基础设施执行重新连接。每个新连接上的第一个请求执行许多设置任务，例如 TLS 握手和预热服务器端缓存。这些操作相当昂贵，可能会导致延迟峰值。Bigtable 被设计成一个高吞吐量系统，这些重新连接和持续查询量的摊销成本应该可以忽略不计。但是，如果客户端应用程序的 QPS 非常低或查询之间的空闲时间很长并且不能容忍这些延迟峰值，它可以每 30-40 分钟创建一个新的 Hbase 连接（java）或一个新的 CBT 客户端（golang）并且在新连接/客户端上不运行 op 调用（存在于 hbase 客户端或读取一小行）以启动底层 gRPC 连接（每个连接调用一次，对于 hbase 默认是 CPU 数量的两倍，默认情况下有 4 个连接） . 准备就绪后，您可以为客户端应用程序中的主要操作换出新的连接/客户端。

Answer 2

我怀疑这可能是由于最近的 grpc-go 版本中引入了一个错误，并且刚刚得到修复。基本上，我们没有在连接断开时立即重新连接，而是错误地等待 1 秒再重新连接。请用grpc-go master head再试一次。谢谢！