這很重要
Azure Cache for Redis 宣布了所有 SKU 的淘汰時間表。 建議您儘快將現有的 Azure Cache for Redis 執行個體移至 Azure 受控 Redis 。
有關退役的更詳細資訊：
若要建置復原性和成功的用戶端應用程式，請務必了解 Azure Cache for Redis 服務中的容錯移轉。 容錯移轉可以是計劃性管理作業的一環，或者非計劃性硬體或網路失敗導致容錯移轉。 管理服務修補 Azure Cache for Redis 二進位時，通常使用快取容錯移轉。
在本文中，您會找到以下資訊：
- 容錯移轉是什麼？
- 修補期間發生容錯移轉的原因。
- 如何建置有彈性的用戶端應用程式。
容錯移轉是什麼？
首先，我們要了解 Azure Cache for Redis 的容錯移轉概觀。
快取架構快速摘要
快取是由多個具有獨立且私人 IP 位址的虛擬機器組成。 每個虛擬機器 （也稱為節點） 都連線到具有單一虛擬 IP 位址的共用負載平衡器。 每個節點都會執行 Redis 伺服器處理程序，並可使用主機名稱和 Redis 連接埠來存取。 每個節點都被視為主要節點或複本節點。 當用戶端應用程式連線到快取時，其流量會通過此負載平衡器，並自動路由傳送至主要節點。
基本快取中的單一節點始終為主要節點。 在標準或高級快取中，將兩個節點中的一個選為主要節點，另一個則為複本節點。 由於標準和進階快取有多個節點，因此一個節點可能無法使用，而另一個節點則會繼續處理要求。 叢集快取是多個分區組成，每個分區有相異的主要和複本節點。 一個分片可能已停用，而其他分片仍然可用。
備註
基本快取沒有多個節點，且不提供快取可用性的服務等級協定 (SLA)。 建議僅將基本快取用於開發和測試目的。 使用標準或進階快取進行多節點部署，以提高可用性。
故障切換的說明
當複本節點將自己升級為主要節點，而舊的主要節點關閉現有連線時，就會發生容錯移轉。 主要節點備份後，該節點會發現角色中的變更，並自我降階為複本。 然後，它會連線到新的主要資料庫並同步資料。 故障切換可能是計劃內的，也可能是非計劃的。
「計劃性容錯移轉」會在兩個不同的時間執行：
- 系統更新，例如 Redis 修補或作業系統升級。
- 管理作業，例如擴展和重新啟動。
由於節點會提前收到更新通知，因此可以合作交換角色並快速更新變更的負載平衡器。 計劃的故障移轉通常會在不到 1 秒的時間內完成。
「非計劃性容錯移轉」可能發生的原因是硬體失敗、網路失敗或其他非預期的主要節點中斷。 複本節點會將自己提升為主要節點，但該過程需要更長的時間。 複本節點必須先偵測到其主要節點不再可用，才能啟動容錯移轉程序。 為避免不必要的容錯移轉，複本節點也必須驗證此非計劃性失敗不是暫時性或本機失敗。 此偵測延遲代表非計劃性容錯移轉通常會在 10 到 15 秒內完成。
修補過程是如何進行的？
適用於 Redis 的 Azure 快取服務會定期使用最新的平臺功能和修正來更新您的快取。 若要修補快取，服務會遵循下列步驟：
- 服務首先對複本節點進行修補。
- 修補的複本會以合作方式將自身提升為主要複本。 此升階視為計劃性容錯移轉。
- 先前的主要節點會重新開機以接受新的變更，並以複本節點的形式重新啟動。
- 複本節點連接至主節點並同步資料。
- 資料同步完成後，會針對其餘節點重複修補程序。
因為修補是計劃性容錯移轉，所以複本節點會快速自我升階為主要複本。 然後，節點開始為要求和新連線提供服務。 基本快取沒有複本節點，在更新完成之前無法使用。 叢集快取的每個分區都會個別修補，而且不會關閉與另一個分區的連線。
這很重要
節點逐個修補，以防止資料遺失。 基本緩存將丟失數據。 叢集快取一次修補一個分區。
相同資源群組和區域中的多個快取也是一次修補一個分區。 位於不同資源群組或不同區域時，快取可能會同時修補。
由於完整資料同步會在重複流程之前發生，因此當您使用標準或進階快取時，不太可能發生資料遺失。 您可以透過 匯出 資料並啟用 持久性來進一步防止資料遺失。
額外的快取負載
容錯移轉發生時，標準和進階快取必須將資料從一個節點複寫至另一個節點。 此複寫會導致伺服器記憶體和 CPU 的負載增加。 如果快取執行個體已經大量載入，用戶端應用程式可能會遇到延遲增加的情況。 在極端案例中，用戶端應用程式可能收到逾時例外狀況。 若要協助減輕更多負載的影響，請 設定 快取的 maxmemory-reserved 設定。
故障切換如何影響到我的用戶端應用程式？
用戶端應用程式可能會從 Azure Cache for Redis 收到一些錯誤。 用戶端應用程式看到的錯誤數目取決於容錯移轉時該連線上擱置的作業數目。 任何透過關閉連線的節點路由的連線都會出現錯誤。
許多用戶端程式庫可能會在連線中斷時擲回不同類型的錯誤，包括：
- 逾時例外狀況
- 連線例外狀況
- 通訊端例外狀況
例外狀況的數目和類型取決於快取關閉連線時，要求所在的位置在程式碼路徑中。 例如，發生容錯移轉時，傳送要求但尚未收到回應的作業可能會發生逾時例外狀況。 已關閉連線物件上的新要求會收到連線異常狀況，直到成功重新連線為止。
大部分的用戶端程式庫會嘗試重新連線快取 (如果程式庫已設定這麼做)。 不過，不可預見的錯誤有時會使程式庫物件進入無法復原的狀態。 如果錯誤持續超過預先設定的時間量，則應重新建立連線物件。 在 Microsoft.NET 和其他物件導向語言中，可以使用 ForceReconnect 模式來完成，而無需重新啟動應用程式即可重新建立連線。
我可以在維護之前收到通知嗎？
Azure Cache for Redis 會在名為 AzureRedisEvents的發佈/訂閱 （pub/sub） 通道上發佈執行階段維護通知。 許多流行的 Redis 客戶端庫都支持訂閱 pub/sub 頻道。 通常來說，將從 AzureRedisEvents 通道接收通知添加到您的用戶端應用程式是一項簡單的作業。 如需維護事件的詳細資訊，請參閱 AzureRedisEvents。
備註
該 AzureRedisEvents 頻道不是一種可以提前幾天或幾小時通知您的機制。 通道可以通知用戶端任何可能影響伺服器可用性的即將發生的伺服器維護事件。
AzureRedisEvents 僅適用於基本、標準和進階層級。
維護中包含哪些更新？
維護包括以下更新：
- Redis 伺服器更新：Redis 伺服器二進位檔的任何更新或修補程式。
- 虛擬機器 （VM） 更新：裝載 Redis 服務的虛擬機器的任何更新。 VM 更新包括在託管環境中為軟體元件打補丁、升級網路元件或停用。
在修補程式之前，維護是否會出現在 Azure 入口網站的服務健康狀態中？
否，維護不會出現在入口網站或任何其他位置中服務健康情況 下的任何位置。
在計劃性維護之前，我可以在多長時間內收到通知？
使用 AzureRedisEvents 頻道時，您會在維護前 15 分鐘收到通知。
用戶端網路組態變更
某些用戶端網路組態變更可能會觸發 [無連線可用 ] 錯誤。 此類變更可能包括：
- 在暫存和生產插槽之間交換用戶端應用程式的虛擬 IP 位址。
- 調整應用程式執行個體的大小或數目。
此類變更可能會導致通常持續不到一分鐘的連線問題。 您的用戶端應用程式可能會失去與其他外部網路資源的連線，也可能會失去與 Azure Redis 快取服務的連線。
建立復原能力
您無法完全避免故障轉移。 相反地，請撰寫具備強韌性的用戶端應用程式，以便在連線中斷和要求失敗時能夠自行復原。 大部分的用戶端程式庫會自動重新連線到快取端點，但很少會嘗試重試失敗的要求。 根據應用場景，使用帶有回退機制的重試邏輯可能會更有意義。
如何讓我的應用程式具有彈性？
請參閱這些設計模式來建置強韌用戶端，特別是熔斷與重試模式：
若要測試用戶端應用程式的復原能力，請使用 重新啟動 作為連線中斷的手動觸發程序。
此外，我們建議您使用排程的更新來選擇快取的更新通道和維護時段，以便在特定的每週時段內套用 Redis 執行階段修補程式。 這些時段通常是用戶端應用程式流量較低的時段，以避免潛在事件。 如需詳細資訊，請參閱 更新頻道 和 排程更新。
如需詳細資訊，請參閱連線復原。