如何处理每小时 Bigtable 连接关闭？
How to handle hourly Bigtable connection closes?
我有带有持久 Bigtable 客户端的 golang 服务。
这些服务每秒在 Bigtable 上进行数百次 read/write 操作。
服务启动后的每个小时，我都会遇到数百个这样的错误：
Retryable error: rpc error: code = Unavailable desc =
the connection is draining, retrying in 74.49241ms
错误之后会增加处理时间，我不能允许发生这些错误。
我发现 Bigtable 客户端正在使用 gRPC 连接池。
似乎 Bigtable gRPC 服务器的连接 maxAge 为 1 小时，这可以解释上述错误以及重新连接期间处理时间增加。
maxAgeGrace 配置应该提供额外的时间来完成当前操作并避免所有池连接同时终止。
我将连接池大小从默认的 4 增加到 12，但没有任何实际好处
考虑到我的流量将继续增长，如何防止重新连接期间处理时间增加以及这些错误的发生？
我怀疑这可能是由于 bug that gets introduced in a recent grpc-go release, and just got fixed。基本上，我们没有在连接消失时立即重新连接，而是错误地等待 1 秒再重新连接。请用grpc-go master head再试一次。谢谢！
云 bigtable 客户端使用 gRPC 连接池连接到 bigtable。 Java 客户端为每个 HBase 连接使用一个通道池，每个通道池有多个 gRPC 连接。 gRPC 连接每小时关闭一次（或在 15 分钟不活动后），底层 gRPC 基础设施执行重新连接。每个新连接上的第一个请求执行许多设置任务，例如 TLS 握手和预热服务器端缓存。这些操作相当昂贵，可能会导致延迟峰值。
Bigtable 被设计成一个高吞吐量系统，这些重新连接和持续查询量的摊销成本应该可以忽略不计。但是，如果客户端应用程序的 QPS 非常低或查询之间的空闲时间很长并且不能容忍这些延迟峰值，它可以每 30 创建一个新的 Hbase 连接（java）或一个新的 CBT 客户端（golang） -40 分钟且 运行 新的 connection/client 上没有操作调用（存在于 hbase 客户端或读取一小行）来启动底层 gRPC 连接（每个连接调用一次，对于 hbase 默认值是两倍的 CPU，go 默认有 4 个连接）。准备就绪后，您可以为客户端应用程序中的主要操作换出新的 connection/client。 Here 是此解决方法的示例代码。
我有带有持久 Bigtable 客户端的 golang 服务。 这些服务每秒在 Bigtable 上进行数百次 read/write 操作。
服务启动后的每个小时，我都会遇到数百个这样的错误：
Retryable error: rpc error: code = Unavailable desc =
the connection is draining, retrying in 74.49241ms
错误之后会增加处理时间，我不能允许发生这些错误。
我发现 Bigtable 客户端正在使用 gRPC 连接池。
似乎 Bigtable gRPC 服务器的连接 maxAge 为 1 小时，这可以解释上述错误以及重新连接期间处理时间增加。
maxAgeGrace 配置应该提供额外的时间来完成当前操作并避免所有池连接同时终止。
我将连接池大小从默认的 4 增加到 12，但没有任何实际好处
考虑到我的流量将继续增长，如何防止重新连接期间处理时间增加以及这些错误的发生？
我怀疑这可能是由于 bug that gets introduced in a recent grpc-go release, and just got fixed。基本上，我们没有在连接消失时立即重新连接，而是错误地等待 1 秒再重新连接。请用grpc-go master head再试一次。谢谢！
云 bigtable 客户端使用 gRPC 连接池连接到 bigtable。 Java 客户端为每个 HBase 连接使用一个通道池，每个通道池有多个 gRPC 连接。 gRPC 连接每小时关闭一次（或在 15 分钟不活动后），底层 gRPC 基础设施执行重新连接。每个新连接上的第一个请求执行许多设置任务，例如 TLS 握手和预热服务器端缓存。这些操作相当昂贵，可能会导致延迟峰值。
Bigtable 被设计成一个高吞吐量系统，这些重新连接和持续查询量的摊销成本应该可以忽略不计。但是，如果客户端应用程序的 QPS 非常低或查询之间的空闲时间很长并且不能容忍这些延迟峰值，它可以每 30 创建一个新的 Hbase 连接（java）或一个新的 CBT 客户端（golang） -40 分钟且 运行 新的 connection/client 上没有操作调用（存在于 hbase 客户端或读取一小行）来启动底层 gRPC 连接（每个连接调用一次，对于 hbase 默认值是两倍的 CPU，go 默认有 4 个连接）。准备就绪后，您可以为客户端应用程序中的主要操作换出新的 connection/client。 Here 是此解决方法的示例代码。