Как обрабатывать почасовое закрытие Bigtable?

Я подозреваю, что это может быть связано с ошибкой , которая появилась в недавнем выпуске grpc-go и только что исправила . По сути, вместо того, чтобы немедленно восстанавливать соединение, когда соединение разрывается, мы неправильно ждем 1 с перед повторным подключением. Пожалуйста, попробуйте еще раз с мастер-головой grpc-go. Спасибо!

Клиенты bigtable в облаке используют пул соединений gRPC для подключения к bigtable. Java-клиент использует пул каналов для каждого соединения HBase, каждый пул каналов имеет несколько соединений gRPC. Соединения gRPC отключаются каждый час (или через 15 минут бездействия), и базовая инфраструктура gRPC выполняет переподключение. Первый запрос для каждого нового соединения выполняет ряд задач настройки, таких как квитирование TLS и прогрев кэшей на стороне сервера. Эти операции довольно дороги и могут вызвать всплески задержки.

Bigtable спроектирован как система с высокой пропускной способностью, и амортизированная стоимость этих повторных соединений с постоянным объемом запросов должна быть незначительной. Однако, если клиентское приложение имеет очень низкий QPS или длительные периоды простоя между запросами и не может допустить эти пики задержки, оно может создавать новое соединение Hbase (java) или новый клиент CBT (golang) каждые 30-40 минут и не запускать операционные вызовы (существуют на клиенте hbase или прочитать небольшую строку) на новом соединении / клиенте, чтобы заполнить базовые соединения gRPC (один вызов на соединение, для hbase по умолчанию вдвое больше процессоров, go по умолчанию имеет 4 соединения) , После заполнения вы можете поменять новое соединение / клиент для основных операций в клиентском приложении. Здесь - пример кода перехода для этого обходного пути.