Tair (Redis® OSS-Compatible)：資料分區節點故障對請求成功率的影響

假設叢集執行個體的資料分區數量為N，當其中1個資料分區節點發生故障時，該故障節點會啟動主備切換，從故障發生至完成切換大約需要幾秒到幾十秒。在該過程中，訪問該資料分區節點的請求均會失敗，假設請求分布均勻，理論上該執行個體會有 1/N 的請求失敗率。

但存在以下原因，可能導致該過程中實際失敗的請求數量高於理論值。本文以代理（Proxy）模式、2個資料分區節點的叢集舉例說明。

• 使用多Key命令

  • 代理模式：Proxy會將多Key命令拆分為多個子命令按照路由表分發給對應的資料分區節點。

  • 直連模式：用戶端會將對應子命令發送給對應資料分區節點。

  當多Key命令涉及節點故障時，該請求都會失敗，如下圖所示。

  最佳化方案：減少單個命令中Key的數量，降低資料分區節點故障時多Key命令的失敗機率。

• 用戶端使用單串連

  部分用戶端會採用單串連非同步發送請求，例如Lettuce。例如下圖中，2個GET請求先後通過一個串連發送給Proxy，由於Redis RESP協議要求請求和回複的順序一致，當GET key2請求因為節點故障無法返回時，GET key2之後的請求即使已成功執行，用戶端也無法收到其響應。

  最佳化方案：使用Jedis等支援串連池模型的用戶端。

• 用戶端串連池資源耗盡

  對於串連池模型的用戶端，存在最大串連數的配置，當串連數達到最大且沒有空閑串連時，新請求會失敗或阻塞。

  下圖以Jedis用戶端為例，如果配置maxTotal = 3, timeout = 2000， 在2秒內發起3個GET key2請求，此時串連數已滿（串連池中所有串連都處於使用狀態），但由於某個節點故障無法返回，新的請求會根據blockWhenExhausted配置直接失敗或阻塞，從而導致使用者端請求失敗或逾時。

  最佳化方案：合理配置JedisPool資源集區大小，適當降低timeout配置，例如200-300（單位ms，Jedis預設為2000），實現快速失敗，避免故障時大量串連處於阻塞狀態。