Azure Service Bus 是一個完全受管理的企業訊息代理服務，提供可靠的非同步訊息傳遞功能，以實現應用程式與服務的解耦。 服務匯流排支援點對點通訊的佇列，以及以發佈-訂閱訊息模式的主題訂用帳戶。 該服務內建可靠性功能，包括訊息耐用度、至少一次送達保證，以及用於處理失敗訊息處理的死符佇列。
當您使用 Azure 時， 可靠性是共同的責任。 Microsoft 提供一系列功能來支援韌性和復原。 您有責任瞭解這些功能在您使用的所有服務中如何運作，並選取符合業務目標和正常運作時間目標所需的功能。
本文說明如何使服務匯流排能够應對各種潜在的中斷和問題，包括瞬暫時性故障、可用性區域中斷和區域中斷。 其中也提供一些關於服務匯流排服務等級協定 (SLA) 的重要資訊。
生產部署建議
Azure Well-Architected Framework 提供可靠性、效能、安全性、成本和作業的建議。 欲了解這些領域如何相互影響並促成可靠的 App Service 解決方案，請參閱 Azure Well-Architected Framework 中的 Azure Service Bus 架構最佳實務。
可靠性架構概觀
本節說明服務運作中從可靠性角度來看最為重要的部分。 本節介紹邏輯架構，包含你部署和使用的部分資源與功能。 它還討論了物理架構，其中提供了有關服務如何在幕後工作的詳細信息。
邏輯架構
命名空間作為服務匯流排的管理容器，並可設定為使用基本、標準或高級等級。 在命名空間層級配置這些服務時，透過分配容量、設定網路安全，並啟用地理複寫和地理災難復原。
在命名空間中，你會部署佇 列 和 主題，這些都是具有不同語意的訊息實體。 如需詳細資訊，請參閱 服務總線佇列、主題和訂用帳戶。
你可以選擇在命名空間上設定 分割區 ，這樣可以將佇列和主題分散到多個訊息代理和訊息儲存裝置。 命名空間可以使用多個分割區來執行平行處理與水平縮放。 服務匯流排僅保證單一分割區中的順序性。 分割在應用程式的可靠性設計中扮演關鍵角色。 當您設計應用程式時，請在最大化可用性和一致性之間進行權衡。 對於高級等級， 你需要在命名空間啟用分割。 針對基本和標準層命名空間，您可以在實體上設定分割區，並且在傳送訊息時可選擇性地設定。
你可以利用服務匯流排及其非同步設計方法，提升應用程式的可用性。 欲了解更多資訊，請參閱 非同步訊息模式與高可用性。
實體架構
服務匯流排提供底層的運算與儲存資源。 每個命名空間由多個 訊息代理 處理，多個 訊息儲存庫 則儲存訊息。 訊息儲存庫有三個副本：一個主要版本和兩個次要版本。 服務匯流排會保持三個複本同步以便進行資料和管理作業。 如果主要複本失敗，其中一個次要複本會升級為主要複本，並且不會感受到停機。
對於使用基本層或標準層的命名空間，Service Bus 透過共享多租戶基礎設施提供冗餘，能自動在可用區域間複製訊息。 該服務維護多個訊息儲存庫，並保持所有副本同步，以進行資料與管理操作。
對於 高級命名空間，Service Bus 提供專用訊息單元，每個單位配備專用的 CPU 與記憶體資源。 高級命名空間可根據工作負載需求自動擴展。 欲了解更多資訊，請參閱 「自動更新 Azure 服務匯流排命名空間的訊息單元」。
服務匯流排的基礎建設跨越多台實體機器與機架，分散於不同的故障域，從而降低災難性故障對命名空間的影響風險。 在有可用性區域的地區，基礎設施 會跨越不同的實體資料中心。 該服務實作透明的故障偵測與故障轉移機制，確保在保證的服務層級內持續運作，且通常在此類故障發生時不會有明顯中斷。
對瞬態故障的彈性
暫時性錯誤是元件中的短暫間歇性失敗。 它們經常出現在雲端等分散式環境中，而且是作業的一般部分。 暫時性錯誤會在短時間內自行修正。 請務必確保您的應用程式能妥善處理暫時性錯誤，通常透過重試受影響的請求來進行。
所有雲端裝載的應用程式在與任何雲端裝載的 API、資料庫和其他元件通訊時，都應該遵循 Azure 暫時性錯誤處理指引。 如需詳細資訊，請參閱 處理暫時性錯誤的建議。
Azure 服務匯流排 SDK 包含自動重試邏輯，並針對因暫時性的狀況 (如網路逾時或服務暫時無法使用) 而失敗的作業進行指數輪詢。 當應用程式出現服務匯流排暫時斷線時，SDK 會自動嘗試使用已設定的重試策略重新連線。
要優化應用程式中的暫態故障處理，請使用最新的服務匯流排 SDK，其中包含最新的重試邏輯與連線管理功能。 欲了解更多資訊，請參閱 .NET 的 Azure Service Bus 用戶端程式庫。
對可用性區域故障的抵抗力
可用性區域 是 Azure 區域內物理上獨立的資料中心群組。 當某個區域發生故障時，服務可以切換至其他剩餘的區域。
服務匯流排支援所有服務層級中的區域備援部署。 當你在支援區域建立服務匯流排命名空間時，區域冗餘會自動啟用，且不會額外付費。 區域冗餘部署模型適用於所有 Service Bus 功能，包括分割與會話。
Service Bus 會透明地在區域內多個可用區域複製您的設定、元資料和訊息資料。 區域備援可提供自動容錯移轉功能，不需要您介入處理。 所有服務匯流排元件，包括運算、網路與儲存，皆可跨區域複製。 服務匯流排具有足夠的保留容量，可立即處理完全失去整個區域的情況。 即使整個可用區域無法使用，服務匯流排仍能持續運作，不會造成資料遺失或訊息應用程式中斷。
需求
區域支援： 區域冗餘服務匯流排命名空間可部署至 支援可用性區域的 Azure 區域。 支援的區域中，當您建立命名空間時，服務匯流排會自動啟用可用性區支援，無需額外設定。
分級： 所有服務公車等級（基本、標準及高級）皆支援可用性區域，無需額外需求。
考慮事項
服務公車命名空間包含一個 zoneRedundant 屬性。 過去此屬性是啟用可用區域的必要條件，但此行為已改變， zoneRedundant 該屬性正被棄用。 即使啟用區域冗餘，此屬性仍可能顯示為 false。 具有可用性區域的區域中的所有命名空間都是區域備援。
費用
服務總線的區域冗餘不會增加額外成本。
設定可用性區域支援
服務匯流排命名空間在 支援區域部署時，會自動支援區域冗餘。 不需要進一步的設定。
所有區域都狀況良好時的行為
本節說明當服務匯流排命名空間配置為區域冗餘且所有可用區域皆可運作時，可預期的情況。
區域之間的流量路由。 服務匯流排採用主動-主動模型，在該模型中，訊息分散在多個可用性區域中。 用戶端連線會自動在區域間負載平衡，服務會將操作路由到可用的訊息基礎設施，不論區域。
區域之間的資料複寫。 服務總線使用跨可用性區域的同步複製技術，涵蓋元資料和訊息資料。 多個訊息儲存的副本必須先確認寫入操作，才能視為完成，以確保正常操作期間跨區域的資料一致性。
區域失敗期間的行為
本節說明當 Service Bus 命名空間設定為區域冗餘且發生可用性區中斷時，應該預期的情況。
- 偵測與回應：Microsoft 會自動偵測區域故障並啟動故障轉移至健康區域。 區域層級故障轉移不需要客戶操作。
- 通知：Microsoft 不會在區域關閉時自動通知您。 不過，您可以使用 Azure 服務健康情況 來了解服務的整體健康情況，包括任何區域失敗，而且您可以設定 服務健康情況警示 來通知您問題。
作用中的要求：在區域失敗期間，服務匯流排可能會捨棄作用中的要求。 如果您的用戶端能透過在短暫延遲後重試而適當處理好暫時性錯誤，通常就能避免產生重大影響。
預期資料遺失：區域故障期間不會發生資料遺失，因為服務匯流排會在確認前同步複製訊息。
預期停機時間：區域故障可能會導致幾秒鐘的停機時間。 如果您的用戶端能透過在短暫延遲後重試而適當處理好暫時性錯誤，通常就能避免產生重大影響。
流量重新路由：服務匯流排偵測到失去可用性區域，並將新的要求自動導向至其他運作良好的可用性區域複本。
服務匯流排 SDK 通常透明地處理連線管理與重試邏輯。
區域復原
當可用區域恢復時，服務匯流排會自動將該區域重新整合到現行的服務拓撲中。 恢復的區域開始接受新連線並與其他區域一同處理訊息。 在中斷期間已抄寫至存續區域的資料會保持完整，且會在所有區域之間繼續正常同步抄寫。 您不需要採取動作來進行區域復原和重新整合。
測試區域失敗
服務匯流排管理流量路由、容錯移轉以及區域失敗的復原，因此您無需驗證可用性區域失敗流程或是提供進一步輸入。
對區域範圍故障的復原能力
Service Bus 提供兩種多區域支援，兩者都需要 Premium 等級命名空間：
地理複製 提供主區域與次要區域之間元資料與訊息資料的主動被動複寫。 大多數需要保持區域中斷韌性且對訊息資料遺失容忍度低的應用，請使用 Geo-Replication。
中繼資料異地災害復原對於主要區域與次要區域之間的設定和中繼資料提供主動式 - 被動式複寫，但不會複寫訊息資料。 考慮使用地理災害復原機制，適用於自行處理資料複製的應用程式，或不需要資料複製的應用程式。
異地複寫和中繼資料異地災害復原都需要您手動起始次要區域容錯移轉或升級，以成為新的主要區域。 Microsoft 不會自動執行容錯移轉或升階，即使您的主要區域已關閉。
Basic 與 Standard 層級的命名空間不包含原生多區域功能，但你可以在多個區域間使用多個命名空間實作應用層級的複製模式。 欲了解更多資訊，請參閱下方「 彈性自訂多區域解決方案 」章節。
Geo-Replication
Premium 級支援地理複製。 此功能同時複製命名空間的元資料（如實體、設定與屬性）及資料（如佇列與主題中的訊息，以及訊息屬性與狀態）。 您可以為命名空間的組態和資料設定複寫方式。 此功能確保你的訊息在其他地區持續可用，並允許你在需要時切換到次要區域。
對於需要區域中斷韌性且對訊息資料遺失容忍度低的情境，使用 Geo-Replication。
命名空間基本上是跨區域延伸。 一個區域作為主要區域，其他區域則作為次要區域。 你的 Azure 訂閱顯示的只有一個命名空間。
你隨時都可以將次要區域 升級 為主要區域。 當你升遷次要區域時，Service Bus 會將該命名空間的完全限定網域名稱（FQDN）重新定位到所選的次要區域，並將先前的主要區域降級為次要區域。 您可以決定是否要執行 計劃的升級 （這表示您等待資料複寫完成） 或強制 升級 （這可能會導致資料遺失）。
備註
服務匯流排異地複寫使用升級一詞，因為它最能代表將次要區域升級為主要區域 (並在之後將主要區域降級為次要區域) 的過程。 您可能也會看到這個術語容錯移轉，用來描述一般流程。
本節總結地理複製的重要面向。 檢閱完整文件以確切瞭解其運作方式。 如需進一步的資訊，請參閱 服務匯流排地理複製。
需求
區域支援： 你可以選擇任何支援服務匯流排的 Azure 區域作為主要或次要區域。 您不需要使用 Azure 配對區域，因此您可以根據延遲、合規性或數據落地需求來選擇次要區域。
等級： 要啟用地理複製，您的命名空間必須使用高級等級。
中繼資料異地災害復原：無法將命名空間設定為同時使用異地複寫和異地災害復原。
考慮事項
功能限制： 啟用地理複製時，會有一些限制。 如需進一步的資訊，請參閱 服務匯流排地理複製。
私人端點： 如果您使用私人端點連線到命名空間，您也必須在主要和次要區域中設定網路。 更多資訊請參閱 Azure Event Hubs 文件中的 私有端點 。
費用
欲了解地理複製的定價運作方式，請參閱 定價。
設定多區域支援
在新命名空間啟用 Geo-Replication。 若要在建立時啟用命名空間的地理複寫，請參見 切換複寫模式。
從中繼資料地理災難復原遷移到地理複製。你可以從使用中繼資料地理災難復原切換到地理複製。
變更複寫方法。 若要在同步和非同步複寫模式之間進行變更，請參閱 切換複寫模式。
關閉地理複製。 若要關閉地理複製到次要區域，請參見 刪除次要區域。
當所有區域都正常時的行為
本節說明當服務匯流排命名空間被設定為地理複製，且主要區域運作時，應預期的情況。
區域之間的流量路由： 用戶端應用程式會透過命名空間的 FQDN 連線，其流量被導向至主要區域。
只有主要區域在正常操作中主動處理用戶端的訊息。 次級區域接收複製訊息，但其他時間保持被動待機狀態。
區域間的資料複製： 主區與次要區之間的資料複製行為取決於你設定複製配對為同步還是非同步。
同步： 訊息在寫入操作完成前會被複製到次要區域。
此模式能最大程度保證您的訊息資料安全，因為它必須在主區與次要區間提交。 然而，同步複製會大幅增加來訊息的寫入延遲。 同時也要求次要區域可用以接受寫入操作，因此次要區域中斷會導致寫入操作失敗。
- 非同步： 訊息會寫入主要區域，然後寫入操作完成。 不久後，它會將訊息複製到次要區域。
此模式提供比同步複寫更高的寫入輸送量，因為在寫入作業期間沒有區域間複寫延遲。 此外，非同步複製模式能容忍次要區域的遺失，同時仍允許在主要區域進行寫入操作。 不過，如果主要區域發生中斷，任何尚未複寫至次要區域的資料都可能無法使用或遺失。
當您設定非同步複寫時，您可以設定複寫所花費的可接受延遲時間上限。 您可以隨時 使用 Azure 監視器計量來驗證目前的複寫延遲。
如果非同步複寫延遲增加超過您指定的上限，主要區域會開始節流傳入請求，以便複寫能夠趕上。 若要避免這種情況，請務必選取地理位置不太遠的次要區域，並確保您的容量足以滿足輸送量。
即使選擇非同步複製模式，某些元資料類型仍會同步複製。
如需詳細資訊，請參閱 複寫模式。
區域故障期間的行為
本節說明當服務匯流排命名空間被設定為 Geo-Replication，且主區或次要區域發生故障時，應預期的情況。
偵測與回應： 你有責任決定何時將命名空間的次要區域升遷成新的主區域。 Microsoft 不會為您做出這個決定或啟動這個過程，即使發生區域中斷也一樣。 關於決定是否容錯移轉時應考量的建議準則，請參閱觸發促銷的推薦場景。
欲了解更多如何將次級區域升級至新主要區域的資訊，請參見 升級流程。
當您升級次要區域時，請選擇要執行 計劃的升級 或 強制升級。 計劃性升階會先等待次要區域同步完成，再接受新的流量。 這種方法消除了資料遺失，但會造成停機。
在主要區域中斷期間，您通常需要執行強制晉升。 如果主要區域仍然可用，而您因其他原因觸發升階，則可以選擇計劃性升階。
- 通知：Microsoft 不會自動通知你區域故障。 不過，你可以使用 Azure Service Health 來了解整體服務的健康狀況，包括任何區域故障，並且可以設定 服務健康警示 來通知你問題。
目前的請求： 行為取決於區域中斷發生在主要區域還是次要區域：
主要區域中斷： 如果主要區域無法使用，則會終止所有作用中要求。 用戶端應用程式應該在升級完成之後重試作業。
次要區域中斷： 在下列情況下，次要區域中的中斷可能會導致作用中要求發生問題：
如果您使用同步複寫模式，如果任何次要區域無法使用，主要區域就無法完成寫入作業。
如果你使用非同步複製模式，當複製延遲達到最大值後，命名空間會降速，且不再接受新訊息。
若要繼續使用主區域的命名空間，請從 Geo-Replication 設定中移除次要命名空間。
預期資料遺失： 資料遺失量取決於您執行的升級類型 （計劃或強制） 和複寫模式 （同步或非同步）：
計劃推廣： 預計不會遺失資料。 不過，在區域中斷期間，可能無法進行計劃的升級，因為它需要所有主要和次要區域都可用。
強制升級，同步複製： 預計不會遺失資料。
強制升遷、非同步複製： 你可能會遇到一些資料遺失，因為最近的訊息沒有複製到次要區域，或是狀態變更尚未被複製。 數量取決於複寫延遲。 若要確認目前的複寫延遲，請使用 Azure 監視器計量。
如果您執行強制升級，則無法復原遺失的資料，即使在主要區域可供使用之後也是如此。
預期停機時間： 預期停機時間取決於您執行的是計劃升級還是強制升級：
計劃推廣： 計劃升級的第一個步驟會將資料複寫至次要區域。 該流程通常會很快完成，但在某些情況下，可能會花費與複寫延遲相同的時間。 複寫完成後，升級程序通常需要大約 5 到 10 分鐘。 網域名稱系統 （DNS） 伺服器有時可能需要更長的時間來更新項目並將其記錄完全複製到用戶端。
主要區域在整個升階過程中不接受寫入作業。
在區域中斷期間，此選項可能無法實現，因為它需要所有主要和次要區域都可用。
強制升班： 在強制升遷期間，Service Bus 不會等待資料複製完成，而是立即啟動升遷。 推廣過程通常需要大約 5 到 10 分鐘。 有時可能需要更長的時間才能在用戶端之間完全複寫和更新 DNS 項目。
主要區域在整個升階過程中不接受寫入作業。
交通重新路由： 升級完成之後，命名空間的 FQDN 會指向新的主要區域。 但此重新導向取決於用戶端 DNS 記錄的更新速度，包括其 DNS 伺服器是否遵循命名空間 DNS 記錄的存留時間 （TTL）。
區域復原
在原始主要區域復原之後，如果您想要將命名空間傳回其原始主要區域，請遵循相同的區域升級程序。
如果您在區域中斷期間執行強制升級，則即使在主要區域可用之後，也無法復原遺失的資料。
區域故障測試
為了測試 Geo-Replication，暫時將次要區域升為主要區域，並驗證你的客戶端應用程式能在區域間切換，且干擾最小。
監控推廣活動的持續時間，並確認您的 Runbook 和自動化流程是否正常運作。 測試之後，您可以恢復至原始組態。
了解您在升級過程中和之後可能遇到的潛在停機和資料遺失。 為了在非生產環境中測試 Geo-Replication，該環境應與你的生產命名空間配置完全相同。
中繼資料異地災害復原
Premium 等級支援中繼資料的地理災害復原。 此功能可改善從災難案例中復原的能力，包括區域的災難性失效。 Geo-Disaster Recovery 只會複製你命名空間的設定和元資料。 然而，它無法複製訊息資料。 為支援災難復原，此功能確保其他區域的命名空間已預先設定並準備好立即接收用戶端訊息。 異地災害復原是一個單向的復原解決方案，不支援容錯回復到先前的主要區域。
中繼資料地理災害復原最適合那些不需要嚴格維護每條訊息，並能容忍在災難情況下出現部分資料遺失的應用程式。 元資料地理災難復原也可能適用於自行複製資料或不需要資料複製的應用程式。 舉例來說，如果你的訊息是大型圖片，然後再將其轉換為縮圖，你可能會考量可以接受損失失敗區域的部分訊息，以便能夠快速在其他區域重啟新訊息的處理，並且稍後重新構建這些訊息來追上進度。
這很重要
Geo-Disaster 復原能讓設定相同但 不複製訊息資料的操作保持連續性。 如果你需要複製訊息資料，可以考慮使用 Geo-Replication。
當你設定 Metadata Geo-Disaster Recovery 時，你會建立一個別名﹐讓用戶端應用程式連接到。 別名是預設將所有流量導向至主要命名空間的 FQDN。
如果主要區域失敗或發生其他類型的災難，您可以隨時手動起始從主要區域到次要區域的單次單向容錯移轉。 你可以選擇執行 安全故障轉移，等待複製完成後再切換到次要系統，但此選項在區域中斷時可能無法使用。 容錯移轉開始後，幾乎會立刻完成。 在故障轉移過程中，地理災難復原（Geo-Disaster Recovery）別名將重新指向次要命名空間，並解除配對。
本節總結地質災害恢復的重要方面。 檢閱完整文件以確切瞭解其運作方式。 如需詳細資訊，請參閱服務匯流排異地災害復原。
需求
區域支援： 你可以選擇任何支援服務匯流排的 Azure 區域作為你的主或次要命名空間。 您不需要使用 Azure 配對區域，因此您可以根據延遲、合規性或數據落地需求來選擇次要區域。
等級： 若要啟用元資料 Geo-Disaster 恢復，兩個命名空間都必須使用高級等級。
分割： 無法將分割命名空間與非分段命名空間配對。
中繼資料異地災害復原：無法將命名空間設定為同時使用異地複寫和異地災害復原。
考慮事項
功能限制： 啟用 Geo-Disaster 恢復時，會有一些限制。 欲了解更多資訊，請參閱 「重要要點」 及 「考量事項」。
角色指派：對於主要命名空間中之實體的 Microsoft Entra 基於角色的存取控制 (RBAC) 指派不會複寫到次要命名空間。 在次要命名空間中手動建立角色指派，以安全存取這些實體。
應用程式設計： 地理災害復原在設計客戶端應用程式時需要特別注意。 如需詳細資訊，請參閱 注意事項。
私人端點： 如果您使用私人端點連線到命名空間，請在主要和次要區域中設定網路。 如需詳細資訊，請參閱私人端點。
命名空間從標準遷移到高級： 如果你的命名空間之前屬於標準層級，後來遷移到高級層級，你需要用不同的方式處理別名。 欲了解更多資訊，請參閱 服務巴士標準至高級服務。
費用
啟用元資料 Geo-Disaster Recovery 時，您需要承擔主命名空間和次要命名空間的費用。
設定多區域支援
容量規劃和管理
當您規劃多區域部署時，請確定兩個區域都有足夠的容量來處理一個區域失敗時的完整負載。 次要區域在正常作業期間會保持被動狀態，但它必須能在容錯移轉後立刻處理流量。 規劃如何調整次要命名空間容量，使其可以立即接收生產流量。 如果您可以在容錯移轉程序期間容忍額外的停機時間，您可以選擇在容錯移轉期間或之後擴展次要命名空間容量。 若要減少停機時間，請提前在次要命名空間中佈建容量，以便隨時準備好接收生產負載。
當所有區域都正常時的行為
本節說明當服務匯流排命名空間被設定為地理災難復原，且主要區域運作時，預期會發生什麼情況。
區域間流量路由： 用戶端應用程式透過 Geo-Disaster Recovery 別名連接你的命名空間，而他們的流量則會路由到主要區域的主命名空間。
只有主要命名空間在正常操作中會主動處理客戶端的訊息。 次要命名空間在待命模式下保持被動狀態，並且任何存取資料的要求都會失敗。
區域之間的資料複寫： 只有組態中繼資料會在命名空間之間複寫。 配置的複寫會持續且非同步地進行。
所有訊息資料僅保留在主要命名空間，不會複製到次要命名空間。
區域故障期間的行為
本節說明當服務匯流排命名空間設定為異地災害復原且主區域發生中斷時可預期的情況。
檢測和應對： 您負責監視區域健康情況，並手動進行故障轉移。 Microsoft 即使在您的主要區域停止運作時，也不會自動進行容錯移轉或升級次要區域。
欲了解更多如何啟動備援的資訊，請參閱 備援流程。
當您啟動故障轉移時，請選擇執行安全故障轉移或標準（強制，或手動故障轉移）。 安全的容錯移轉會等待完成複寫至次要區域後才開始進行。 此方法減少元資料遺失，但會帶來停機時間。 安全的容錯移轉需要命名空間位在相同的 Azure 訂用帳戶中。
在主要區域發生停電時，通常需要強制切換。 如果主要區域可用，且您因其他原因觸發容錯移轉，可以選擇計劃性容錯移轉。
容錯移轉是單向作業，因此您必須稍後重新建立異地災害復原配對。 如需詳細資訊，請參閱 區域復原。
- 通知：Microsoft 不會自動通知你區域故障。 不過，你可以使用 Azure Service Health 來了解整體服務的健康狀況，包括任何區域故障，並且可以設定 服務健康警示 來通知你問題。
作用中請求： 進行中的作用中要求會在容錯移轉開始時終止。 用戶端應用程式應該在容錯移轉完成之後重試操作。
預期資料遺失：
元數據： 組態和中繼資料通常會複寫至次要命名空間。 但中繼資料複寫會非同步進行，因此最近的變更可能不會複寫，尤其是複雜的變更。 在用戶端存取次要命名空間之前，請先驗證次要命名空間的組態。
訊息資料： 訊息資料不會在區域間複製。 如果主要區域失效，主命名空間的訊息將無法使用。
除非發生災難性災難導致主要區域完全失效，否則訊息不會永久遺失。 如果區域恢復，之後你可以從主命名空間取回訊息。
預期停機時間： 故障轉移通常會在 5 到 10 分鐘內發生。 用戶端可能需要更長的時間才能完全複寫和更新 DNS 項目。
流量重導： 使用 Geo-Disaster Recovery 別名連接命名空間的用戶端，在故障轉移後會自動重新導向到次要命名空間。 但此重新導向取決於 DNS 伺服器是否遵循命名空間 DNS 記錄的 TTL，以及用戶端能夠接收到這些更新的 DNS 記錄。
區域復原
原始主要區域復原之後，您必須手動重新建立配對，或選擇回復至原始主要區域。 建立一個新的地理災害復原配對，將復原區域設為次級區域，然後再進行一次故障轉移，將系統返回至原始區域。 這個過程涉及傳送至臨時主要區域的訊息資料可能會遺失。
如果災害導致主要區域中的所有區域遺失，您的資料可能無法復原。 在其他情況下，你的訊息資料會從故障轉移可恢復前就留在主要命名空間。 在恢復存取權限後，你可以從舊的主要命名空間取得歷史訊息。 你負責設定你的應用程式來接收和處理這些訊息。 Microsoft 不會自動將它們還原至您的次要區域。
區域故障測試
若要測試您的回應和災難復原程序，請在維護時段期間執行計劃性容錯移轉。 從您的主要命名空間啟動容錯移轉至次要命名空間，並確認您的應用程式能夠連線到新的主要命名空間並處理訊息。
監控故障轉移的持續時間，並驗證您的執行手冊和自動化是否正常運作。 測試之後，您可以恢復至原始組態。
了解您在容錯移轉流程期間和之後，可能會遇到的潛在停機和資料遺失問題。 在一個和您的生產命名空間設定相符的非生產環境中測試中繼資料異地災害復原。
自訂多區域解決方案，以實現復原能力
地理複寫與元資料地理災難復原提供對地區中斷及其他問題的韌性，適用於大多數工作負載。 然而，在以下情況下，他們可能不適合你的需求：
- 你有自訂複製或同時維護多個活躍區域的需求。
- 你使用的服務總線層級不支援這些功能。
服務匯流排中有多種設計模式可提供不同類型的多區域支援。 許多模式需要部署多個命名空間，並設定應用程式以適當使用命名空間。 如需詳細資訊，請參閱下列文章：
服務維護的韌性
服務巴士負責定期維護。 在計畫性維護期間，命名空間會被移至包含最新更新的冗餘節點。 隨著此移動，客戶端 SDK 會在命名空間上自動斷線並重新連接。 通常升級會在30秒內完成。 你的應用程式必須準備好應對維護期間發生 的任何暫時性網路斷線 。
欲了解更多資訊，請參閱 Azure Service Bus 維護事件指引。
備份與還原
Service Bus 並非設計為長期儲存資料的地方。 通常，資料會先在主題或佇列中儲存一段短時間，然後被處理或持久保存到另一個資料儲存系統，接著就會被刪除。 由於這樣的設計，服務匯流排會自動維護訊息資料的複本，但不提供訊息資料的備份與還原功能。
對於需要長期訊息保留的情況，可以考慮在 Azure Storage 或其他耐用儲存服務中實作應用程式層級的歸檔。
服務等級協定
Azure 服務的服務等級協定 (SLA) 描述服務的預期可用性，以及解決方案必須符合才能達到該可用性預期的條件。 如需詳細資訊，請參閱 在線服務的 SLA。
Service Bus 為所有命名空間提供 SLA。 當你的命名空間符合以下所有條件時，可用性 SLA 會更高：
- 它使用了高階版本。
- 它位於具有可用性區域的地區。
- 它使用分區。