CN111400065A - 一种分离全局zookeeper的pulsar消息异地多活方法及*** - Google Patents

Abstract

本发明提供一种分离全局zookeeper的pulsar消息异地多活方法和***，包括N个分离全局zookeeper的pulsar集群，其中每一分离全局zookeeper的pulsar集群都包括：至少一个本地zookeeper子集群，至少一个全局zookeeper子集群；其中N个分离的全局zookeeper集群的所有全局zookeeper子集群都相互连接；其中每一分离全局zookeeper的pulsar集群都分别创建相同名称的主题topic，以使所述每一个pulsar集群中的broker可以与其他pulsar集群的broker进行通信。

Description

一种分离全局zookeeper的pulsar消息异地多活方法及***

技术领域

本发明实施例涉及数据处理技术领域，尤其是一种消息队列的异地多活技术，特别涉及一种分离全局zookeeper的pulsar消息异地多活方法及***。

背景技术

消息队列的异地多活是防灾备份领域非常重要的一项技术，为了实现业务在灾难性故障的情况不受影响，就必须实现有效的消息队列的异地多活。现有的消息队列的异地多活技术，主要是基于MirrorMarker的kafka跨集群同步技术。

Kafka是一个由linkedin开源的，高性能的分布式流平台，主要用于发布和订阅流数据、以容错的方式持久化流数据、处理流数据。对于每个topic，kafka都会维护一个分区日志，每个分区都是有序的，不变的消息序列，这些消息被附加到结构化的提交日志中。每个分区中的消息都有一个称为offset唯一的Id，用于唯一的标识分区中的每条消息。Kafka集群使用可配置的保留期限持久地保留已发布的消息，例如，如果将保留策略设置为两天，则在发布记录后的两天内，该记录可供使用，之后将被丢弃以释放空间。Kafka的性能相对于数据大小实际上是恒定的，因此长时间存储数据不是问题。

在Kafka集群中，producer负责往提交日志追加记录，broker负责各个topic的各个partition之间的副本复制，consumer负责从特定的offset处开始读取记录并转换成消息，通过移动offset来实现顺序消费的功能。

在Kafka集群中，每个分区都有一个充当“领导者”的服务器和零个或多个充当“跟随者”的服务器。领导者处理对分区的所有读写请求，而跟随者则被动地复制领导者。如果领导者失败，则跟随者之一将自动成为新领导者。每个服务器充当其某些分区的领导者，而充当其他分区的跟随者，因此群集中的负载得到了很好的平衡。

MirrorMarker是Kafka官方提供的集群间复制工具，通过消费源cluster到目标cluster的方式来实现在另一个集群的镜像功能。可以同时启动多个mirror程序来增加复制的吞吐和提高容错的能力。MirrorMarker技术的底层实现原理是订阅一个kafka集群的topic消息，并发布到另一个kafka集群的topic中。进行复制的两个topic相互独立，除了需要相同的topic名称之外，其他的配置可以完全不同，包括partition和replicator等。由于MirrorMarker技术是基于topic级别的，通常需要指定whitelist，即白名单，可以是简单的topic名称，也可以是使用正则表达式的一组topic。同时由于目标kafka集群中不一定存在其中的某些topic，可以设置auto.create.topics.enable＝true来实现在目标kafka集群自动创建topic的功能，特别是在使用正则表达式进行复制的场景。

MirrorMarker的不足之处在于：MirrorMarker技术只是提供了基于配置的生产者消费者工具，能实现消息在集群间传递，此方式存在诸多的缺陷，主要包括以下几个方面：

单点故障：mirrormarker自身是一个单进程，一旦进程由于资源受限或者网络原因无法进行消息传递，消息将出现阻塞甚至中断同步。即使可以部署多进程，但是多个进程间的负载均衡和维护也是非常的困难，成本非常的高。

单向复制：mirrormarker只能从source cluster复制到target cluster，单向复制数据只适合主备场景，在双活场景无法适用。

双配置：mirrormarker需要同时配置source cluster的consumer和targetcluster的producer，双配置维护和变更成本也比较高。

