本文介紹了 Kafka 跨資料中心的兩種部署方式，簡要分析兩種方式下的不同架構以及優缺點，對這些架構可能碰到的問題也提供了一些解決思路；同時也說明了 Kafka 跨資料中心部署的社群解決方案和商業化解決方案。
背景
Kafka 作為世界上最流行的消息中間件之一，一般是客戶資料鍊路中的核心元件，高可用性是客戶很關注的因素。近期在對接雲上客戶時發現，客戶對 Kafka 的高可用也有需求，行業架構師也想了解 Kafka 高可用的方案細節；有些客戶是需要雲上 Kafka 的高可用能力，有些客戶需要 IDC 中的 Kafka 與雲上 Kafka 建立高可用架構；有些客戶需要與其他友商雲進行跨雲高可用。單叢集的高可用讨論得比較多，但跨資料中心的方式比較多，相對複雜。本文希望借由對 Kafka 跨資料中心高可用架構的分析，為以上場景的解決方案提供一些思路。
相關術語
- RTO(Recovery Time Objective)：即資料恢複時間目标。指如果發生故障，發生故障轉移時業務系統所能容忍的最長停止服務時間。如果需要 RTO 越低，就越要避免手工操作，隻有自動化故障轉移才能實作比較低的 RTO。
- RPO(Recovery Point Objective)：即資料恢複點目标。指如果發生故障，故障轉移需要從資料曆史記錄中的哪個點恢複。換句話說，有多少資料會在故障期間丢失。
- 災難恢複(Disaster Recovery): 涵蓋所有允許應用程式從災難中恢複的體系結構、實作、工具、政策和過程的總稱，在本文檔的上下文中，是指整個區域故障。
- 高可用性(High Availability): 一個高度可用的系統即使在出現故障的情況下也可以連續運作。在多區域架構的上下文中，高可用性應用程式即使在整個區域故障期間也可以運作。HA 應用程式具有災難恢複政策。
發生故障的場景
在目前基礎設施豐富的時代，我們很容易認為不需要考慮故障場景。然而現實情況是，不論是在虛拟化或容器化架構下，還是在提供成熟服務的雲廠商上，盡管機率各不相同，但都有可能發生局部和系統故障。架構師需要考慮特定類型故障的可能性以及對其整體系統可用性的影響。
下面列出一些典型的故障場景：
| 序号 | 故障場景 | 影響 | 緩解措施 |
| 1 | 單節點故障 | 單個節點或托管在該節點上的 VM 的功能喪失 | 叢集部署 |
| 2 | 機架或交換機故障 | 該機架内托管的所有節點/虛拟機（和/或連接配接）丢失 | 叢集部署分布在多個機架和/或網絡故障域中 |
| 3 | DC/DC-機房故障 | 在該 DC/DC 機房内托管的所有節點/虛拟機（和/或連接配接）丢失 | 擴充叢集、複制部署 |
| 4 | 區域故障 | 該區域内托管的所有節點/虛拟機（和/或連接配接）丢失 | 地理延伸叢集（延遲相關）和/或複制部署 |
| 5 | 全球性系統性中斷（DNS 故障、路由故障等） | 影響客戶和員工的所有系統和服務完全中斷 | 離線備份；第三方域中的副本 |
| 6 | 人為行為（無意或惡意） | 在檢測之前，人為行為可能會破壞資料和任何同步副本的可用性 | 離線備份 |
這篇文章重點圍繞故障場景2、3、4說明 Kafka 中有哪些方案來應對這幾類故障場景。第1種單節點故障，Kafka 叢集高可用可以應對；第5、6種故障可以考慮将資料存儲到第三方系統，如果在雲上可以轉儲到 COS 。
Kafka體系架構簡介
以下是 Kafka 的軟體架構，整個 Kafka 體系結構由Producer、Consumer、Broker、ZooKeeper 組成。Broker 又由 Topic、分區、副本組成。
詳細可以參考Kafka官方文檔：https://kafka.apache.org/documentation/#introduction。
單套 Kafka 叢集是通過副本複制來保障叢集的高可用，但在實際生産情況下，單資料中心單叢集不一定能滿足生産上需要的高可用需求，也難以應對複雜的業務場景。我們下面來看看跨資料中心下幾種常見的應用場景。
跨資料中心的應用場景
- 跨地域複制
有時候，一家公司可能會在不同的地理區域、城市或大洲有多個資料中心。每個資料中心都有自己的 Kafka 叢集。有些應用程式隻需要與本地的 Kafka 叢集通信，有些應用程式則需要通路多個資料中心的資料（否則就沒有必要跨資料中心的複制方案了）。有很多情況需要跨資料中心通路資料，例如，根據供需情況修改商品價格就是一個典型的應用場景。該公司在每個城市都有一個資料中心，用于收集每個城市的供需資訊，然後根據整體的供需情況調整商品價格。這些資訊會被鏡像到中心叢集，然後業務分析員會基于中心叢集中的資料生成整個公司的收益報告。
- 災備
Kafka 叢集可能因為某些原因不可用，為了實作備援，需要有另外一個與第一個叢集完全相同的叢集。如果有第一個叢集不可用的情況發生，可以将應用程式重新定向到第二個叢集。
- 叢集的實體隔離
有些客戶需要将生産環境資料鏡像到測試環境，進行驗證。
- 雲遷移和混合雲部署
在雲計算流行的今天，部分公司會将業務同時部署在本地IDC 和雲端。本地 IDC 和每個雲服務區域可能都會有 Kafka 叢集，應用程式會在這些 Kafka 叢集之間傳輸資料。例如，雲端部署了一個應用，它需要通路 IDC 裡的資料，IDC 裡的應用程式負責更新這個資料，并儲存在本地的資料庫中，可以捕獲這些資料變更，然後儲存在 IDC 的 Kafka 叢集中，然後再鏡像到雲端的 Kafka 叢集中，讓雲端的應用程式可以通路這些資料。這樣既有助于控制跨資料中心的流量成本，也有助于提高流量的監管合規性和安全性。
- 法律和法規要求
越來越多的國家和地區對資料安全都很重視，都有出台相應的資訊保護法律法規。如果有資料涉及到跨境被通路，可以利用 Kafka 的鏡像能力，在傳輸到境外之前，進行資料脫敏、傳輸加密等一系列的處理。為了符合不同國家的法律和監管要求，一家公司在不同國家的營運也可能需要不同的配置和政策。例如，一些資料可能需要被儲存在具有嚴格通路控制的獨立叢集中，一些資料則可以被複制到具有寬松通路權限的其他叢集。為了滿足不同區域對資料保留期限的合規性要求，儲存在不同區域叢集中的資料可以使用不同的配置。
跨資料中心 Kafka 的部署形态
一般來說，Kafka跨資料中心部署大體分兩種形态：Stretched Cluster和Connected Cluster。
Stretched Cluster
延展叢集，它本質上是單個叢集，是使用 Kafka 内置的複制機制來保持Broker副本的同步。通過配置min.insync.replicas 和 acks=all，可以確定每次寫入消息時都可以收到至少來自兩個資料中心的确認。
Connected Cluster
連接配接叢集，是通過異步複制完成多地域複制，并且使用外部工具将資料從一個（或多個）叢集複制到另一個叢集。該工具中會有 Kafka 消費者從源叢集消費資料，然後利用 Kafka 生産者将資料生産到目的叢集。但 Confluent 提供了一種不使用外部工具實作此功能的連接配接叢集，在下面介紹商業化方案的時候再詳細說明。
下面是這兩種部署形态的對比：
| 部署形态 | 資料傳輸方式 | Offset保留 | 延遲 | RTO&RPO | 何時使用 |
| Stretched Cluster | 同步 | 可以 | 無 | 資料中心距離較短 | |
| Connected Cluster | 異步 | 可以 | 取決于網絡 | >0 | 資料中心較遠 |
基于這兩種部署形态，跨資料中心會有如下幾種部署架構。
跨資料中心 Kafka 的部署架構
延展叢集 2AZ
Kafka 的 Broker 跨兩個資料中心組成叢集，Zookeeper 是 Hierarchical Quorum 模式。資料中心的 Kafka 叢集直接連接配接本地的 Zookeeper 組。延展叢集2AZ部署架構如下：
如果 DC1 不可用，用戶端在另外一個資料中心也失去了分區 Leader。要麼部分生産，要麼停止生産，這取決于複制因子的配置。
如果某個資料中心發生故障，可以通過如下方式進行切換。
①DC1 發生故障
②不能選擇 Leader 分區
③從配置檔案中移除不可用的 ZK 和 Group
④在 DC2 中選擇新的 Leader 分區
⑤将 min.insync.replica 從3修改為2
⑥生産者可以發送消息給新的 Leader 分區
可以看到延展叢集 2AZ 的架構并非标準的高可用解決方案。如果出現某個資料中心不可用，需要手動調整配置檔案，手動重新拉起ZK叢集。是以整個過程 RTO 和 RPO 都是大于0。現有的解決方案中，Confluent 提供的 Linker 産品更适用 2AZ 高可用的場景，在下面的商業化解決方案中再詳細介紹。
延展叢集 2.5AZ
延展叢集 2.5AZ 的架構包含兩個完全運作的可用區，和一個運作單個延展叢集的輕可用區(0.5)。Zookeeper 需要跨3個資料中心部署，每個資料中心一個 ZK 節點。如果某個資料中心不可用，故障切換的 RTO 和 RPO 都是0。在 2.5AZ 的部署架構下，如果副本數設為3，并且 Acks=all，min.insync.replicas=2，那麼3副本的分布為2+1。此時如果2副本的資料中心不可用，因為最小 ISR 設為了2，是以叢集的寫入将不可用，但消費不受影響。
延展叢集 2.5AZ 的部署架構如下：
延展叢集 3AZ
該架構跨3個資料中心部署一個叢集，RTO 和 RPO 在一個資料中心故障時為 0。這種模式是所有模式中最簡單、最健壯的。這種模式在公共雲中非常常見（使用多個可用區）。也不會有 2.5AZ 最少 ISR 不夠用的風險。
延展叢集3AZ的部署架構如下：
通過配置 min.insync.replicas 和 Acks=all，可以確定每次寫入消息時都可以收到至少來自兩個資料中心的确認。從Kafka 2.4.0開始，消費者可以基于機架資訊從最近的副本擷取資料。從本地資料中心的 Follow 副本讀取資料可以提高吞吐量、降低延遲和成本，因為跨資料中心的流量減少了。
連接配接叢集-災備架構
Parimay 叢集(主)将資料鏡像到備用叢集(被動)使用 MM2。當主用站點故障時，您需要移動生産者和消費者應用程式到備用站點。RTO 取決于備用站點的升溫程度向上當涉及到 RPO 時，可能會發生資料丢失因為 MM2 異步複制資料主用站點到備用站點。
這種架構的好處是比較好實作，隻需要安裝第二個叢集，然後使用鏡像工具将第一個叢集的資料完全鏡像到第二個叢集中。但這個架構最大的問題在于浪費一個叢集，并且 Kafka 的故障轉移很難完全做到既不丢資料，也無重複資料。我們隻能盡量減少這些問題的發生，但是無法完全避免。
Kafka 已知的鏡像方案都是異步的，是以災備叢集無法及時擷取主叢集的主要資料。我們需要監控同步延遲，來确認災備叢集落後主叢集多少，并確定不要落後太多。如果有故障轉移計劃，可以先停止主叢集，等鏡像程序将剩餘資料同步完畢，然後再切換到災備叢集，這樣可以避免資料丢失。如果發生了非計劃内的故障轉移，切換到災備叢集可能會丢失一部分消息。
另外，目前社群鏡像方案還不支援 EOS(Exactly-once Semantics)，如果主叢集有事務消息，同步到災備叢集，有些消息可能會丢失。切換到災備叢集，還有個比較大的挑戰是消費者位點的同步。MM1 并不能承諾消費者位點能夠同步，是以早期版本（2.4版本以前）的 Kafka 災備切換，消費位點要麼從起始位置開始讀取資料，要麼從末尾開始讀取資料。從起始位置讀取會帶來大量的重複資料；從末尾開始讀取資料，可能丢棄部分資料。一般來說，從末尾讀取資料更為常見。從 Kafka0.10 之後，Kafka 每條消息都包含了一個時間戳，是以也可以根據時間點來調整消費位移點。跟随 Kafka 2.4 一起推出的 MirrorMaker2 （以下簡稱MM2）是下一代的多叢集鏡像解決方案，修複了 MirrorMaker1 的局限性。
連接配接叢集-雙活架構
當有兩個或者多個資料中心需要共享部分或全部資料，并且每個資料中心都可以生産或者消費資料，可以使用雙活架構，如下圖所示：
資料中心運作單獨的 Kafka 叢集，每個叢集都是另外一個叢集的副本。當一個資料中心發生故障，應用程式将故障轉移到另外一個資料中心。
雙活架構可能遇到的一些問題。
- 資料鏡像延遲問題。如果使用者向一個資料中心生産資料，從另外一個資料中心消費資料，生産的資料可能還沒有鏡像到另外一個資料中心。
- 多資料中心重複消費問題。要小心避免同一條消息被鏡像到兩個或多個資料中心，被消費多次。需要根據實際情況選擇合适的方法，比如給每條消息設定一個 ID，通過消息 ID 來檢測是否被重複消費過。或者根據消息上帶的時間戳，消費前檢查該時間戳是否被消費過。
- 配置和管理的複雜性。需要在兩個或多個資料中心之間配置和管理多個 Kafka 叢集，如果配置不當或者管理不當，可能會導緻資料同步失敗或者資料丢失。同時也需要有完善的監控系統來觀測鏡像的情況，如鏡像延遲，鏡像速率等。
- 消息循環鏡像。需要避免消息在兩個或多個資料中心來回鏡像。可以通過在不同的資料中心設定單獨的 Topic，并確定不要從不同的資料中心鏡像同名的Topic。如 MirrorMaker2 就是通過在目标叢集的Topic上中帶 Kafka 執行個體 ID 來避免循環鏡像。或者通過消息 Head 中包含資料中心資訊，進而避免循環鏡像。
跨資料中心 Kafka 解決方案
社群解決方案
社群方案中的延展叢集利用 Kafka 自身的同步機制達到高可用的效果，并不需要借助于外部工具。針對連接配接叢集，社群解決方案主要是借助于 Kafka 自帶的MirrorMaker工具。早期的MirrorMaker1(以下簡稱MM1)存在一些問題。
比如：
- 目标叢集的 Topic 使用預設配置建立，但通常需要手動分區。
- ACL 和 Topic 配置的變更不會自動同步
- 消息會被 DefaultPartitioner 打散到不同分區，即對一個Topic ，目标叢集的 Partition 與源叢集的 Partition 不一緻。是以也沒辦法保障順序消息。
- 不保證 Exactly-Once 語義，可能出現重複資料的情況
- MM1 支援的資料備份模式較簡單，比如無法支援 Active/Active 模式
- Rebalance 可能會導緻鏡像延遲
- 不支援消費 Offset 同步
因為存在這些問題，MM1 很難在生産環境中使用。是以在 Kafka2.4 版本中，推出了一個新的 MirrorMaker2（以下簡稱MM2），MM2 基于 Kafka Connect 架構，解決了上面大部分的問題。
下圖是 MM2 在主備架構中的應用。
可以在 MirrorMaker2 下配置複雜的拓撲來支援更為廣泛的的場景。比如有 Kafka 叢集 A、B、C。雙活高可用可配置：A→B，B→A。災備叢集可配置：A→B。聚合：A→C，B→C。扇出可配置：C→A，C→B。鍊式複制可配置：A→B，B→C。
為避免添加新的 Topic 或分區發生再均衡而導緻延遲激增，在配置設定分區時，MirrorMaker2 并沒有使用 Kafka 的消費群組管理協定。源叢集的每個分區的消息都可以鏡像到目标叢集的相同分區。如果源 Topic 添加了分區，那麼目标 Topic 也會自動建立對應的分區。除了可以複制中繼資料、消息資料，MM2 還支援消費者偏移量、Topic 配置和 ACL。
MM2 的具體配置也可以參考：https://kafka.apache.org/documentation/#georeplication-mirrormaker ，文檔裡面包含 MM2 相關的 KIP-382，有興趣可以了解下。
開源&商業化方案
Uber 的 uReplicator
uReplicator 是 UBber 開源的 Kafka 叢集複制開源項目，基于 MirrorMaker1 的改進版，使用 Apache Helix 作為中心控制器，用于管理 Topic 清單和配置設定給每個 uReplicator 執行個體的分區。管理者可以通過 REST API 添加新的 Topic，uReplicator 負責将分區配置設定給不同的消費者。uReplicator 引入 Helix，取代了 High-Level Consumer 裡面的 Consumer Group Coordinator 角色，消費者的分區由 Helix 控制器負責配置設定，不需要在消費者之間進行協調，避免了再均衡。
uReplicator 借助于 Helix 解決了 MM1 的一些痛點問題，但是也帶來了額外的複雜性。MM2 解決了 MM1 的伸縮性和容錯性問題，并且不需要依賴外部元件。想對 uReplicator 有更多了解，可以參考官方部落格。
Confluent 的 Replicator
Confluent Replicator 允許您輕松可靠地将主題從一個 Kafka 叢集複制到另一個叢集。除了複制消息外，Replicator 還會根據需要建立主題，保留源叢集中的主題配置。這包括保留分區數、複制因子以及為單個主題指定的任何配置覆寫。和MirrorMaker類似，Confluent Replicator 也依賴于 Connect 架構，并可以在 Connect 叢集中運作。
Confluent Replicator 支援各種拓撲的資料複制以及消費者偏移量和 Topic 配置資訊的遷移，但與 MirrorMaker2 不同，Confluent Replicator 不支援 ACL 遷移；并且Replicator 不使用遠端 Topic 避免循環複制，而是使用源頭來避免循環複制。同時 Replicator 提供一系列名額，比如複制延遲，還可以通過 REST API 或者控制台 UI 來監控這些名額。
Confluent 的 Cluster Linker
Confluent 的 Cluster Linker 可以使能夠直接将叢集和鏡像 Topic 從一個叢集連接配接到另一個叢集。Cluster Linker 使建構多資料中心、多區域和混合雲部署變得更為容易。它是安全的，高性能的，容忍網絡延遲，并内置于 Confluent 伺服器和 Confluent 雲。通過 Cluster Linker，可以實作多區域高可用性，同時可以支援災難恢複、全局複制、資料共享以及叢集遷移等需求。
與 Replicator 和 MirrorMaker 2不同，叢集連結不需要運作 Connector 來将消息從一個叢集移動到另一個叢集，并且它建立具有全局一緻偏移量的相同的“鏡像主題”。源主題上的消息精确地鏡像到目标叢集上，在相同的分區和偏移量上。鏡像主題中不會出現與源主題所包含内容相關的重複記錄。
Cluster Linker 将 Topic 副本複制協定用在了叢集複制上，可以跨叢集進行帶消費 Offset 遷移的資料複制，不需要進行 Offset 轉換。Topic 配置資訊、分區、消費者 Offset 和 ACL 都可以在兩個叢集直接同步，以便在發生災難時實作低 RTO 的故障轉移。目标叢集上鏡像 Topic 的 Leader 分區從對應的源 Leader 那裡擷取分區資料，目标叢集上鏡像 Topic 的 Follower 使用 Kafka 标準的 Replication 機制從本地 Leader 那裡複制資料。目标叢集的鏡像 Topic 會被定義成隻讀，防止本地生産者将資料生産到這些主題。
Cluster Linker 比 MM2 或 Replicator 優勢的地方在于，不需要維護一個 Connector 叢集，并且比外部工具更高效，避免了 Connector 叢集鏡像資料時需要解壓縮和再壓縮，同時 Cluster Linker 可用于網絡不可靠且高延遲的資料中心，它隻在資料中心之間複制一次資料，減少了跨資料中心的流量。但 Cluster Linker 沒有類似 MM2 的鏡像配置選項，缺少鏡像配置的靈活性。同時，如果發生了故障轉移，需要重新開機用戶端，将網絡連結到目标叢集上。Cluster Linker 一般适用于遷移叢集和需要共享主題的場景。
Confluent 的 Multi-Region Cluster
Confluent 的 Multi-Region Cluster（以下簡稱MRC）适用于延遲在50ms以内的資料中心，它同步組合了同步複制和異步複制，以此來降低對生産者性能的影響，并能提供給更高的網絡容錯性。
Confluent Server 通常跨可用性區域或附近的資料中心運作。如果跨可用性區域或附近資料中心的代理之間的計算機網絡在可靠性、延遲、帶寬或成本方面不同，這可能會導緻更高的延遲、更低的吞吐量以及生産和使用消息的成本增加。
為了緩解這種情況，Confluent Server 添加兩個增強的能力：
- Follower-Fetching：Kafka 允許用戶端從 Follower 副本讀取資料，用戶端可以根據機架 ID從最近的broker擷取資料，進而減少了跨資料中心的流量。
-
Observers：社群 Kafka 有兩種類型的副本，Leader 和 Follower。Multi-Region Cluster 引入了第三種類型的副本，觀察者。預設情況下，觀察者不會加入同步副本 (ISR)，但會像 Follower 一樣努力跟上 Leader 的步伐。通過 Follower 擷取，客戶也可以從 Observer 那裡消費。通過不加入 ISR，Observer 使操作員能夠異步複制資料。在 Confluent Server 中，主題分區的高水位線不會增加，直到 ISR 的所有成員都确認他們已經複制了一條消息。使用的用戶端 Acks=all 可能會遇到吞吐量問題，尤其是在涉及跨資料中心的高延遲、低帶寬網絡時。使用 Observer，可以定義在一個區域内同步複制資料但在區域之間異步複制資料的 Topic。預設情況下，這些 Observer 不加入 ISR，是以它們不會影響排除消息的吞吐量和延遲，因為主題分區 Leader 在向生産者确認請求之前不需要等待它們被複制到 Observer。
Confluent Server 支援自動觀察者提升(Automatic Observer Promotion)，可以自動将 Observer 提升到同步副本清單 (ISR) 中。這在某些降級情況下可能是很有用的。例如，如果分區的 ISR 數量小于 min.insync.replicas 的值，那麼該分區通常會不可用。通過自動觀察者提升，一個或多個 Observer 可以取代 ISR 中的 Follower，保持分區線上，直到不可用的 Follower 恢複。一旦 Follower 被恢複（他們被趕上并重新加入 ISR），觀察者就會自動從 ISR 中降級。
總結
本文介紹了 Kafka 跨資料中心的兩種部署方式，簡要分析了兩種方式下的不同架構以及優缺點，對這些架構可能碰到的問題也提供了一些解決思路；同時也說明了 Kafka 跨資料中心部署的社群解決方案和商業化解決方案。
随着資料中心故障的不可避免，作為核心資料鍊路中的 Kafka 的高可用也得到更多的重視。Kafka 跨資料中心部署方式中，Stretched Cluster 采用同步的方式複制資料，RTO&RPO 是0；Connected Cluster 采用異步的方式複制資料，RTO&RPO一般大于0。如果自建 Connected Cluster，那麼需要做好故障切換的演練。大家可以根據實際場景需求來選擇相應的部署架構，一種場景并不見得隻有一種解決方案架構能滿足。或者為了省心，可以在騰訊雲上直接選擇 Ckafka。
騰訊雲 CKafka 在公有雲上也提供跨可用區叢集的産品化能力，支援 Streched Cluster 2.5AZ 和 Streched Cluster3AZ 兩種部署架構；也支援 Connected Cluster，支援多個叢集直接互相複制，支援多種複制拓撲。已經有衆多的大客戶在雲上選擇了 Ckafka。