【Azure Redis 緩存】C#程式是否有對應的方式來優化并縮短由于 Redis 維護造成的不可通路的時間

問題描述

C#程式是否有對應的方式來優化并縮短由于 Redis 維護造成的不可通路的時間？

Redis維護說明：

Redis 服務維護時，會把副本節點提升為主節點，且舊主節點關閉現有連接配接時，這個時候，原有用戶端的所有連接配接都将斷開，并通過用戶端Retry機制馬上連接配接到新的主節點，這個過程被稱為故障轉移。

計劃的故障轉移發生在兩個不同的時間：

• 系統更新，例如 Redis 修補或 OS 更新。
• 管理操作，例如縮放和重新啟動。

正常情況下，故障轉移的時間在1秒左右完成，如果出現異常，則需要10-15秒完成。

但是，并不是所有的用戶端都能在發生故障轉移後馬上恢複連接配接，是以就需要考慮沖用戶端代碼，配置方面來優化此種情況所帶來的後果。

問題解答

在Azure官方文檔中，C# 連接配接Redis的用戶端工具為 StackExchange.Redis， 文章中對它有比較詳細的說明：

1. 在極少數情況下，Stackexchange.redis 在連接配接中斷後無法重新連接配接。 在這些情況下，重新啟動用戶端或建立新的 

   ConnectionMultiplexer

    可解決此問題。 建議使用單一執行個體 

   ConnectionMultiplexer

    模式，同時允許應用定期強制重新連接配接。

2. ConnectionMultiplexer

    的使用者必須處理因處置該類的舊執行個體而可能發生的任何 

   ObjectDisposedException

    錯誤。
3. 針對 

   RedisConnectionExceptions

    和 

   RedisSocketExceptions

    調用 

   ForceReconnectAsync()

   。 也可以針對 

   RedisTimeoutExceptions

    調用 

   ForceReconnectAsync()

   ，但前提是你使用大量的 

   ReconnectMinInterval

    和 

   ReconnectErrorThreshold

   。 否則，建立新連接配接可能會導緻逾時的伺服器發生連鎖故障，因為伺服器已過載。

詳見：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-best-practices-connection#using-forcereconnect-with-stackexchangeredis

Demo參考：https://github.com/Azure-Samples/azure-cache-redis-samples/tree/main/quickstart/dotnet-core

當在複雜的環境中面臨問題，格物之道需：濁而靜之徐清，安以動之徐生。 雲中，恰是如此!