Topic级别：无整体集群级别的同步策略，只能通过正则表达式来实现，新增topic往往难以确定是否会进行同步。

延迟大：mirrormarker采用consumer方式消费source cluster，消息序列化到日志文件之后才开始进行消费，再通过网络传输到target cluster上被序列化到日志文件之后被最终消费，延迟往往很大且不可控。

发明内容

针对现有技术中的消息队列异地多活技术存在的缺陷，本发明实施例提出了一种分离全局zookeeper的pulsar消息异地多活方法及***。

为了解决上述问题，本发明实施例提出了一种分离全局zookeeper的pulsar消息异地多活***，包括N个分离全局zookeeper的pulsar集群，其中所述每一分离全局zookeeper的pulsar集群都包括：至少一个本地zookeeper子集群，至少一个全局zookeeper子集群；

其中所述N个分离的全局zookeeper集群的所有全局zookeeper子集群都相互连接；

其中所述每一分离全局zookeeper的pulsar集群都分别创建相同名称的主题topic，以使所述每一个pulsar集群中的broker可以与其他pulsar集群的broker进行通信；

在一些实施例中，还包括控制端，所述控制端连接所述每一分离的全局zookeeper集群；其中所述控制端用于执行以下的至少一种操作：

Pulsar集群机器维护；

Pulsar端口号健康检测；

Pulsar多集群tenent、namespace统一创建、更新、删除功能；

Pulsar多集群topic统一查询、创建、删除功能；

Pulsar多集群consumer、subscription统一删除功能；

Pulsar多集群load report统一查询功能。

在一些实施例中，当网络不可用的情况下，所述N个分离全局zookeeper的pulsar集群分别针对其各自的topic进行数据传输；在网络可用后，将N个分离全局zookeeper的pulsar集群各自的topic消息通过geo-replication同步到其他的pulsar集群。

在一些实施例中，其中所述全局zookeeper子集群是进行异地备份geo-replication的元数据存储***。

在一些实施例中，本地zookeeper子集群采用2181端口，且所述全局zookeeper子集群采用2184端口；其中所述每一分离的全局zookeeper集群中过的本地zookeeper子集群的节点数为不小于3的奇数，所述全局zookeeper子集群包括不少于5个节点。

同时，本发明实施例还提出了一种利用如前任一项所述的分离全局zookeeper的pulsar消息异地多活***的数据处理方法，包括：

对每一个分离的全局zookeeper集群分别进行初始化，即针对每一个分离的全局zookeeper集群都执行initialize-cluster-metadata，总共N次；

对每一个分离的全局zookeeper集群中分别执行clusters create，以在该集群中建立全局zookeeper子集群；

对每一于分离的全局zookeeper集群，分别创建相同过的规则tenent以及命名namespace；总共N次；包括：

创建tenent：bin/pulsar-admin tenants create CDC-c Cluster1,Cluster2,...,ClusterN

创建namespace：bin/pulsar-admin namespaces create CDC/ns-c Cluster1,Cluster2,...,ClusterN

针对每一个分离的全局zookeeper集群，分别创建相同的topic。

本发明的上述技术方案的有益效果如下：上述技术方案提出了一种分离全局zookeeper的pulsar集群实现消息异地多活方法及***，能够在拥有全局zookeeper集群的特性之外，还能够避免了全局zookeeper存在的消息丢失的风险。

附图说明

图1为相关技术中的在pulsar的架构图；

图2为相关技术中的全局zookeeper的pulsar异地多活技术；

图3为本发明实施例的分离全局zookeeper的pulsar异地多活技术。

具体实施方式

为使本发明要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。

以下首先对本申请中涉及的各种名词进行解释：

Record：记录，用来描述一个事实或者状态的信息载体的基本单元。

Log：日志，用来记录数据或者数据变更的记录。

Message：消息，用于在机器之间进行数据传递的基本单元。

Stream：流，将一条或者多条消息以时间维度组织在一起的消息组合。

Publish：发布，将消息发送出去的或者存储起来的过程。

