Azure 受控 Redis 的故障轉移和修補 （預覽）
若要建置復原且成功的用戶端應用程式，請務必瞭解 Azure 受控 Redis （預覽）服務中的故障轉移。 容錯移轉可以是計劃性管理作業的一環，或者非計劃性硬體或網路失敗導致容錯移轉。 當管理服務修補 Azure 受控 Redis 二進位檔時，通常會使用快取故障轉移。
在本文中，您會找到以下資訊：
- 容錯移轉是什麼？
- 修補期間發生容錯移轉的原因。
- 建置復原性用戶端應用程式的方式。
容錯移轉是什麼？
讓我們從 Azure 受控 Redis 的故障轉移概觀開始。
快取結構的快速摘要
快取是由包含個別和私人 IP 位址的多個虛擬機器建構而成。 每個虛擬機 （或 “node”） 會平行執行多個 Redis 伺服器進程（稱為「分區」）。 多個分區可讓每個虛擬機上的 vCPU 更有效率地使用率，以及更高的效能。 並非所有的主要 Redis 分區都位於相同的 VM/節點上。 相反地，主要和複本分區會分散到這兩個節點。 因為主要分區使用比復本分區更多的 CPU 資源，因此此方法可讓更多主要分區平行執行。 每個節點都有 高效能的 Proxy 程式來管理分區、處理連線管理，以及觸發自我修復。 即使一個分區關閉，其他分區仍可使用。
如需 Azure 受控 Redis 架構的深入詳細數據，請參閱 這裡。
容錯移轉的說明
當一或多個複本分區升級為成為主要分區，而舊的主要分區關閉現有的連線時，就會發生故障轉移。 故障轉移可能是計劃性或非計劃性。
「計劃性容錯移轉」會在兩個不同的時間執行：
- 系統更新，例如 Redis 修補或 OS 升級。
- 管理作業，例如調整或重新啟動。
節點會收到更新的預先通知，所以可以合作方式交換角色，並快速更新變更的負載平衡器。 計劃性容錯移轉通常會在 1 秒內完成。
非計劃性故障轉移可能會因為硬體故障、網路失敗，或叢集中一或多個節點的其他非預期中斷而發生。 其餘節點上的複本分區（s）會自行升階為主要複本，以維護可用性，但程式需要較長的時間。 復本分區必須先偵測其主要分區無法使用，才能啟動故障轉移程式。 復本分區也必須確認此非計劃性失敗不是暫時性或本機的，以避免不必要的故障轉移。 此偵測延遲代表非計劃性容錯移轉通常會在 10 到 15 秒內完成。
為什麼發生修補？
Azure 受控 Redis 服務會定期使用最新的平臺功能和修正來更新快取。 若要修補快取，服務會遵循下列步驟：
- 服務會建立新的最新 VM，以取代正在修補的所有 VM。
- 然後，它會將其中一個新的 VM 升級為叢集領導者。
- 一個接一個地，所有要修補的節點都會從叢集中移除。 這些 VM 上的任何分區都會降級並移轉至其中一個新的 VM。
- 最後，所有已取代的 VM 都會遭到刪除。
叢集快取的每個分區會個別修補，而且不會關閉與另一個分區的連線。
相同資源群組和區域中的多個快取也是一次修補一個分區。 位於不同資源群組或不同區域時，快取可能會同時修補。
由於完整數據同步處理會在程式重複之前發生，因此快取不太可能發生數據遺失。 您可以匯出資料並啟用持續性，進一步防止資料遺失。
其他快取負載
每當發生故障轉移時，快取就必須將數據從一個節點複寫到另一個節點。 此複寫會導致伺服器記憶體和 CPU 中的負載增加。 如果快取執行個體已是高負載，用戶端應用程式可能遇到延遲增加。 在極端案例中，用戶端應用程式可能收到逾時例外狀況。
容錯移轉如何影響我的用戶端應用程式？
用戶端應用程式可能會從其 Azure 受控 Redis 實例收到一些錯誤。 用戶端應用程式顯示的錯誤數目，取決於容錯移轉時該連線上擱置的作業數目。 透過關閉其連線的節點所路由的任何連線，都會看到錯誤。
連線中斷時，很多用戶端程式庫可能擲回不同類型的錯誤，包括：
- 逾時例外狀況
- 連線例外狀況
- 通訊端例外狀況
例外狀況的數目和類型取決於快取關閉連線時，要求在程式碼路徑中的位置。 例如，發生容錯移轉時，傳送要求但尚未收到回應的作業可能會發生逾時例外狀況。 已關閉連線物件上的新要求會收到連線例外狀況，直到成功重新連線為止。
大部分的用戶端程式庫會嘗試重新連線快取 (如果程式庫已設定這麼做)。 但未預期的 Bug 有時會將程式庫物件置於無法復原的狀態。 如果錯誤持續超過預先設定的時間，建議重新建立連線物件。 在 Microsoft.NET 和其他物件導向語言中，使用 ForceReconnect 模式可以重新建立連線，而不重新啟動應用程式。
維護期間包含哪些更新？
維護包含下列更新：
- Redis 伺服器更新：Redis 伺服器二進位檔的任何更新或修補程式。
- 虛擬機 （VM） 更新：裝載 Redis 服務之虛擬機的任何更新。 VM 更新包括修補裝載環境中的軟體元件，以升級網路元件或解除委任。
維護是否出現在修補前 Azure 入口網站的服務健康情況中？
否，維護不會出現在入口網站或任何其他位置的服務健康情況之下。
用戶端網路設定變更
某些用戶端網路組態變更可能會觸發 沒有可用的 連線錯誤。 這些變更可能包括︰
- 在預備和生產位置間交換用戶端應用程式的虛擬 IP 位址。
- 調整應用程式執行個體的大小或數目。
這類變更可能會導致通常持續不到一分鐘的連線問題。 用戶端應用程式可能會失去與其他外部網路資源的連線，但也會失去與 Azure 受控 Redis 服務的連線。
内建復原性
您無法完全避免容錯移轉。 所以請撰寫用戶端應用程式，增強連線中斷和失敗要求的復原性。 大部分的用戶端程式庫會自動重新連線快取端點，但少數會嘗試重試失敗的要求。 根據應用程式案例，使用重試邏輯與輪詢可能很合理。
如何設定應用程式的復原性？
請參閱以下設計模式來建置復原性用戶端，尤其是斷路器和重試模式：