关于apache:博文推荐-Apache-Pulsar-三大跨地域复制解决方案

9次阅读

共计 3515 个字符，预计需要花费 9 分钟才能阅读完成。

编者荐语：

原文作者冉小龙，首发于公众号“腾讯云中间件”，公布已取得原帐号受权。如需转载，请返回联系。本文次要为大家介绍 Apache Pulsar 在不同场景下的跨地区复制解决方案。

以下文章来源于腾讯云中间件，作者冉小龙

对于 Apache Pulsar
Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。
GitHub 地址：http://github.com/apache/pulsar/

Apache Pulsar 是一个多租户、高性能的服务间音讯传输解决方案，反对多租户、低延时、读写拆散、跨地区复制、疾速扩容、灵便容错等个性。其原生反对了跨洲际级别的跨地区复制的解决方案，并联合其本身的 tenant 和 namespace 级别的形象，能够灵便的反对不多品种，不同场景下的跨地区复制解决方案。

在 Geo-Replication 的设计撑持下，其一，咱们能够比拟容易的将服务扩散到多个机房；其二，能够应答机房级别的故障，即在一个机房不可用的状况下，服务能够转接到其它的机房来持续对外提供服务。

Apache Pulsar 内置了多集群跨地区复制的性能，GEO-Repliaaction 是指把扩散在不同物理地区的集群通过肯定的配置形式让其能在集群之间进行数据的互相复制。

依据音讯是否为异步读写的维度，跨地区复制能够分为如下两种计划：

同步模式：如果对数据的容灾级别要求十分高，能够采纳同步跨城部署模式，数据正本会存在不同城市之间，有余是跨城之间网络的稳定会对性能有较大的影响，因为须要期待多个城市都写胜利才会返回客户端胜利。
异步模式：如果对数据的容灾级别不是那么高，能够采纳异步跨城部署模式，例如有两个独立的数据中心上海和多伦多，写入上海的音讯会异步再写一份到多伦多，长处不影响主流程性能，有余多一份存储开销。

上面咱们探讨的是异步模式下，Pulsar 的跨地区复制计划。

Pulsar 目前反对以下三种异步跨地区复制的计划：

全连通
单向复制
Failover 模式

从是否具备 configurationStoreServers（global zookeeper）的角度能够分为以下两种异步跨地区复制计划：

有 configurationStoreServers

全连通

没有 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 时，用户能够指定上述对应的信息，示例如下：

bin/pulsar initialize-cluster-metadata \
  --cluster pulsar-cluster-1 \
  --zookeeper zk1.us-west.example.com:2181 \
  --configuration-store zk1.us-west.example.com:2181 \
  --web-service-url http://pulsar.us-west.example.com:8080 \
  --web-service-url-tls https://pulsar.us-west.example.com:8443 \
  --broker-service-url pulsar://pulsar.us-west.example.com:6650 \
  --broker-service-url-tls pulsar+ssl://pulsar.us-west.example.com:6651

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 模式下，远端机房的集群只是用来做数据的备份，并不会有 producer 和 consumer 的存在，只有当以后处于 active 的集群宕机之后，才会把对应的 producer 和 consumer 切换到对应的 standby 集群中来持续生产。因为有 replication sub 的存在，所以会一起将订阅的状态也复制到备份机房。