Subscribe：订阅，将消息从消息存储***顺序接收到的过程。

Topic：主题，消息以主题的形式进行逻辑和物理的隔离，使消息处理更简单。

Producer：生产者，将消息发布到特定的一个主题或者一组主题的应用程序。

Consumer：消费者，将一个主题或多个特定的主题按顺序接收用于处理的应用程序。

Zookeeper：一个分布式的，分布式应用程序协调一致性的服务。

Partition：分区，将topic划分成不同的存储和处理单元，提高消息吞吐和性能，一个topic可以由一个或多个partition组成。

Replicator：副本，对topic或者partition进行冗余的存储单元，增加数据的冗余度，也可以提高消费者的性能，一个partition也可以由一个或多个replicator组成。

Leader：领导者，副本通过复制的技术进行同步，用于与生产者和消费者进行交互的副本，称为leader,一个分片通常只有一个leader。

Follower：跟随者，不与生产者和消费者直接交互的，且只用于提高冗余度的副本,在leader发生故障或者从集群中失联时，会从follower中选择一个副本成为leader，这个过程称为leader选举。

Broker：消息的服务端，通常指topic的服务端，可持久化消息的服务程序。

Cluster：集群，由一个或者多个broker组成的服务端，一个集群可以支持多个broker，也可以支持多个topic，并将多个topic的分区和副本在不同的broker中进行负载均衡和复制同步。

相关技术中有一种全局zookeeper的pulsar异地多活技术。Pulsar是一项yohoo开源技术，用于服务器到服务器进行消息传递的多租户高性能解决方案。与kakfa类似，pulsar也提供producer和consumer的支持，也支持消息的持久化。与kafka不同的地方，pulsar能提供更低的端到端的延迟，同时支持跨集群的无缝的地理复制特性。Pulsar集群中，对消息提供了额外的offload功能，可以将消息保留到第三方存储引擎中，包括hdfs、aws等。更重要的是，pulsar提供了比kafka更可靠的序列化保证，pulsar支持消息的flush机制，消息持久到存储硬件而非文件***。

相关技术中有一种全局zookeeper的pulsar异地多活技术的原理如图1所示的，在pulsar的架构图中有一个称为Global replicators的内部组件和一个称为Global ZK的外部组件，一起组成了一个pulsar cluster。基于全局zookeeper技术，pulsar可以无缝的实现geo replication。Pulsar的broker与kafka不同，是一个无状态的代理。broker中的Global replicators专门用于进行geo replication，当producer向broker发布消息时，broker同时从Global zookeeper中获取需要进行replicator的多个目标cluster，将消息写入到其他目标cluster,完成消息的跨集群同步。

图1中，每当P1，P2和P3生产者将消息分别发布到Cluster-A，Cluster-B和Cluster-C群集上的T1主题时，这些消息就会立即在群集之间复制。复制后，C1和C2使用者可以使用其各自群集中的消息。如果没有地理复制，则C1和C2使用者将无法使用P3产生者发布的消息。

与kafka的MirrorMarker对比，不难发现geo replication存在很多的优势，比如：

Broker自有特性：kafka broker只负责本地集群的消息，而pulsar的broker自带geo replication，集群已提供集群间复制功能。

无单点故障：由于broker实例是分布式的，geo replication依附于broker也是分布式的，不存在单点故障缺陷，一旦某个broker实例宕机也会发生故障转移，保证高可用。

相互复制：kafka的MirrorMarker只能单一的从source cluster复制到targetcluster，而pulsar的geo replication可以支持两个甚至更多的集群间的相互复制，无缝支持异地多活。

全局zookeeper配置：kafka的MirrorMarker需要配置两个集群，而pulsar的georeplication的多个cluster之间只需要一个额外的全局zookeeper配置即可，更易于统一维护。

Cluster级别：与kafka的MirrorMarker基于topic复制不同，pulsar的georeplicattion基于cluster进行同步。

延迟小：pulsar内部的Global replicators在producer发布消息之后，立即就可以复用内存队列中的高速缓存数据，将消息发布到其他的cluster，无需进行磁盘文件的读取，延迟更小。

