需求意義

在 Geo-Replication 的設計支撐下，其一，我們可以比較容易的將服務分散到多個機房；其二，可以應對機房級別的故障，即在一個機房不可用的情況下，服務可以轉接到其它的機房來繼續對外提供服務。 

摘要

Apache Pulsar 內置了多集群跨地域復制的功能，GEO-Repliaaction 是指把分散在不同物理地域的集群通過一定的配置方式讓其能在集群之間進行數據的相互復制。

根據消息是否為異步讀寫的維度，跨地域復制可以分為如下兩種方案：

• 同步模式：如果對數據的容災級別要求非常高，可以采用同步跨城部署模式，數據副本會存在不同城市之間，不足是跨城之間網絡的波動會對性能有較大的影響，因為需要等待多個城市都寫成功才會返回客戶端成功。

• 異步模式：如果對數據的容災級別不是那么高，可以采用異步跨城部署模式，例如有兩個獨立的數據中心上海和多倫多，寫入上海的消息會異步再寫一份到多倫多，優點不影響主流程性能，不足多一份存儲開銷。

下面我們討論的是異步模式下，pulsar 的跨地域復制方案。

Pulsar 目前支持以下三種異步跨地域復制的方案：

• 全連通      
  
• 單向復制      
  
• Failover 模式      
  

從是否具有 configurationStoreServers （global zookeeper）的角度可以分為以下兩種異步跨地域復制方案：

• 全連通

2. 沒有 configurationStoreServers

• 單向復制      
  

• Failover 模式

在整個跨地域復制中的一個核心理念在于，各個集群之間的數據是否能夠互通，它們之間的交互主要依靠如下配置信息：

• cluster （cluster name）
• zookeeper （local cluster zk servers）
• configuration-store （global zk servers）
• web-service-url
• web-service-url-tls
• broker-service-url
• broker-service-url-tls

在初始化 pulsar cluster 時，用戶可以指定上述對應的信息，示例如下：

Full-mesh(全連通)

Full-mesh 的形式允許數據在多個集群中共享，如下圖：

概念解析

• configurationStoreServers: 存儲的是各個集群的配置信息，也就是讓集群之間能夠互相感知到對方的地址信息。除此之外還會存儲 tenant 和 namespace 的信息，主要目的在于簡化操作流程，當更新其中一個集群的信息，其它集群都可以通過 global zookeeper 獲取到這次信息的更改。
• tenant: 當前創建的 tenant 允許哪些集群進行操作（–allowed-clusters）

• namespace: 當前創建的 namespace 允許在哪幾個集群之間進行數據的復制 （–clusters）

原理

對于多個集群之間的數據復制，我們均可以簡化到兩個集群之間的數據復制，基于這個理念，Geo-Replication 的原理如下圖所示：

當前擁有兩個集群，分別部署在北京和上海，當用戶在北京的集群中使用 producer 發送數據時，首先會發送到北京機房的本地集群中（topic1）與此同時會去創建一個 replication cursor，用于專門復制數據的一個游標，通過這個 cursor 信息，你可以判斷當前數據究竟復制到哪一個階段。同時會去創建 replication producer，它會把數據從北京機房的 topic1 中讀取數據，然后將數據寫到上海機房的 topic1 中，上海機房的 broker 收到 producer 的請求之后，會寫到本地相同的 topic 中來（topic1）。此時如果上海機房的用戶開啟 consumer 去消費數據的話，會接收到由北京機房 producer 生產的數據信息。反之亦然。

在這里需要說明如下問題：

• 在全連通的場景下，北京機房的數據會復制給上海機房的集群，上海機房的數據也會復制給北京的機房，那么是否會出現北京機房的數據復制給上海機房之后，上海機房反向再把該條數據復制回到北京，形成數據的死循環？因為當 producer 在發送消息時，它是知道自己當前所在的集群是屬于哪一個的，當生產的消息經過 replication producer 的復制時，會在該消息標記一個 label：replication_from，代表這條消息從哪里來，可以解決反向復制的問題。
• 在 Geo-Replication 的場景下，同樣可以保證消息的 exactly-once 的語義（at-least-once + broker 端的去重（producer-name + sequence ID））

• 復制的延遲取決于兩個機房之間網絡的時延，如果時延比較大，需要考慮兩個機房之間的網絡情況。

一旦配置了 global zookeeper 之后，數據之間的復制都是雙向復制的，所有 global zookeeper 下面掛載的集群之間的數據都是互通的。

單向復制

上面我們提到，在配置了 global zookeeper 的情況下，是沒有辦法做數據的單向復制的，但是很多場景下，我們并不需要所有的集群之間的數據都是全連通的，這種場景下，我們就可以考慮使用單向復制的功能，需要強調的是，單向復制并不需要用戶單獨配置或指定 configurationStoreServers，配置時只需要將 configurationStoreServers 的值配置為本地集群的 zookeeper 地址（zookeeperServers）即可。

那么在不配置 global zookeeper 的情況下，如何去做跨集群復制的場景呢？

在上面我們提到，global zookeeper 的作用主要是用來存儲多個集群的地址信息以及相應的 namespace 信息，并沒有額外的元數據信息。所以在單向復制的場景下，你需要告訴其它機房的集群，你需要讀到不同集群之間的 namespace 信息。

Failover 模式

Failover 模式是單向復制的特例。

Failover 模式下，遠端機房的集群只是用來做數據的備份，并不會有 producer 和 consumer 的存在，只有當當前處于 active 的集群宕機之后，才會把對應的 producer 和 consumer 切換到對應的 standby 集群中來繼續消費。因為有 replication sub 的存在，所以會一同將訂閱的狀態也復制到備份機房。

目前 pulsar Geo-Replication 

存在的問題

• Pulsar 只能保證單機房生產的消息順序，在多機房的場景下沒辦法保證多個機房的消息全局有序
• 由于 cursor snapshot 是定期進行的，在時間上精確度不會太高，多少有些偏差。
• 目前只會同步 “Mark delete position” 的位置，對于單獨簽收的消息暫時無法同步。
• 只有在所有相關集群都處于「可用」狀態時，才可以進行 cursor snapshot。

• 當使用 cursor snapshot 后，會產生一些緩存，影響到后續涉及 backlog 的計算結果。