Azure 事件中樞 地理複製會保留你命名空間的元資料(實體、配置和屬性)以及多個 Azure 區域的事件資料副本。 如果你的主要區域出現故障,你可以推廣到第二個區域,以維持串流應用程式的運作,減少資料損失。
以下章節將說明地理複製的運作方式、同步與非同步複製模式的比較,以及如何管理次要區域。
附註
Event Hubs 的地理複製功能僅在高級與專用層級提供。
異地復寫可確保命名空間的元數據和數據會從主要區域持續復寫到次要區域。 命名空間可以視為延伸至多個區域,其中一個區域是主要區域,另一個區域是次要區域。
隨時可以將次要區域升階為主要區域。 提升次要區域會將命名空間 FQDN (完整網域名稱) 重新指向選定的次要區域,而且先前的主要區域會降級為次要區域。
案例
Event Hubs 的地理複製可用於多種情境。
商務持續性和災害復原
異地復寫可確保命名空間上所有串流數據的災害復原和商務持續性。 藉由跨區域複寫數據,組織可以防範數據遺失,並確保其應用程式即使在發生區域性中斷時仍可運作。 這項功能對於需要高可用性和最短停機時間的任務關鍵性應用程式而言非常重要。
全球資料分布
異地復寫可用來全域散發數據,讓應用程式能夠從最接近的區域存取數據。 這可減少延遲,並改善位於世界不同地區的工作負載效能。
資料主權與合規
在多個國家或地區運作的組織,通常需要遵守資料主權法規,要求資料必須儲存在特定的地理範圍內。 異地復寫可讓這些組織將數據復寫至符合當地法規的區域,確保它們符合法律需求,同時仍維持統一的數據平臺。
移轉和升級
異地復寫也可用來協助數據遷移、維護和系統升級。 組織可以主動將其命名空間從主要區域移轉至次要區域,以允許主要區域的任何維護和升級。
基本概念
地理複製功能使用主次複製模型來複製元資料與資料。 在任何時刻,都有一個主要區域同時服務生產者和消費者。 次要區域作為熱備援區域,所以你無法與次要區域互動。 不過,它會以與主要區域相同的組態執行,這表示提升後它可以快速接手。
地理複製功能的一些關鍵面向包括:
- 主-次級複製模型——地理複製建立在主-次級複製模型上,在特定時間點只有一個主要命名空間服務事件產生者與事件消費者。
- 事件中樞會在次要區域上 (已設定一致性層級),執行中繼資料、事件資料和取用者位移的完全受控位元組對位元組複寫。
- 單一命名空間主機名稱 - 在成功設定具地理複製功能的命名空間後,請在用戶端應用程式中使用該命名空間主機名稱。 主機名稱的行為與已設定的主要和次要區域無關,且一律會指向主要區域。
- 當你發起促銷時,主機名稱會指向被選為新主要區域的區域。 舊的主要區域會成為次要區域。
- 你無法在次級區域閱讀或書寫。
- 從主要區域到次要區域的客戶受控升階提供了中斷解決方案的完整擁有權和可見度。 提供使用的計量可協助自動化用戶端的升階。
- 你可以新增或移除次要區域。
- 複寫一致性 - 有兩種複寫一致性設定:同步與非同步。
| 國家 | 圖表 |
|---|---|
| 容錯轉移之前 (次要區域的升階) |
|
| 容錯轉移之後 (次要區域的升階) |
|
複寫模式
有兩種複製一致性配置可供選擇:同步與非同步。 了解這兩種配置的差異,因為它們會影響你的應用程式和資料一致性。
非同步複寫
使用非同步複製時,主複製會提交所有請求,然後向用戶端發送確認。 複寫到次要區域會以非同步方式進行。 你可以設定最大可接受的延遲時間——即服務端在主區域和次要區域最新動作之間的偏移量。 服務會持續復寫數據和元數據,確保延隔時間盡可能小。 如果作用中的次要區域的延遲超出了使用者設定的最大複寫延遲值,則主要區域就會開始限制傳入的要求速率。
同步複寫
使用同步複寫時,系統會將所有請求發送到次要位置。 次要位置會在主要位置認可之前先認可並確認作業。 因此,你的應用程式的發佈速度會與發佈、複製、確認和提交這些過程所需的速度一致。 這個流程意味著你的申請取決於兩個地區的可用性。 如果次要區域延遲或無法使用,主要區域不會回應或提交訊息,並會限制收到的請求。
復寫一致性比較
使用同步複寫:
- 由於分散式認可作業,導致較長的延遲。
- 可用性取決於兩個地區的可用性。 如果某個區域關閉,您的命名空間將無法使用。
另一方面,同步複寫可提供您資料安全的最大保證。 透過同步複製,資料會在你設定的所有地理複製區域提交,提供最佳的資料保障。
使用自動非同步複寫:
- 延遲受影響很小。
- 失去次要區域不會立即影響可用性。 然而,一旦達到設定的最大複製延遲,可用性就會受到影響。
因此,它無法像同步複製那樣絕對保證所有區域在提交前都擁有資料,因此可能會發生資料遺失或重複。 不過,由於您不再會因單一區域的延遲或無法使用而立即受到影響,應用程式的可用性提升,延遲也降低了。
| 能力 | 同步複寫 | 非同步複寫 |
|---|---|---|
| 延遲 | 由於分散式認可作業,導致較長的延遲 | 影響極小 |
| 可用性 | 與次要區域的可用性相關聯 | 失去次要區域不會立即影響可用性 |
| 資料一致性 | 在確認之前,一律會在這兩個區域中進行資料認可 | 只有在確認之前,才會在主要環境中認可資料 |
| RPO (復原點目標) | RPO 0,升階時不會遺失資料 | RPO > 0,升階時可能會遺失資料 |
你可以在設定好地理複製後更改複製模式。 你可以從同步切換到非同步,或從非同步切換到同步。 如果你從非同步切換到同步,次要區域會在延遲降為零後設定為同步。 如果您因任何原因持續出現延遲,可能需要暫停您的發行者,讓延遲降到零,並讓模式能夠切換為同步。 啟用同步複製而非非同步複寫的原因,主要與資料的重要性、特定業務需求或合規考量相關,而非應用程式的可用性。
附註
如果次要區域延遲或無法使用,應用程式無法複製到該區域,當複製延遲達到時就會開始限速。 若要繼續在主要位置使用命名空間,請移除受影響的次要區域。 如果你移除所有次要區域,命名空間會繼續存在,且不啟用地理複製。 你可以隨時新增其他次要區域。 最上層實體是事件中樞,不論設定的複寫模式為何,都會以同步方式複寫。
次要區域選擇
要啟用地理複製功能,請使用啟用該功能的主區域與次要區域。 地理複製功能依賴於能夠將已發佈訊息從主區域複製到次要區域。 若次級區域位於其他大陸,此選擇對從初級區域到次級區域的複製延遲有重大影響。 如果你是為了可用性而使用地理複製,盡量選擇同一大陸的次要區域。 為了更了解地理距離引起的延遲,請參閱 Azure 網路往返延遲統計。
附註
地理複寫要求事件中樞的主要和次要複本位於相同的層級。 你無法跨層設定地理複製。
地理複製管理
地理複製功能讓你能設定一個次要區域,讓中繼資料和資料被複製到那裡。 因此,您可以執行以下管理任務:
- 設定地理複製 - 你可以透過啟用區域複製功能,在區域內任何新設或現有命名空間上設定次要區域。
- 設定複製一致性 - 設定地理複製時,請設定同步與非同步複製。 你也可以之後切換這個設定。
- 觸發程序升階/容錯移轉 - 所有升階都是客戶起始的。
- 移除次要 區域——如果你想移除次要區域,可以這麼做。 次要區域的資料會被刪除。
觸發升階的準則
以下列出一些可能觸發將次要角色提升為主要角色的情況。
區域故障:若主要區域發生區域故障,應提升次要區域,以確保業務連續性並減少停機時間。
維護活動:在主要區域的計畫性維護活動中,推廣次要區域有助於維持關鍵任務應用的高可用性。
災難復原:若主要區域發生災難,推廣次要區域確保資料保持可存取,應用程式持續運作。
效能問題:若主要區域出現影響活動中心可用性或可靠性的效能問題,提升次要區域有助於緩解這些問題。
偶爾測試故障轉移機制,確保業務持續計畫有效,且您的應用程式能在需要時無縫切換到次要區域。
監視資料複寫
你可以透過在應用程式指標日誌中查看複製延遲指標來監控複製作業的進度。
依照監視 Azure 事件中樞- Azure 事件中樞| Microsoft Learn,在 Event Hubs 命名空間中啟用應用程式指標記錄。
啟用應用程式指標日誌後,先從命名空間產生並使用資料幾分鐘,再開始查看日誌。
要查看應用程式指標日誌,請前往事件中心頁面的 監控 區塊,並在左側選單選擇 日誌 。 請使用以下查詢來找出主命名空間與次要命名空間間的複製延遲(秒數)。
AzureDiagnostics | where TimeGenerated > ago(1h) | where Category == "ApplicationMetricsLogs" | where ActivityName_s == "ReplicationLag"欄位
count_d顯示主區與次級區間的複製延遲,單位為秒。
發行資料
發佈應用程式可以透過支援地理複製的命名空間的命名空間主機名稱,將資料傳送到地理複製的命名空間。 發佈方式與非地理複製的情況相同。 你不需要對資料平面 SDK 或客戶端應用程式做任何修改。
在下列情況中可能不適用事件發佈:
- 要求升階次要區域之後,現有的主要區域會拒絕發佈到事件中樞的任何新事件。
- 當主要和次要區域之間的複寫延遲達到複寫延遲持續時間上限時,發行者輸入工作負載可能會受到節流。
發行者應用程式無法直接存取次要區域中的任何命名空間。
資料消耗
取用應用程式可以使用已啟用異地複寫功能之命名空間的命名空間主機名稱來取用資料。 消費者營運從促銷開始到促銷結束都不會得到支援。
檢查點與偏移管理
事件取用應用程式可以用與非異地複寫命名空間相同的方式維持位移管理。 支援地理複製的命名空間在偏移管理上不需要特別考量。
警告
在強制容錯移轉 (也就是非正常容錯移轉) 的情況下,可能會遺失部分尚未複製過去的資料。 這種資料遺失可能導致該特定資料在命名空間的主區與次區間的偏移量不同。 然而,偏移量仍維持在命名空間設定的最大複製延遲範圍內。 在這類情況下,請從最後認可的位移開始取用。 有些資料可能會重複處理,必須在用戶端處理。
Kafka
取用者會直接將位移認可到 Event Hubs,系統會跨區域複寫位移。 因此,消費者可以從主要區域停止消費的地方開始消費。
以下是支援的 Apache Kafka 用戶端清單:
| 用戶端名稱 | 版本 |
|---|---|
| Apache Kafka | 2.1.0 或更新版本 |
| Librdkafka 和衍生函式庫 | 2.1.0 或更新版本 |
對於其他函式庫,支援取決於 API 版本:
| API 名稱 | 支援的版本 |
|---|---|
| 元數據 API | 7 或更新版本 |
| 擷取 API | 9 或更新版本 |
| ListOffset API | 4 或更新版本 |
| OffsetFetch API | 5 或更新版本 |
| OffsetForLeaderEpoch API | 0 或更新版本 |
Event Hubs SDK 與 AMQP
對於 AMQP,使用者會透過檢查點儲存(如 Azure Blob 儲存)或自訂儲存解決方案來管理檢查點。 如果發生故障轉移,二級區域必須有檢查點儲存庫,以便用戶端能取得檢查點資料並避免訊息遺失。
最新版本的 Event Hubs SDK 包含檢查點表示法的更動,以支援容錯切換。 請使用最新版本的 SDK,但也支援以下 SDK 的舊版本。
| 語言 | 封裝名稱 |
|---|---|
| C# | Azure.Messaging.EventHubs |
| C# | Microsoft.Azure.EventHubs |
警告
作為實作的一部分,當你在命名空間啟用地理複製時,檢查點格式會被調整。 隨後的檢查點在地理複製配對後會以新格式寫入。 如果你在地理複製配對完成後、但新檢查點尚未儲存之前,強制將次要區域升為主要區域(這種情況可能發生在強制升遷或故障轉移時),升遷後發布的新資料可能會遺失。
在這類情況下,請從最後認可的位移開始取用。 有些資料可能會重複處理,必須在用戶端處理。
升級到 最新版本的 SDK。
考慮事項
請記住以下考量:
- 在你的推廣規劃中,請考慮時間因素。 例如,如果您中斷連線時間超過 15 到 20 分鐘,您可能會決定起始升階。
- 您應至少演練一次提升複雜分散式基礎結構的程序。
定價
價格會依你選擇的等級而異,但通常有兩個參數:
- 叢集或命名空間的計算費用。
- 主要區域與次要區域之間複製數據的頻寬費用。
附註
欲確定費用,請參閱Azure 事件中樞所列價格詳情。 地理複製的電荷取決於主要區域的位置。
專用叢集
當你使用地理複製搭配 Event Hubs 專用叢集時,至少需要兩個獨立區域的專用叢集。 你可以用這些叢集來承載除被地理複製的命名空間以外的命名空間。 你根據分配給每個叢集的容量單元(CU)數量,分別付費使用這些專用叢集。
啟用地理複製時,唯一額外的費用是從主複製到次要資料的頻寬費用。 此費用取決於主要區域的位置。
進階命名空間
對於高級命名空間,啟用地理複製後,次要區域中處理單元(PU)數量相同。 你要為你使用的 PU 數量 以及在 主區和次要區域之間傳輸的資料頻寬付費。
舉例來說,如果你在一個已配置為 4 個 PU 的 Premium 命名空間中啟用地理複寫,你需要付費。
- 主要區域的 4 個 PU 費用、
- 次要區域的 4 個 PU 費用、
- 每 GB 複寫資料量計算的異地複寫費用。
你需支付的是根據主區和次要區之間傳輸的資料所計算的頻寬費用。
定價計量
地理複製資料傳輸頻寬費用的計費指標顯示如下:
| 產品名稱 | 儀表說明 |
|---|---|
| 服務匯流排 | 服務匯流排 - 異地複寫區域 1 GB 資料傳輸 - 區域名稱 |
| 服務匯流排 | 服務匯流排 - 異地複寫區域 2 GB 資料傳輸 - 區域名稱 |
| 服務匯流排 | 服務匯流排 - 異地複寫區域 3 GB 資料傳輸 - 區域名稱 |
私人終端節點
用戶端透過 私有端點 連接到事件中心命名空間,故障轉移後會自動連接到新的主區域。 Event Hubs 命名空間會將流量導向目前的主要區域,客戶端不需要知道哪個區域是主要區域,私有端點也能持續運作,沒有任何變動。 推廣通常在兩分鐘內完成,客戶可能會看到短暫錯誤並重新連線。 請依此設定重試策略。
私有端點是區域資源。 為了高可用性,請將應用程式部署在多個區域,並在每個區域的虛擬網路中建立私有端點。
DNS
每個區域只設一個 privatelink.servicebus.windows.net 私人 DNS 區域,且只連結到該區域的虛擬網路。 當你附加私人 DNS 區域群組時,本地私有端點的 A 紀錄會自動加入。 每個區域都會將命名空間名稱解析為其本地端點,無論哪個區域是主要區域。
如果你在兩個虛擬網路共用同一個私有 DNS 區域,只有一個 A 紀錄存在,並且指向最後連接的那個端點。 在這種情況下,可以新增 跨區虛擬網路對等連線 ,讓所有用戶端都能連線到該端點。
對於內部部署用戶端,請透過條件式轉送或手動維護的記錄,將命名空間解析至最近區域的私人端點。 推廣不需要在本地更改 DNS。
故障切換情境
- 僅用於應用程式的故障轉移。 應用程式會移至另一個虛擬網路。 它透過本地私有端點抵達命名空間。
- 僅限命名空間的故障轉移。 Event Hubs 的主要角色已移轉。 用戶端會保留相同的 連接字串 和本地端點;流量會自動路由到新的主節點。
- 區域性中斷。 受影響區域的私人端點無法連線。 在健康區域中具有私人端點的客戶端會繼續在存留的區域上運作。
相關內容
若要了解如何使用異地複寫功能,請參閱使用異地複寫。