虽然geo replication技术可以解决很多kafkaMirrorMarker存在的缺陷，但是geo replication基于全局zookeeper的实现，自身也会存在诸多的不足之处，主要包括如下几点：

部署成本：全局zookeeper需要跨所有的cluster进行部署，扩容和变更成本较高。

状态维护：全局zookeeper集群，网络往往是不可靠的，跨数据中心的网络更不可靠，一旦发生网络故障，集群的状态非常的复杂，处理也非常困难。

低性能：全局zookeeper集群，由于写数据都需要跨数据中心保证集群一致性，会产生很大的性能波动，延迟也可能会产生指数级的放大，对于pulsar集群本身的性能损耗也是极大的，带来很大的风险。

网络中断：一旦发生网络中断，部分集群不但无法进行geo replication，甚至由于本地的全局bookeeper故障导致puslar集群故障，无法进行消息的发布订阅。

难以恢复：一旦全局zookeeper发生了网络故障，产生了网络分区，发生故障的本地pulsar集群和全局zookeeper集群将很难恢复到可使用的状态，如果发生全局的网络分局，所有集群都将不可用，直到网络分区问题消失。

由于相关技术中的全局zookeeper自身存在的问题，导致pulsar的异地多活技术在生产环境中存在很大的不稳定性和风险性，本发明针对性的对全局zookeeper进行分离，以避免全局zookeeper存在的各种各样的不可靠风险点，使pulsar的异地多活技术更加的稳定，降低风险，使其在生产环境中可以正式投入应用。

Pulsar提供的geo replication基于全局zookeeper进行设计，为了克服全局zookeeper带来的诸多问题，本发明采用分离全局zookeeper的技术方案来实现全局zookeeper的功能，为了更好的理解分离全局zookeeper的技术方案，本发明仅仅从跨两个pulsar集群的geo replication场景进行技术原理分析和技术方案阐述。

图2为举例说明的全局zookeeper部署的架构图；如图2所示的全局zookeeper部署架构中包括两个集群：Cluster A和Cluster B；当然本发明实施例中并未限定集群的具体数字。如图2所示的，Cluster A中的全局zookeeper有三个node实例，分别是zk1.A:2184、zk2.A:2184、zk3.A:2184。Cluster B中全局zookeeper有两个node实例，分别是zk1.B:2184、zk3.B:2184。

从图2所示的例子中可以看出，两个集群Cluster A和Cluster B的全局zookeeper是不均衡的，其中全局zookeeper需要至少(n+1)/2＝3个node实例才能提供服务。其中Cluster A在于Cluster B进行网络分区之后的表现也会不同，Cluster A仍然存活3个node实例可以进行正常的消息处理，而Cluster B由于只有zk1.B:2184、zk3.B:2184两个node实例无法满足提供服务的条件，Cluster B中的broker无法连接global zookeeper。

在pulsar中，每一个topic需要对应一个broker进行托管，topic对应的broker成为该topic的ownership，pulsar的client(包括producer和consumer)与pulsar集群进行交互时必须满足以下条件：

指定topic，默认全局topic；

通过topic的lookup接口定位到该topic的ownership，ownership关系存储在全局zookeeper中；

client与该topic的ownership进行消息的send和receive操作。

Global zookeeper是进行geo replication的元数据存储***，一旦globalzookeeper无法连接，Client的api将无法从broker实例查找到topic的ownership。也就导致无法进行客户端消息的发布和订阅，集群处于不可用状态。

在如图2所示的全局zookeeper的部署架构图中，Pulsar的zookeeper部署架构中，2181端口表示本地zookeeper集群，2184端口表示全局集群，所有的zookeeper集群必须保证节点数为奇数且至少三个节点，全局zookeeper集群至少5个节点。Pulsar集群禁用自动创建topic，生产环境往往不会开启，避免造成元数据污染。

