Apache Pulsar 跨地域复制方案选型实践

本文主要介绍了 Apache Pulsar 跨地域复制方案选型相关实践，作者为中国移动云能力中心大数据团队软件开发工程师刘静。

Apache Pulsar 是集消息、存储、轻量化函数式计算为一体的云原生分布式消息流平台，采用计算存储分离的云原生架构可轻松实现动态扩缩容，其原生支持多租户、多 Namespace 级别的抽象，且在设计之初就考虑了多个机房的跨地域复制需求，具有跨地域多机房数据复制和互备特性，可满足多种场景多层次下的跨域复制。

跨地域复制

Pulsar 天然支持跨地域复制特性，根据消息是否为异步读写可分为同步复制方案和异步复制方案，用户可根据具体业务需求选用。

异步复制

内置的异步多集群跨地域复制功能，通过 Geo-replication 机制将分布在不同地域的数据中心集群数据进行同步和互备。这种方案在一个数据中心集群发生故障完全不可用时，可通过转接到其他数据中心集群继续对外提供服务。

以 Region1 集群数据向 Region2 集群复制为例，分析 Geo-replication 复制流程：

1.当 Produce 向 Region1 集群 Topic 写数据时，本地机房会把消息持久化到 BookKeeper 中，同时会创建一个 Replicator （Replicator 包含 Replication Cursor 和 Replication Producer，Cursor 是记录当前数据被复制到哪个阶段的游标）；2.Replication Producer 会把 Region1 的 Topic 数据发送到 Region2 的远程集群的 Topic 中；3.Region2 远程集群收到 Replication Producer 请求后，会将数据写入 Region2 的 Topic 中；4.远程集群 Region2 数据写成功后会给 Region1 集群的 Cursor 返回一个 ACK；5.Region1 集群收到 ACK 应答后会通过 Replication Producer 继续发送下一条消息；6.至此，Region2 的 consumer 就可以消费到 Region1 集群 producer 生产的数据信息，反之亦然。

根据各数据中心集群间数据是否能互通，可将 Pulsar 异步复制分为全连通，单向及 Failover 模式：

•全连通：该模式下 Topic 看起来像是一个全局 Topic，生产者向任一集群中的 Topic 发送消息时，其他集群都可以从各自集群的 Topic 中消费到数据。需要建立连接的各集群可通过配置相同的 configurationStoreServer 参数可共享一个全局 Zookeeper，多个跨地域集群通过这个全局 Zookeeper 互相感知，当某一集群更改时，其他集群也会收到消息。•单向模式：设置数据从 Cluster1 集群复制到 Cluster2，生产者发送到 Cluster1 中 Topic 的消息会自动同步到 Cluster2 中 Topic。但当生产者发送消息到 Cluster2 集群 Topic 时，消息不会同步到 Cluster1 中 Topic。•Failover 模式：单向复制的一种特例，远端机房作数据备份适用，不存在生产者和消费者，只有当前集群宕机后，才会把对应的生产者和消费者切换到远端集群继续使用。

同步复制

相比于异步方案，同步复制提供的是一种强一致的复制方案，该方案中单个 Pulsar 集群分布在多个数据中心，数据落盘时它会限制每条消息必须要跨机房/地域写入成功才算成功，可确保不同数据中心间数据的一致性，同步复制可以通过 BookKeeper Client 的跨机架/跨区域感知能力配合 broker.conf 中的一些参数设置来实现。

方案对比总结

跨域方案选型实践及落地方案设计

选型实践

在两区域各选几台物理机搭建环境对比分析同步及异步复制方案性能，所选跨区域节点间测得 ping 网络延迟为 1.5ms，在双区域均可用场景及一个区域故障，仅单区域可用场景下进行实验，结果如下：

•同步复制，双区域可用

•同步复制，一个区域故障，仅单区域可用

•异步复制，一区域作为主集群生产消费消息，生产的消息会被异步复制到另一区域

验证结果分析总结：

1.延迟时间：同步方案时延略高于异步方案，在测试的几组场景中，由于跨区域节点间本身网络延迟很小，同步方案所测端到端平均延迟较异步方案高几毫秒，在可接受范围内；2.数据一致性：同步方案较异步方案拥有更明显的优势，在单 Region 整体不可用情况下，更能保证数据的可用性，基本不会出现数据不一致或数据丢失情况；3.资源成本占用：异步方案会多一份存储开销，同步方案更具优势。结论：选用同步方案在本实践场景下完成跨域复制较为合适

方案设计

1.共享 Zookeeper 集群采用三区域部署方案（Region1:2 + Region2:2+ Region3:1），任一区域故障，另外两个区域都能保证集群正常可用。2.共享 Bookkeeper 集群由若干分布在不同区域的 Bookie 节点组成，将跨区域数据的多份副本分别存储到不同区域的节点上。3.Pulsar 实例分单区域和跨区域两类，多个 Pulsar 实例共享一套跨多区域的 Zookeeper 和 Bookkeeper 集群。跨区域实例的 Broker 集群分散在不同区域机房，各区域地位均等，协同对外提供服务，当某区域节点整体不可用时，其他区域上的 Broker 仍能正常对外提供服务。

开源 Pulsar Broker 默认采用随机读写策略，本方案实施过程中在 Broker 读写策略上进行了优化，具体改动点如下：

•给每个 Broker 和 Bookie 节点打上标签，标识节点所属区域。•跨区域 Pulsar 实例，当 Broker 选择存储双副本的 Bookie 节点集合时，需保证集合中包含来自不同区域的节点，Broker 读取数据时优先从本区域的 Bookie 节点读取。•单区域 Pulsar 实例，当 Broker 选择存储双副本的 Bookie 节点集合时，只选择和 Broker 处于同一区域的 Bookie 节点，读取数据时也有本区域的 Bookie 节点获取。

总结

较传统消息队列，Pulsar 功能更为丰富，可以应对很多传统消息队列无法应对的复杂场景，其天然适配云原生环境，支持动态扩缩容，多协议扩展（如 KOP，ROP，AOP 等多种插件可通过对接同一套底层 Pulsar 集群进行各类客户端的接入，极大降低了中间件管理运维成本），且内置跨地域复制等多种特性，现已成为云原生时代消息中间件的首选。

本文主要针对 Pulsar 的跨域复制特性进行了介绍，分析异步复制及同步复制方案的架构，优缺点及适用场景，并结合实际环境进行跨域复制方案选型实践和落地方案设计，希望可以帮助读者了解 Pulsar 跨地域复制特性以及如何结合具体实际进行方案选型。