Question

我拥有持久性Bigtable客户端的golang服务。服务正在每秒对Bigtable进行数百次读/写操作。

从服务启动开始的每个小时，我都会遇到上百个这样的错误：

public class Head {
    private float headThickness=0;
    private float headThicknessTolerance=0;

    private ShapeOfHead headShape;
    private float knuckleRadius=0;
    private int numberOfHeadPieces=4;
    private HeadSide headSide;

    private Figure8_1WeldingDetails headLongitudinalWeld;
    private Figure9_1WeldingDetails headCircumferentialWeld;

    private Bracing headBracing;
}

public class DishedHead extends Head {
    private float dishedHeadDepth;  
}

public class ConicalHead extends Head {
    private float conicalHeadHeight;
}

出现错误后会增加处理时间，这些错误发生时我不允许这样做。

我能够确定Bigtable客户端正在使用gRPC连接池。

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

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

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

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

Answer 1

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

Bigtable被设计为一个高吞吐量的系统，这些具有持续查询量的重新连接的摊销成本应该可以忽略不计。但是，如果客户端应用程序具有非常低的QPS或查询之间的长时间闲置时间，并且不能忍受这些延迟尖峰，则可以每30-40分钟创建一个新的Hbase连接（java）或新的CBT客户端（golang），并且在新的连接/客户端上不运行任何op调用（存在于hbase客户端上或读取一小行）以启动基础gRPC连接（每个连接一个调用，对于hbase默认是CPU数量的两倍，默认情况下go具有4个连接）。启动后，您可以将新的连接/客户端换成客户端应用程序中的主要操作。 Here是此变通办法的示例代码。

Answer 2

我怀疑这可能是由于bug在最近的grpc-go版本中引入的，而只是得到了fixed。基本上，我们没有在连接断开时立即重新连接，而是错误地等待了1秒再重新连接。请使用grpc-go主机头重试。谢谢！

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

2 个答案: