共用方式為

Azure Cache for Redis 的容錯移轉和修補

  • 發行項

若要建置復原且成功的用戶端應用程式，請務必瞭解 Azure Cache for Redis 服務中的故障轉移。 故障轉移可以是計劃管理作業的一部分，或可能是由非計劃的硬體或網路失敗所造成。 當管理服務修補 Azure Cache for Redis 二進制檔時，通常會使用快取故障轉移。

在本文中，您會找到此資訊：

  • 什麼是故障轉移？
  • 修補期間如何進行故障轉移。
  • 如何建置復原的用戶端應用程式。

什麼是故障轉移？

讓我們從 Azure Cache for Redis 的故障轉移概觀開始。

快取架構的快速摘要

快取是由具有個別和私人IP位址的多個虛擬機所建構。 每個虛擬機，也稱為節點，會連線到具有單一虛擬IP位址的共用負載平衡器。 每個節點都會執行 Redis 伺服器進程，而且可以使用主機名和 Redis 埠來存取。 每個節點都會被視為主要節點或復本節點。 當用戶端應用程式連線到快取時，其流量會經過此負載平衡器，並自動路由傳送至主要節點。

在基本快取中，單一節點一律是主要節點。 在標準或 進階版 快取中，有兩個節點：一個是選擇做為主要節點，另一個是複本。 因為標準和 進階版 快取有多個節點，一個節點可能會在另一個節點繼續處理要求時無法使用。 叢集快取是由許多分區所組成，每個分區都有不同的主要和復本節點。 其中一個分區可能會關閉，而另一個分區則維持可用狀態。

注意

基本快取沒有多個節點，而且不提供服務等級協定 （SLA） 以取得其可用性。 建議只針對開發和測試目的使用基本快取。 使用標準或 進階版 快取進行多節點部署，以提高可用性。

故障轉移的說明

當復本節點升級為成為主要節點，而舊的主要節點關閉現有的連線時，就會發生故障轉移。 在主要節點備份之後，它會注意到角色的變更，並將本身降級為複本。 然後它會連線到新的主要復本，並同步處理數據。 故障轉移可能是計劃性或非計劃性。

計劃性故障轉移會在兩個不同的時間進行：

  • 系統更新，例如 Redis 修補或操作系統升級。
  • 管理作業，例如調整和重新啟動。

由於節點會收到更新的預先通知，因此可以合作交換角色，並快速更新變更的負載平衡器。 計劃性故障轉移通常會在不到 1 秒內完成。

非計劃性故障轉移可能會因為硬體故障、網路失敗或其他主要節點未預期的中斷而發生。 復本節點會將本身升階為主要節點，但程式需要較長的時間。 復本節點必須先偵測其主要節點無法使用，才能啟動故障轉移程式。 復本節點也必須確認此非計劃性失敗不是暫時性或本機的，以避免不必要的故障轉移。 此偵測延遲表示非計劃性故障轉移通常會在 10 到 15 秒內完成。

修補如何進行？

Azure Cache for Redis 服務會定期使用最新的平臺功能和修正來更新快取。 若要修補快取，服務會遵循下列步驟：

  1. 服務會先修補復本節點。
  2. 修補的複本會合作地將自己升階為主要複本。 此升級會被視為計劃性故障轉移。
  3. 先前的主要節點會重新啟動以取得新的變更，並備份為復本節點。
  4. 復本節點會連線到主要節點並同步處理數據。
  5. 當數據同步完成時，修補程式會針對其餘節點重複。

因為修補是計劃性故障轉移，復本節點會快速升級自己成為主要複本。 然後，節點會開始服務要求和新連線。 基本快取沒有復本節點，在更新完成之前無法使用。 叢集快取的每個分區都會個別修補，而且不會關閉另一個分區的連線。

重要

節點會一次修補一個，以防止數據遺失。 基本快取將會遺失數據。 叢集快取會一次修補一個分區。

相同資源群組和區域中的多個快取也會一次修補一個。 位於不同資源群組或不同區域的快取可能會同時修補。

由於完整數據同步處理會在程式重複之前發生，因此當您使用標準或 進階版 快取時，不太可能發生數據遺失。 您可以匯出數據並啟用持續性，進一步防範數據遺失。

其他快取負載

