Azure Managed Redis 在 Azure 上提供完全整合且受管理的 Redis Enterprise，為應用程式提供高效能的記憶體資料儲存。 此服務專為需要超低延遲、高吞吐量及先進資料結構的企業工作負載打造。
當您使用 Azure 時， 可靠性是共同的責任。 Microsoft 提供一系列功能來支援韌性和復原。 您有責任瞭解這些功能在您使用的所有服務中如何運作，並選取符合業務目標和正常運作時間目標所需的功能。
本文說明 Azure Managed Redis 中的可靠性，包括對暫態故障、可用性區失效及區域性故障的韌性。 文章同時描述了備用策略與服務水準協議（SLA）。
生產部署建議
為確保您的 Azure Managed Redis 實例具備高可靠性，我們建議您：
- 啟用高可用性，也就是部署多個快取節點。
- 透過在具備可用性區域的區域中部署高可用性快取，啟用區域備援。
- 考慮對需要跨區域故障轉移的關鍵任務負載實施主動地理複製。
可靠性架構概觀
本節說明服務運作中從可靠性角度來看最為重要的部分。 本節介紹邏輯架構，包含你部署和使用的部分資源與功能。 它還討論了物理架構，其中提供了有關服務如何在幕後工作的詳細信息。
邏輯架構
Azure Managed Redis 建置於 Redis Enterprise 之上，透過高可用性配置與複製功能提供可靠性。
你部署一個 Azure Managed Redis 實例 ，也稱為 快取實例 或 快取。 你的客戶端應用程式透過 Redis API 儲存並互動快取中的資料。
實體架構
在規劃 Azure Managed Resid 的韌性時，有兩個關鍵概念是：節點與分片。
節點： 每個快取實例由 節點組成，節點是虛擬機（VM）。 每個虛擬機在叢集中作為獨立的運算單元。 您看不到 VM，也無法直接管理 VM。 平台會自動管理執行個體建立、狀況監控，以及取代狀況不良的執行個體。 這些虛擬機集合合起來也稱為 叢集。
你可以將實例設置為高可用性。 當你這麼做時，Azure Managed Redis會確保至少有兩個節點，並且會自動在節點間複製資料。 在有可用區域的區域，節點會被分配到不同的可用區域。 欲了解更多資訊，請參閱 對於可用性區域失效的韌性。
該服務會抽象化每個配置中使用的特定節點數量，以避免複雜性並確保最佳配置。
分片： 每個節點執行多個 Redis 伺服器程式，稱為 分片，管理快取資料的一部分。 當快取設定為高可用性時，分區會自動分散並複寫到各節點。 你指定了一個 叢集策略，決定分片如何在節點間分配。
欲了解更多資訊，請參閱 Azure Managed Redis 架構及 Azure Managed Redis 的故障轉移與修補。
對瞬態故障的彈性
暫時性錯誤是元件中的短暫間歇性失敗。 它們經常出現在雲端等分散式環境中，而且是作業的一般部分。 暫時性錯誤會在短時間內自行修正。 請務必確保您的應用程式能妥善處理暫時性錯誤，通常透過重試受影響的請求來進行。
所有雲端裝載的應用程式在與任何雲端裝載的 API、資料庫和其他元件通訊時，都應該遵循 Azure 暫時性錯誤處理指引。 如需詳細資訊，請參閱 處理暫時性錯誤的建議。
使用 Azure Managed Resis 時，請遵循以下管理暫時性故障的建議：
- 使用 SDK 設定 ，當發生瞬態故障時自動重試，並使用適當的退換與逾時時間。 考慮在申請中使用 重試模式 和 斷路器模式 。
- 設計快取旁路模式，使應用程式在 Redis 暫時無法使用時，仍能透過退回主要資料儲存系統，即使效能下降仍能運作。
對可用性區域故障的抵抗力
可用性區域 是 Azure 區域內物理上獨立的資料中心群組。 當某個區域發生故障時，服務可以切換至其他剩餘的區域。
Azure 管理的 Redis 快取實例可以設定為 區域冗餘，自動將快取節點分配到區域內多個可用區域。 區域冗餘降低資料中心或可用性區域中斷導致快取無法使用的風險。
若要讓快取具備區域備援，您必須將它部署到支援的區域並啟用高可用性組態。 在沒有可用性區域的地方，高可用性配置仍會創建至少兩個節點，但它們不會位於不同的區域中。
下圖顯示一個區域冗餘快取，包含兩個節點，各自位於獨立區域：
需求
區域支援： 具區域備援的 Azure Managed Redis 快取可以部署到任何支援可用性區域且服務開通的地區。 關於最新支援可用性區域的區域清單，請參閱 具備可用性區域的 Azure 區域。 關於支援 Azure Managed Redis 的區域列表，請參閱 「按區域提供的產品可用性」。
高可用性組態：您必須在快取上啟用高可用性組態，快取才會具備區域備援。
分級： 所有 Azure Managed Redis 層級都支援可用性區域。
費用
區域冗餘要求快取設定為高可用性，也就是至少部署兩個節點來執行快取。 高可用性配置的計費率高於非高可用性配置。 欲了解更多資訊，請參閱 Azure Managed Redis 定價
設定可用性區域支援
建立一個新的區域冗餘實例： 當你建立新的 Azure Managed Redis 實例時，啟用高可用性設定並將其部署到有可用性區域的區域。 接著，它會自動預設包含區域冗餘。 您不需要再執行任何設定。
詳細步驟請參見 快速入門：建立 Azure 管理的 Redis 實例。
在現有實例上啟用區域冗餘： 要將現有的 Azure Managed Redis 實例設定為區域冗餘，請確保它部署在支援可用性區域的區域，並在快取上啟用高可用性。
關閉區域冗餘： 區域冗餘無法在現有實例上停用，因為一旦快取實例啟用高可用性，就無法關閉。
容量規劃和管理
在區域降級事件中，你的實例可用資源可能會減少，無法充分應付你的工作負載。 如果您的實例經常面臨資源壓力，且需要準備可用性區域失效，請考慮以下其中一種方法：
過度配置你的實例： 過度配置是指選擇比你可能需要的更高效能層級。 它讓你的實例能容忍部分容量損失，繼續運作而不影響效能。 欲了解更多關於過度配置原則的資訊，請參閱 「透過過度配置管理容量」。 想了解如何擴展你的實例，請參閱 「擴展 Azure Managed Redis 實例」。
使用主動式地理複製： 你可以在不同區域部署多個實例，並設定 主動地理複製 ，將負載分散到這些獨立實例。
所有區域都狀況良好時的行為
本節說明當受控 Redis 快取具備區域備援且所有可用性區域都正常運作時，您可以預期的行為：
區域間的流量路由： 分片會根據你的叢集政策分散在各節點之間。 你的叢集政策也決定了流量如何路由到每個節點。 區域冗餘不會改變流量的路由方式。
區域間的資料複製： 分片會自動在節點間複製，並使用非同步複寫。 通常分片間的複製延遲以秒計，但這會依快取的工作負載而異，寫入密集且網路密集的情境通常會有較高的複製延遲。
區域失敗期間的行為
本節說明當受管理的 Redis 快取為區域冗餘且一個或多個可用區域無法使用時，應預期的情況：
- 偵測與回應： Azure Managed Redis 負責偵測可用性區域的故障。 您不需要執行任何動作即可起始區域容錯移轉。
- 通知：Microsoft 不會在區域關閉時自動通知您。 不過，您可以使用 Azure 服務健康情況 來了解服務的整體健康情況，包括任何區域失敗，而且您可以設定 服務健康情況警示 來通知您問題。
作用中要求：進行中的要求可能會遭到捨棄，請重試。 應用程式應該 實作重試邏輯 來處理這些暫時中斷。
預期資料遺失： 任何未複製到其他區域分片的資料，在區域故障時可能會遺失。 通常資料遺失的量以秒計，但取決於複製延遲。
預期的停機時間： 在分片切換到健康區域節點時，可能會有短暫的停機時間，通常為 10 至 15 秒。 關於非計畫性故障轉移流程的資訊，請參見 故障轉移說明 。設計應用程式時，請遵循 暫態故障處理的實務。
交通改道： Azure Managed Redis 會自動將流量重新導向到健康區域的節點。
區域復原
當受影響的可用區域恢復時，Azure Managed Redis 會自動恢復該區域的操作。 Azure 平臺會完全管理此程式，而且不需要任何客戶介入。
測試區域失敗
由於 Azure Managed Redis 完全管理區域故障的流量路由、故障轉移與故障恢復，您無需驗證可用性區故障流程或採取進一步行動。
對區域範圍故障的復原能力
Azure Managed Redis 透過 主動式地理複製提供原生多區域支援，讓你能將多個跨 Azure 區域的 Azure Managed Redis 實例連結成單一複製群組。 接著你可以在實例間設定自己的容錯轉移方式。
主動式地理複寫
當你使用 主動式地理複製時，應用程式可以從群組中的任何快取實例讀寫，變更會自動同步於所有區域。 該服務支援主動-主動複寫模式，每個區域可同時處理讀寫操作。 當不同區域同時寫入導致衝突時，服務會自動利用預定的衝突解決演算法解決，無需人工介入。 此方法提供能夠抵禦區域故障的能力，同時維持全球分散式應用程式的低延遲存取。
下圖顯示同一活躍地理複製群組內不同區域的兩個快取實例，且每個快取實例都有用戶端應用程式連接：
你負責配置客戶端應用程式，這樣如果有任何區域實例故障，他們能將請求重新導向健康的實例。 下圖顯示應用程式如何在其平常用的快取實例失敗時，將請求重新導向至健康快取實例：
需求
區域支援 Azure Managed Redis 的主動地理複製可以在任何有該服務的 Azure 區域間設定。
實例配置： 主動式地理複製需要在所有參與區域內擁有相同層級與規模的 Azure Managed Redis 實例。 複製群組中的所有快取實例必須設定相同的設定，包括持久化選項、模組及叢集策略。
其他要求： 你的快取實例必須符合其他需求，包括你使用的模組，這也會影響快取實例的擴展方式。 欲了解更多資訊，請參閱 主動地理複製的前置條件。
考慮事項
故障轉移責任： 當你使用主動式地理複製時， 你必須負責快取實例之間的故障轉移。 你應該準備並配置你的應用程式來處理故障轉移。 容錯移轉需要事先準備，且可能需要您完成多個步驟。 如需詳細資訊，請參閱當發生區域中斷時強制解除連結。
最終一致性： 應用程式應設計以應對最終一致性情境，因為變更可能因網路狀況與地理距離而跨越所有區域需要時間。 在區域中斷期間，直到連線恢復並同步完成前，你可能會遇到更多資料不一致的情況。
費用
當你啟用主動式地理複製時，你會根據複製群組內每個區域的 Azure Managed Redis 實例計算費用。 此外，您可能會因跨地區複製流量而產生資料傳輸費用。 欲了解更多價格資訊，請參閱 Azure Managed Redis 價格 與 頻寬價格詳情。
設定多區域支援
建立新的地理複製快取實例：在快取配置期間，透過指定複製群組並連結多個實例來配置主動式地理複製。 欲了解更多資訊，請參閱 「建立或加入活躍的地理複製群組」。
啟用現有快取實例進行地理複製：你可以將現有快取實例加入活躍的地理複製群組。
然而，當現有實例加入活躍的地理複製群組時，實例中的資料需要被清除，且會有少量停機時間。 如果可能，建立快取實例時，計畫啟用主動式地理複製。
欲了解更多資訊，請參閱 「將現有實例加入活躍的地理複製群組」。
在快取實例中停用地理複製：透過刪除快取實例，將該實例從地理複製群組中移除。 剩下的實例會自動重新配置。
容量規劃和管理
在區域停機事件期間，其他執行個體可能承受更高壓力。 如果實例通常已經承受資源壓力，且你需要準備區域故障時增加的容量需求，可以考慮 超額配置實例。 想了解如何擴展實例，請參閱 「擴展 Azure Managed Redis 實例」。
當所有區域都正常時的行為
本節說明當實例設定為使用主動地理複製且所有區域運作時，會發生什麼情況。
區域間流量路由：你負責設定應用程式連接特定快取實例。 應用程式可以連接到複製群組中的任何快取實例，並執行讀寫操作。 流量路由由應用程式處理，讓你能以最低延遲將客戶導向最近的區域。 Azure Managed Redis 不提供區域間的自動流量路由。
區域間的資料複製：該服務使用區域間的非同步複製來維持最終一致性。 寫入作業會立即在本機區域提交，然後在背景傳播至其他區域。 無衝突複製資料型態（CRDT）確保不同區域的並行寫入會自動合併。
區域失敗期間的行為
本節說明當實例設定為使用主動式地理複製，且某區域發生故障時，會發生什麼情況：
偵測與回應：你負責偵測快取實例的失敗，並決定何時切換。 你可以監控地理複製叢集的健康狀況，這有助於你決定何時開始故障轉移。 欲了解更多資訊，請參閱 地理複製指標。
容錯移轉需要您完成多個步驟。 如需更多詳細資料，請參閱當發生區域中斷時強制解除連結。
通知： Microsoft 不會自動通知你區域失效。 不過，你可以使用 Azure Service Health 來了解整體服務的健康狀況，包括任何區域故障，並且可以設定 服務健康警示 來通知你問題。
你也可以監控每個實例的健康狀況。
要監控地理複製關係的健康狀況，可以使用 地理複製健康 指標。 指標總是有
1（健康）或0（不健康）的值。 你可以在這個指標上設定 Azure Monitor 警示，了解實例何時可能不同步。主動請求：對失敗區域的請求會被終止，必須由應用程式的故障切換邏輯處理。 應用程式應實行重試策略，以將流量導向正常運作的快取。
預期資料遺失：由於區域間的非同步複製，若尚未複製到其他區域，部分近期寫入失敗區域可能會遺失。 潛在的資料遺失程度取決於故障時的複製延遲。 欲了解更多資訊，請參閱 Active-Active 地理分布式 Redis ，以及 關於 CRDB 區域故障中一致性與資料遺失的考量。
預期停機時間：應用程式僅在偵測故障並將流量導向健康區域所需的時間內停機。 這通常從幾秒鐘到幾分鐘不等，取決於你如何設定應用程式的健康檢查和故障轉移。
流量重路由：你負責在應用程式中實作邏輯，偵測區域故障並將流量導向健康區域。 這可以透過健康檢查、斷路器模式或外部負載平衡解決方案來實現。
區域復原
當失敗的區域恢復時，Azure Managed Redis 會自動將該區域的實例重新整合到主動的地理複製群組，無需你介入。 該服務會自動同步健康實例的資料。 在此過程中，恢復的實例會逐漸跟上故障期間發生的變化。 同步完成後，恢復的實例會完全啟動，能同時處理讀寫操作。
你負責重新設定應用程式，將流量路由回已恢復的區域實例。
區域故障測試
你應該定期測試應用程式的故障轉移程序。 應用程式必須能在不同實例間切換，並在此過程中滿足業務對停機時間的要求。 同時，測試整體回應流程也很重要，包括防火牆及其他基礎設施的重新配置，以及你的復原流程。
服務維護的韌性
Azure Managed Redis 執行定期的服務升級及其他維護任務。
當維護進行中時，Azure 受控 Redis 會自動建立新節點並自動執行容錯移轉。 用戶端應用程式可能會看到連線中斷及其他暫時性故障。 應用程式應該 實作重試邏輯 來處理這些暫時中斷。
欲了解更多 Azure Managed Redis 的維護流程，請參閱 Azure Managed Redis 的故障轉移與修補。
備份與還原
Azure Managed Redis 提供資料持久化與備份功能，以防止其他可靠性功能無法解決的資料遺失情境。 備份能提供防範資料損壞、意外刪除或設定錯誤等情境的保護。
資料持續性： 預設情況下，Azure Managed Redis 會將所有快取資料儲存在記憶體中。 它可以選擇性地透過 資料持久化寫入資料快照到磁碟。 如果節點發生硬體故障，Azure Managed Redis會自動還原資料。 您可以選取不同類型的持續性資料，以在快照頻率與對快取效能的影響之間取得不同取捨。
然而，資料檔案無法還原到其他實例，且你無法存取這些檔案。 資料持久性並不能保護你免於資料損壞或意外刪除。
進出口： Azure Managed Redis 支援透過 匯入與匯出功能備份資料，將備份檔案儲存到 Azure Blob Storage。 你可以在 Azure Storage 帳號上設定地理冗餘儲存，或是複製或移動備份 blob 到其他位置以加強保護。
匯出的檔案可以還原到相同的快取實例或不同的快取實例。
沒有內建匯入或匯出排程器，但你可以自行開發自動化流程，使用 Azure CLI 或 Azure PowerShell 來啟動匯出操作。
服務等級協定
Azure 服務的服務等級協定 (SLA) 描述服務的預期可用性，以及解決方案必須符合才能達到該可用性預期的條件。 如需詳細資訊，請參閱 在線服務的 SLA。
Azure Managed Redis 的 SLA 涵蓋了快取端點的連線。 SLA 未涵蓋資料遺失防護。
要符合Azure Managed Redis可用性SLA的資格：
- 你必須啟用高可用性設定。
- 你不得啟動任何已記錄的產品功能或管理操作，導致暫時無法使用。
當你的實例是區域冗餘時，會適用較高可用性的 SLA。 在某些層級，當你已部署區域冗餘實例到至少三個區域並使用主動地理複製時，可以享有更高的可用性SLA。