我有帶有持久 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，但沒有任何實際好處考慮到我的流量會持續增長，如何防止處理時間在重新連接期間增加以及這些錯誤的發生？
2 回答
縹緲止盈
TA貢獻2041條經驗 獲得超4個贊
云 bigtable 客戶端使用 gRPC 連接池連接到 bigtable。Java 客戶端為每個 HBase 連接使用一個通道池，每個通道池有多個 gRPC 連接。gRPC 連接每小時關閉一次（或在 15 分鐘不活動后），底層 gRPC 基礎設施執行重新連接。每個新連接上的第一個請求執行許多設置任務，例如 TLS 握手和預熱服務器端緩存。這些操作相當昂貴，可能會導致延遲峰值。
Bigtable 被設計成一個高吞吐量系統，這些重新連接和持續查詢量的攤銷成本應該可以忽略不計。但是，如果客戶端應用程序的 QPS 非常低或查詢之間的空閑時間很長并且不能容忍這些延遲峰值，它可以每 30-40 分鐘創建一個新的 Hbase 連接（java）或一個新的 CBT 客戶端（golang）并且在新連接/客戶端上不運行 op 調用（存在于 hbase 客戶端或讀取一小行）以啟動底層 gRPC 連接（每個連接調用一次，對于 hbase 默認是 CPU 數量的兩倍，默認情況下有 4 個連接） .?準備就緒后，您可以為客戶端應用程序中的主要操作換出新的連接/客戶端。
qq_花開花謝_0
TA貢獻1835條經驗 獲得超7個贊
我懷疑這可能是由于最近的 grpc-go 版本中引入了一個錯誤，并且剛剛得到修復?；旧希覀儧]有在連接斷開時立即重新連接，而是錯誤地等待 1 秒再重新連接。請用grpc-go master head再試一次。謝謝！
- 2 回答
- 0 關注
- 143 瀏覽
添加回答
舉報
0/150
提交
取消