需求意義

在 Geo-Replication 的設(shè)計支撐下，其一，我們可以比較容易的將服務(wù)分散到多個機(jī)房；其二，可以應(yīng)對機(jī)房級別的故障，即在一個機(jī)房不可用的情況下，服務(wù)可以轉(zhuǎn)接到其它的機(jī)房來繼續(xù)對外提供服務(wù)。 

摘要

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

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

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

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

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

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

• 全連通      
  
• 單向復(fù)制      
  
• Failover 模式      
  

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

• 全連通

2. 沒有 configurationStoreServers

• 單向復(fù)制      
  

• Failover 模式

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

• 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 時，用戶可以指定上述對應(yīng)的信息，示例如下：

Full-mesh(全連通)

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

概念解析

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

• namespace:當(dāng)前創(chuàng)建的 namespace 允許在哪幾個集群之間進(jìn)行數(shù)據(jù)的復(fù)制 （–clusters）

原理

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

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

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

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

• 復(fù)制的延遲取決于兩個機(jī)房之間網(wǎng)絡(luò)的時延，如果時延比較大，需要考慮兩個機(jī)房之間的網(wǎng)絡(luò)情況。

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

單向復(fù)制

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

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

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

Failover 模式

Failover 模式是單向復(fù)制的特例。

Failover 模式下，遠(yuǎn)端機(jī)房的集群只是用來做數(shù)據(jù)的備份，并不會有 producer 和 consumer 的存在，只有當(dāng)當(dāng)前處于 active 的集群宕機(jī)之后，才會把對應(yīng)的 producer 和 consumer 切換到對應(yīng)的 standby 集群中來繼續(xù)消費(fèi)。因為有 replication sub 的存在，所以會一同將訂閱的狀態(tài)也復(fù)制到備份機(jī)房。

目前 pulsar Geo-Replication 

存在的問題

• Pulsar 只能保證單機(jī)房生產(chǎn)的消息順序，在多機(jī)房的場景下沒辦法保證多個機(jī)房的消息全局有序
• 由于 cursor snapshot 是定期進(jìn)行的，在時間上精確度不會太高，多少有些偏差。
• 目前只會同步 “Mark delete position” 的位置，對于單獨(dú)簽收的消息暫時無法同步。
• 只有在所有相關(guān)集群都處于「可用」?fàn)顟B(tài)時，才可以進(jìn)行 cursor snapshot。

• 當(dāng)使用 cursor snapshot 后，會產(chǎn)生一些緩存，影響到后續(xù)涉及 backlog 的計算結(jié)果。