每當發生故障轉移時，標準和 進階版 快取都必須將數據從一個節點複寫到另一個節點。 此復寫會導致伺服器記憶體和CPU的負載增加。 如果快取實例已大量載入，用戶端應用程式可能會遇到增加的延遲。 在極端情況下，用戶端應用程式可能會收到逾時例外狀況。 若要協助減輕更多負載的影響， 請設定 快取的 maxmemory-reserved 設定。

容錯移轉如何影響我的用戶端應用程式？

用戶端應用程式可能會從其 Azure Cache For Redis 收到一些錯誤。 用戶端應用程式所看到的錯誤數目取決於故障轉移時該連線上擱置的作業數目。 透過關閉其連線的節點所路由的任何連線，都會看到錯誤。

當連線中斷時，許多用戶端連結庫可能會擲回不同類型的錯誤，包括：

  • 逾時例外狀況
  • 連線 ion 例外狀況
  • 套接字例外狀況

例外狀況的數目和類型取決於當快取關閉其連線時，要求位於程式代碼路徑的位置。 例如，傳送要求但未在故障轉移發生時收到回應的作業可能會發生逾時例外狀況。 關閉連接物件上的新要求會接收連線例外狀況，直到重新連線成功為止。

大部分的用戶端連結庫會嘗試重新連線到快取，如果他們已設定為 。 不過，無法預見的錯誤偶爾會將連結庫物件置於無法復原的狀態。 如果錯誤持續的時間超過預先設定的時間量，則應該重新建立連接物件。 在 Microsoft.NET 和其他面向物件語言中，使用 ForceReconnect 模式可以重新建立連線而不重新啟動應用程式。

我可以事先收到維護通知嗎？

Azure Cache for Redis 會在名為 AzureRedisEvents的發佈/訂閱（pub/sub） 通道上發佈運行時間維護通知。 許多熱門的 Redis 用戶端連結庫都支援訂閱發佈/訂閱頻道。 從 AzureRedisEvents 通道接收通知通常是用戶端應用程式的簡單新增專案。 如需維護事件的詳細資訊，請參閱 AzureRedisEvents。

注意

AzureRedisEvents通道不是可以事先通知您數天或數小時的機制。 通道可以通知用戶端任何可能影響伺服器可用性的即將發生的伺服器維護事件。 AzureRedisEvents僅適用於基本、標準和 進階版 層。

維護期間包含哪些更新？

維護包含下列更新：

  • Redis 伺服器更新：Redis 伺服器二進位檔的任何更新或修補程式。
  • 虛擬機 （VM） 更新：裝載 Redis 服務之虛擬機的任何更新。 VM 更新包括修補裝載環境中的軟體元件，以升級網路元件或解除委任。

維護是否出現在修補前 Azure 入口網站的服務健康情況中？

否，維護不會出現在入口網站或任何其他位置的服務健康情況之下。

在計劃性維護之前可以取得通知多少時間？

使用 AzureRedisEvents 通道時，您會在維護前 15 分鐘收到通知。

用戶端網路設定變更

某些用戶端網路組態變更可能會觸發 沒有可用的 連線錯誤。 這類變更可能包括：

  • 在預備位置與生產位置之間交換用戶端應用程式的虛擬IP位址。
  • 調整應用程式的大小或實例數目。

這類變更可能會導致通常持續不到一分鐘的連線問題。 用戶端應用程式可能會失去與其他外部網路資源的連線，但也會失去與 Azure Cache for Redis 服務的連線。

在復原中建置

您無法完全避免故障轉移。 相反地，請撰寫用戶端應用程式以復原連線中斷和失敗的要求。 大部分客戶端連結庫都會自動重新連線到快取端點，但其中很少有連結庫嘗試重試失敗的要求。 根據應用程式案例，使用重試邏輯進行輪詢可能很合理。

如何? 讓應用程式具有復原性？

請參閱這些設計模式來建置復原的用戶端，特別是斷路器和重試模式：

若要測試用戶端應用程式的復原能力，請使用 重新啟動 作為連線中斷的手動觸發程式。

此外，建議您使用排程的更新來選擇更新通道，以及快取的維護時間範圍，以在特定每周期間套用 Redis 運行時間修補程式。 這些視窗通常是用戶端應用程式流量低時的期間，以避免潛在的事件。 如需詳細資訊，請參閱 更新通道和排程更新。

如需詳細資訊，請參閱 連線 復原能力。

相關內容