這很重要
Azure Cache for Redis 宣布了所有 SKU 的淘汰時間表。 建議您儘快將現有的 Azure Cache for Redis 執行個體移至 Azure 受控 Redis 。
有關退役的更詳細資訊：
重試命令
設定客戶端連線，以指數退避方式重試命令。 如需詳細資訊，請參閱 重試指導方針。
測試韌性
使用 重新啟動 來模擬修補程式，測試系統對連線中斷的復原能力。 如需測試效能的詳細資訊，請參閱 效能測試。
Linux 裝載用戶端應用程式的 TCP 設定
某些 Linux 版本中的預設 TCP 設定可能會導致 Redis 伺服器連線失敗 13 分鐘或更長時間。 預設設定可能會防止用戶端應用程式偵測已關閉的連線，並在連線未正常關閉時自動還原它們。
在網路連線中斷或 Redis 伺服器離線進行計劃外維護的情況下，可能會發生無法重新建立連線的情況。
我們建議使用下列 TCP 設定：
| Setting | 價值觀 |
|---|---|
net.ipv4.tcp_retries2 |
5 |
如需案例的詳細資訊，請參閱 在 Linux 上執行時 15 分鐘內不會重新建立連線。 雖然此討論是關於 StackExchange.Redis 程式庫，但在 Linux 上執行的其他用戶端程式庫也會受到影響。 該解釋仍然有用，您可以應用於其他函式庫。
將 ForceReconnect 與 StackExchange.Redis 搭配使用
在極少數情況下， StackExchange.Redis 在連線中斷後無法重新連線。 在這些情況下，重新啟動用戶端或建立新的 ConnectionMultiplexer 用戶端即可修正問題。 建議您使用單一模式 ConnectionMultiplexer ，同時允許應用程式定期強制重新連線。 請參閱最符合應用程式所使用的架構和平臺的快速入門範例專案。 您可以在我們的 快速入門中看到此程式碼模式的範例。
ConnectionMultiplexer 的使用者必須處理因處置舊錯誤而可能發生的任何 ObjectDisposedException 錯誤。
對 ForceReconnectAsync() 和 RedisConnectionExceptions 呼叫 RedisSocketExceptions。 您也可以對ForceReconnectAsync() 呼叫 RedisTimeoutExceptions，但僅限於使用寬裕的 ReconnectMinInterval 和 ReconnectErrorThreshold 時。 否則，在因為已超載而逾時的伺服器上，建立新的連線可能導致連鎖失敗。
在 ASP.NET 應用程式中，您可以使用 Microsoft.Extensions.Caching.StackExchangeRedis 套件中的整合實作，而不是直接使用 StackExchange.Redis 套件。 如果您在 ASP.NET 應用程式中使用 Microsoft.Extensions.Caching.StackExchangeRedis ，而不是直接使用 StackExchange.Redis ，您可以將屬性設定 UseForceReconnect 為 true：
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
設定適當的時間上限
在連線復原中，有兩個逾時值很重要： 連線逾時 和 命令逾時。
連線逾時
connect timeout 是用戶端等候與 Redis 伺服器建立連線的時間。 將用戶端程式庫設定為使用一個五秒的connect timeout，以便讓系統即使在較高的 CPU 負荷條件下，也有足夠的時間進行連線。
小 connection timeout 值並不能保證在該時間範圍內建立連線。 如果發生問題（高客戶端 CPU、高伺服器 CPU 等），則短 connection timeout 值會導致連線嘗試失敗。 這種行為往往會使糟糕的情況變得更糟。 較短的逾時非但沒有提供幫助，反而會強制系統重新啟動嘗試重新連線的過程，從而加劇問題，這可能導致 連線-> 失敗-> 重試 迴圈。
命令逾時
大多數客戶端庫都有另一個逾時配置 command timeouts，即客戶端等待來自 Redis 伺服器的回應的時間。 雖然我們建議初始設定少於五秒，但請考慮根據您的案例和快取中儲存的值大小來設定較高或較低的值 command timeout 。
如果 command timeout 過小，可能會導致連接不穩定。 不過，如果 command timeout 過大，您的應用程式可能需要等待很長時間才能確定命令是否會逾時。
避免用戶端連線尖峰
避免在連線中斷後重新連線時同時建立許多連線。 與 短暫的連線逾時 可能導致較長的中斷類似，同時啟動許多重新連線嘗試也會增加伺服器負載，並延長所有用戶端順利重新連線所需的時間。
如果您需要重新連接多個用戶端執行個體，建議考慮分散新建立的連接，以避免連線的用戶端數量急劇增加。
備註
當您使用 StackExchange.Redis 用戶端程式庫時，請在連接字串中設定abortConnect為 。false 我們建議讓 ConnectionMultiplexer 處理重新連接。 如需詳細資訊，請參閱 StackExchange.Redis 最佳實務。
避免剩餘連接
快取對每個快取層的用戶端連線數目有限制。 請確定當您的用戶端應用程式重新建立連線時，它會關閉並移除舊的連線。
提前維護通知
使用通知來了解即將進行的維護。 如需詳細資訊，請參閱 是否可以提前獲得計劃維護通知。
排程維護時段
調整快取設定以適應維護。 如需有關建立維護時段以減少對快取造成任何負面影響的詳細資訊，請參閱 更新通道和排程更新。
更多彈性設計模式
套用設計模式以取得復原能力。 如需詳細資訊，請參閱如何 讓應用程式具有復原能力。
閒置逾時
Azure Cache for Redis 的閒置連線逾時時間為 10 分鐘。 10 分鐘逾時可讓伺服器自動清除外洩連線或用戶端應用程式孤立的連線。 大多數 Redis 用戶端程式庫都有內建功能，可以定期傳送 heartbeat 或 keepalive 命令，以防止連線關閉，即使沒有來自用戶端應用程式的請求。
如果您的連線有閒置 10 分鐘的任何風險，請將間隔設定 keepalive 為小於 10 分鐘的值。 如果您的應用程式使用的用戶端程式庫沒有原生支援 keepalive 功能，您可以在應用程式中定期傳送 PING 命令來實作它。