其中每一个topic只需要在其中一个集群(例如图2中的ClusterA和Cluster B)中被创建一次，且该topic存储于该集群中的全局zookeeper子集群中。具体的topic可以由一个集群中的任意一个本地zookeeper子集群创建。当Producer发布消息之后，消息先写到存储在本地任一个子集群内的topic中，然后将该消息的全局副本global replicator通过全局zookeeper子集群同步到其他集群中；当两个集群之间的网络连接可用，则创建topic的集群将全局部分除非异地集群与创建topic的集群可连接之后，由global replicator通过全局zookeeper子集群同步到第二集群；且该第二集群通过副本任务replicator task创建对应的topic，则该第二集群可以在其所包括的子集群直接发送send和接收receiver该topic。

如图3所示的为本发明实施例中举例说明的分离全局zookeeper的集群技术的架构图。

在本发明实施例中，分离的全局zookeeper的Pulsar消息队列异地多活***的架构中，2181端口表示本地zookeeper子集群，2184端口表示全局zookeeper子集群，所有的本地zookeeper子集群必须保证节点数为奇数且至少三个节点，全局zookeeper子集群必须保证不少于5个节点。Pulsar集群禁用自动创建topic，生产环境往往不会开启，避免造成元数据污染。如图3所示的，本发明实施例示例性的列出了一种分离全局zookeeper的Pulsar消息队列异地多活架构，其示例性的包括了两个集群：Cluster A和Cluster B。如图3所示的，每个集群中都包括至少一个具有2181端口的本地子集群：本地zookeeper子集群，还包括至少一个具有2184端口的全局zookeeper子集群：global zookeeper子集群。其中，所述每一集群Cluster A和Cluster B中

如图3所示的，ClusterA和Cluster B之间已经不具有全局zookeeper功能。如图3所示的，每个集群包括至少一个基于2181端口的本地zookeeper子集群，还至少包括一个基于2184端口的全局zookeeper子集群；其中每一集群(例如图3中的ClusterA和Cluster B)的全局zookeeper子集群之间相互导通以进行数据传输；还包括一个控制端admin，该控制端admin的接口与图2所示的全局zookeeper的部署架构相似的是，该控制端admin可以与每一集群(例如图3中的ClusterA和Cluster B)进行通讯。

本发明实施例的分离的全局zookeeper集群，各自通过其本地zookeeper子集群建立相同的topic，且该topic的元数据被传输到该集群中的全局zookeeper子集群中。这样即使在集群之间的网络不可用时，每个集群都可以对该topic各自进行发送send和接收receive。

在本发明实施例中，部署基于分离全局zookeeper的pulsar异地多活技术方案时，假设有N个集群需要进行异地多活(N≥2)，则本发明实施例的方法包括：

在本地部署分离的全局zookeeper集群，其中每一个分离的全局zookeeper集群包括N个子集群，其中每一个分离的全局zookeeper集群都包括至少一个基于2181端口的本地zookeeper子集群以及至少一个基于2184端口的全局zookeeper子集群；且所述N个分离的全局zookeeper集群的全局zookeeper子集群之间可以独立访问；

1.对每一个分离的全局zookeeper集群分别进行初始化，即针对每一个分离的全局zookeeper集群都执行initialize-cluster-metadata，总共N次；initialize-cluster-metadata为集群初始化步骤，其为已有技术，在此不再赘述；

2.对每一个分离的全局zookeeper集群中分别执行clusters create，以在该集群中建立基于2184端口的全局zookeeper子集群，其中每一个分离的全局zookeeper集群都执行N+1次，总计N*(N+1)次；

3.对每一于分离的全局zookeeper集群，分别创建相同的tenent以及命名namespace；总共N次；包括：

创建tenent：bin/pulsar-admin tenants create CDC-c Cluster1,Cluster2,...,ClusterN

创建namespace：bin/pulsar-admin namespaces create CDC/ns-c Cluster1,Cluster2,...,ClusterN

4.针对每一个分离的全局zookeeper集群，分别建立相同的topic；每个分离的全局zookeeper集群都执行一次，总计N次。

