博文推荐 | Apache Pulsar 三大跨地域复制解决方案

2021年11月25日 阅读数:9
这篇文章主要向大家介绍博文推荐 | Apache Pulsar 三大跨地域复制解决方案,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

编者荐语:git

原文做者冉小龙,首发于公众号“腾讯云中间件”,发布已得到原账号受权。如需转载,请前往联络。本文主要为你们介绍 Apache Pulsar 在不一样场景下的跨地域复制解决方案。github

如下文章来源于腾讯云中间件 ,做者冉小龙
关于 Apache Pulsar
Apache Pulsar 是 Apache 软件基金会顶级项目,是下一代云原生分布式消息流平台,集消息、存储、轻量化函数式计算为一体,采用计算与存储分离架构设计,支持多租户、持久化存储、多机房跨区域数据复制,具备强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。
GitHub 地址: http://github.com/apache/pulsar/

Apache Pulsar 是一个多租户、高性能的服务间消息传输解决方案,支持多租户、低延时、读写分离、跨地域复制、快速扩容、灵活容错等特性。其原生支持了跨洲际级别的跨地域复制的解决方案,并结合其自身的 tenant 和 namespace 级别的抽象,能够灵活的支持很少种类,不一样场景下的跨地域复制解决方案。web

需求意义

在 Geo-Replication 的设计支撑下,其一,咱们能够比较容易的将服务分散到多个机房;其二,能够应对机房级别的故障,即在一个机房不可用的状况下,服务能够转接到其它的机房来继续对外提供服务。apache

摘要

Apache Pulsar 内置了多集群跨地域复制的功能,GEO-Repliaaction 是指把分散在不一样物理地域的集群经过必定的配置方式让其能在集群之间进行数据的相互复制。segmentfault

根据消息是否为异步读写的维度,跨地域复制能够分为以下两种方案:网络

  • 同步模式:若是对数据的容灾级别要求很是高,能够采用同步跨城部署模式,数据副本会存在不一样城市之间,不足是跨城之间网络的波动会对性能有较大的影响,由于须要等待多个城市都写成功才会返回客户端成功。
  • 异步模式:若是对数据的容灾级别不是那么高,能够采用异步跨城部署模式,例若有两个独立的数据中心上海和多伦多,写入上海的消息会异步再写一份到多伦多,优势不影响主流程性能,不足多一份存储开销。

下面咱们讨论的是异步模式下,Pulsar 的跨地域复制方案。架构

Pulsar 目前支持如下三种异步跨地域复制的方案:异步

  • 全连通
  • 单向复制
  • Failover 模式

从是否具备 configurationStoreServers (global zookeeper)的角度能够分为如下两种异步跨地域复制方案:分布式

  1. 有 configurationStoreServers
  • 全连通
  1. 没有 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(全连通)

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 的存在,因此会一同将订阅的状态也复制到备份机房。

图片

相关阅读

点击 连接 ,获取 Apache Pulsar 硬核干货资料!