我有帶有持久 Bigtable 客戶端的 golang 服務(wù)。這些服務(wù)每秒對 Bigtable 進(jìn)行數(shù)百次讀/寫操作。從服務(wù)啟動后的每一個小時，我都會遇到數(shù)百個這樣的錯誤：Retryable error: rpc error: code = Unavailable desc =
the connection is draining, retrying in 74.49241ms當(dāng)這些錯誤發(fā)生時，錯誤之后是我不允許的處理時間增加。我能夠弄清楚 Bigtable 客戶端正在使用 gRPC 連接池。似乎 Bigtable gRPC 服務(wù)器的連接 maxAge 為 1 小時，這可以解釋上述錯誤以及重新連接期間處理時間的增加。maxAgeGrace 配置應(yīng)該為完成當(dāng)前操作提供額外的時間，并避免所有池連接同時終止。我將連接池大小從默認(rèn)的 4 增加到 12，但沒有任何實(shí)際好處考慮到我的流量會持續(xù)增長，如何防止處理時間在重新連接期間增加以及這些錯誤的發(fā)生？
2 回答
縹緲止盈
TA貢獻(xiàn)2041條經(jīng)驗(yàn) 獲得超4個贊
云 bigtable 客戶端使用 gRPC 連接池連接到 bigtable。Java 客戶端為每個 HBase 連接使用一個通道池，每個通道池有多個 gRPC 連接。gRPC 連接每小時關(guān)閉一次（或在 15 分鐘不活動后），底層 gRPC 基礎(chǔ)設(shè)施執(zhí)行重新連接。每個新連接上的第一個請求執(zhí)行許多設(shè)置任務(wù)，例如 TLS 握手和預(yù)熱服務(wù)器端緩存。這些操作相當(dāng)昂貴，可能會導(dǎo)致延遲峰值。
Bigtable 被設(shè)計(jì)成一個高吞吐量系統(tǒng)，這些重新連接和持續(xù)查詢量的攤銷成本應(yīng)該可以忽略不計(jì)。但是，如果客戶端應(yīng)用程序的 QPS 非常低或查詢之間的空閑時間很長并且不能容忍這些延遲峰值，它可以每 30-40 分鐘創(chuàng)建一個新的 Hbase 連接（java）或一個新的 CBT 客戶端（golang）并且在新連接/客戶端上不運(yùn)行 op 調(diào)用（存在于 hbase 客戶端或讀取一小行）以啟動底層 gRPC 連接（每個連接調(diào)用一次，對于 hbase 默認(rèn)是 CPU 數(shù)量的兩倍，默認(rèn)情況下有 4 個連接） .?準(zhǔn)備就緒后，您可以為客戶端應(yīng)用程序中的主要操作換出新的連接/客戶端。
qq_花開花謝_0
TA貢獻(xiàn)1835條經(jīng)驗(yàn) 獲得超7個贊
我懷疑這可能是由于最近的 grpc-go 版本中引入了一個錯誤，并且剛剛得到修復(fù)?；旧希覀儧]有在連接斷開時立即重新連接，而是錯誤地等待 1 秒再重新連接。請用grpc-go master head再試一次。謝謝！
- 2 回答
- 0 關(guān)注
- 153 瀏覽
添加回答
舉報(bào)
0/150
提交
取消