可以发现其中存在多个集群的部署和topic创建成本比全局zookeeper的技术方案操作次数要多N到N*N步。为了消除这种复杂性成本，本发明专门针对性的开发了一套基于分离的zookeeper进行集群部署维护的pulsar多活管理***，该***基于pulsar的java客户端进行开发实现。

自定义的Pulsar多活管理***功能包括如下几点：

Pulsar集群机器维护

Pulsar端口号健康检测

Pulsar多集群tenent、namespace统一创建、更新、删除功能

Pulsar多集群topic统一查询、创建、删除功能

Pulsar多集群consumer、subscription统一删除功能

Pulsar多集群load report统一查询功能

部署完成之后，在N个集群中任何一个集群send消息，都会通过globalreplicators点对点地复制到其他的cluster中，即便发生网络不可达故障，所有的N个集群都能正常运行，等到网络可达时消息会自动同步到其他需要同步的目标集群中，保证所有集群的持续稳定运行。

该技术方案能够在拥有全局zookeeper集群的特性之外，还避免了全局zookeeper存在的各种不稳定性，以及这些不稳定性所产生的生产事故，甚至是消息的丢失风险。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明所述原理的前提下，还可以作出若干改进和调整，这些改进和调整也应视为本发明的保护范围。

Claims (6)

1.一种分离全局zookeeper的pulsar消息异地多活***，其特征在于，包括N个分离的全局zookeeper集群其中所述每一分离的全局zookeeper集群都包括：至少一个本地zookeeper子集群，至少一个全局zookeeper子集群；

其中所述N个分离的全局zookeeper集群的所有全局zookeeper子集群都相互连接；

其中所述每一分离的全局zookeeper集群都分别建立相同的用于承载消息的主体topic，以使所述每一个pulsar集群中的broker可以与其他pulsar集群的broker进行通信。

2.根据权利要求1所述的分离全局zookeeper的pulsar消息异地多活***，其特征在于，还包括控制端，所述控制端连接所述每一分离的全局zookeeper集群；其中所述控制端用于执行以下的至少一种操作：

Pulsar集群机器维护；

Pulsar端口号健康检测；

Pulsar多集群tenent、namespace统一创建、更新、删除功能；

Pulsar多集群topic统一查询、创建、删除功能；

Pulsar多集群consumer、subscription统一删除功能；

Pulsar多集群load report统一查询功能。

3.根据权利要求1所述的分离全局zookeeper的pulsar消息异地多活***，其特征在于，当网络不可用的情况下，所述N个分离全局zookeeper的pulsar集群分别针对其各自的topic进行数据传输；在网络可用后，将N个分离全局zookeeper的pulsar集群各自的topic消息通过geo-replication同步到其他的pulsar集群。

4.根据权利要求1所述的分离全局zookeeper的pulsar消息异地多活***，其特征在于，其中所述全局zookeeper子集群是进行异地备份geo-replication的元数据存储***。

5.根据权利要求1所述的分离全局zookeeper的pulsar消息异地多活***，其特征在于，本地zookeeper子集群采用2181端口，且所述全局zookeeper子集群采用2184端口；其中所述每一分离的全局zookeeper集群中过的本地zookeeper子集群的节点数为不小于3的奇数，所述全局zookeeper子集群包括不少于5个节点。

6.一种权利要求1-5任一项所述的分离全局zookeeper的pulsar消息异地多活***的数据处理方法，其特征在于，包括：

对每一个分离的全局zookeeper集群分别进行初始化，即针对每一个分离的全局zookeeper集群都执行initialize-cluster-metadata，总共N次；

对每一个分离的全局zookeeper集群中分别执行clusters create，以在该集群中建立全局zookeeper子集群；

对每一于分离的全局zookeeper集群，分别创建相同过的规则tenent以及命名namespace；总共N次；包括：

创建tenent：bin/pulsar-admin tenants create CDC -c Cluster1,Cluster2,...,ClusterN

创建namespace：bin/pulsar-admin namespaces create CDC/ns -c Cluster1,Cluster2,...,ClusterN

针对每一个分离的全局zookeeper集群，分别建立相同的topic。

Images