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

【问题标题】：How to handle hourly Bigtable connection closes?如何处理每小时关闭的 Bigtable 连接？
【发布时间】：2019-07-25 00:14:42
【问题描述】：

我有带有持久性 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，但没有真正的好处

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

【问题讨论】：

标签： go grpc google-cloud-bigtable

【解决方案1】：

推荐的答案 Google Cloud

Cloud bigtable 客户端使用 gRPC 连接池连接到 bigtable。 Java 客户端每个 HBase 连接使用一个通道池，每个通道池有多个 gRPC 连接。 gRPC 连接每小时（或 15 分钟不活动后）关闭，底层 gRPC 基础设施执行重新连接。每个新连接上的第一个请求都会执行许多设置任务，例如 TLS 握手和预热服务器端缓存。这些操作相当昂贵，可能会导致延迟高峰。

Bigtable 被设计为一个高吞吐量系统，这些重新连接和持续查询量的摊销成本应该可以忽略不计。但是，如果客户端应用程序的 QPS 非常低或查询之间的空闲时间很长并且不能容忍这些延迟峰值，它可以每 30-40 分钟创建一个新的 Hbase 连接（java）或一个新的 CBT 客户端（golang），并且在新连接/客户端上不运行任何操作调用（存在于 hbase 客户端或读取一小行）以启动底层 gRPC 连接（每个连接调用一次，对于 hbase 默认是 CPU 数量的两倍，go 默认有 4 个连接） .准备就绪后，您可以将新的连接/客户端换成客户端应用程序中的主要操作。 Here 是此解决方法的示例代码。

【讨论】：

【解决方案2】：

我怀疑这可能是由于在最近的 grpc-go 版本中引入了 bug，并且刚刚得到了 fixed。基本上，不是在连接消失时立即重新连接，而是在重新连接之前错误地等待 1 秒。请用 grpc-go master head 再试一次。谢谢！

【讨论】：