ApachePulsar中的地理复制2：模式和实践

在上一篇博文中，我概述了ApachePulsar中的地理复制功能。Apache Pulsar利用Apache BookKeeper提供的可扩展流存储，是一个消息传递系统，支持跨多个数据中心的同步地理复制（通过Apache BookKeeper）和异步地理复制（在Pulsar代理级别配置）。在这篇博文中，我将描述一些人们可以用来跨多个数据中心设置地理复制的模式。

异步地理复制只需30秒

首先，让我花30秒钟解释ApachePulsar中的异步地理复制是如何工作的。下面的图1演示了ApachePulsar中3个数据中心之间的全网格地理复制设置。

在该图中，每当生产者P1、P2和P3分别向集群A、集群B和集群C中的主题T1发布消息时，这些消息都会立即跨集群复制。一旦被复制，消费者C1和C2就可以从各自的集群中消费这些消息。

在Pulsar中，每个租户都可以进行地理复制。只有当租户可以访问两个群集时，才能在两个特定群集之间启用地理复制。这是在名称空间级别管理的，使您能够创建和配置名称空间，以便在租户可以访问的两个或多个已配置集群之间进行复制。在该命名空间中的任何主题上发布的任何消息都将被复制到指定集中的所有集群。

3个命令中的全网格地理复制

只需几个命令，我们就可以看到在ApachePulsar中启用地理复制是多么容易（与现有的消息传递系统相比，地理复制不需要额外的复制器或镜像生成器）。让我通过在脉冲星群之间建立全网格地理复制来解释这一点。

假设有3个数据中心：美国西部、欧盟中部和亚太地区澳大利亚。在开始之前，您需要在Pulsar（租户）中创建一个属性，并授予该租户访问所有三个数据中心的权限。

$ bin/pulsar-admin properties create my-property \
  --admin-roles my-admin-role \
  --allowed-clusters us-west,eu-central,apac-australia

复制是在命名空间级别配置的。让我们创建一个名为full mesh的命名空间：

$ bin/pulsar-admin namespaces create my-property/global/full-mesh

最初，名称空间不会分配给任何集群。可以使用set clusters命令将名称空间分配给一个集群或多个集群。让我们将这个名称空间分配给所有三个可用集群。

$ bin/pulsar-admin namespaces set-clusters my-property/global/full-mesh \
  --clusters us-west,eu-central,apac-australia

发出这三个命令后，您就可以在三个数据中心之间进行全网格地理复制了。现在，在任何数据中心生成的消息都将自动复制到其他两个数据中心以供使用。

如果您希望在将来更改复制设置，例如，如果您的公司正在建设第四个数据中心或停用现有的数据中心，您可以随时更改复制设置，而不会中断正在进行的通信。一旦配置更改应用到这些数据中心，所有集群中的复制通道都将立即设置或停止。下面的示例命令将第四个数据中心apac china添加到名称空间full mesh。

$ bin/pulsar-admin namespaces set-clusters my-property/global/full-mesh \
  --clusters us-west,eu-central,apac-australia,apac-china

每个消息的选择性复制

默认情况下，使用集群之间的完整网格复制设置完整网格命名空间，并将消息复制到为该命名空间配置的所有集群。但是，您可以通过在应用程序级别直接为消息指定复制列表来有选择地限制复制。然后，该消息将仅复制到复制列表中的子集。

下面的示例代码显示了一个使用Pulsar Java客户端仅向数据中心apac australia生成消息的示例。

List<String> restrictDatacenters = Lists.newArrayList("apac-australia");

Message message = MessageBuilder.create()
	…
	.setReplicationClusters(restrictDatacenters)
	.build();

producer.send(message);

地理复制模式

通过使用全网格复制并在发送消息时应用选择性复制信息，您可以非常灵活地在任意数量的数据中心之间构建任意类型的复制拓扑，只需几个命令。

除了全网格地理复制之外，您还可以使用其他一些复制模式。

主动复制

这是全网格地理复制的一种特殊情况，只有两个数据中心，其中生产者可以在任何数据中心运行以生成消息，消费者可以使用来自所有数据中心的所有消息。

主动备份复制

这是主动地理复制的一种特殊情况。生产者向活动数据中心生成消息，同时将消息复制到备用数据中心进行备份。当活动数据中心关闭时，备用数据中心将接管并成为活动数据中心。然后，您可以让生产者向备用数据中心（现在是活动数据中心）生成消息。

聚合复制

有时，出于聚合目的，您希望将多个前端数据中心的消息复制到一个中心数据中心。例如，假设您有3个前端数据中心—front1、front2、front3和一个聚合数据中心（称为聚合数据中心）。然后，您可以为front1数据中心使用的主题创建front1聚合命名空间，为front2数据中心使用的主题创建front2聚合命名空间，为front3创建front3聚合命名空间。最后，您可以将聚合数据中心分配给这些名称空间。

聚合与边缘计算

聚合模式通常在将物联网（IoT）消息从边缘复制到云时出现。脉冲星能够很容易地支持这一点。有效管理复制设置的灵活性和工具对于边缘计算的成功至关重要。因为您不必设置非常重的复制器或镜像器。

地理复制最佳做法

除了设置您自己的地理复制方案的一般说明外，我们还推荐以下几个最佳做法。

监视复制积压工作

监测脉冲星群对您的业务非常重要。最重要的是，使用地理复制，不同数据中心之间发生网络分区或网络性能降级的可能性要比单个数据中心内的高很多。因此，密切监视复制统计数据，特别是复制积压工作非常重要。

replication backlog是已生成到源群集但尚未复制到其他远程群集的消息数。监视复制积压工作有两个重要原因：

1. 如果需要从源数据中心故障切换到目标数据中心，则在源数据中心恢复联机之前，可能无法访问在源数据中心生成但尚未到达目标的所有消息。

2. 在目的地发生的任何消息处理都将因积压而延迟。

积压工作通常只是几条消息（取决于两个数据中心之间的网络延迟）。但是如果网络分区不正确，它可能会变大。如果积压不断增加，这表明复制吞吐量低于原始群集产生的吞吐量（例如，原始群集产生的消息速度为100 MB/s，但Pulsar只能以50 MB/s的速度复制消息）在远程数据中心中添加更多代理或在两个数据中心之间添加更多带宽是必要的。

针对数据中心故障的容量规划

在为多个数据中心设计地理复制计划时，另一个需要注意的关键问题是确保消息传递（Apache Pulsar中的brokers）和存储组件（Apache BookKeeper中的bookies）能够在一个或多个数据中心停机时维持长时间的积压，从几个小时到几天。至少要有一个计划，以防故障转移群集没有足够的容量来吸收所有故障转移流量，这一点很重要。

当跨数据中心网络问题解决时，能够提供足够的网络或I/O带宽，以便在不影响现有通信量的情况下，以比生成新消息更快的速度排出积压，这也是至关重要的。

限制复制

当数据中心发生故障时，大量消息将累积在目标集群中。当数据中心恢复时，Pulsar需要将目标集群中积累的消息复制回源集群。因为复制需要消耗大量的积压工作，所以您必须注意这些积压工作的消耗率，并对重要主题的I/O进行优先级排序，对不太重要的主题进行限制。这确保您的业务能够尽快恢复到正常状态。

例如，要限制命名空间中每个主题的每主题排放率，请执行以下操作：

$ bin/pulsar-admin namespaces set-dispatch-rate my-property/global/full-mesh \
  --msg-dispatch-rate 20000

结论

在这篇博文中，我们就如何在Apache Pulsar中使用异步地理复制提供了一些想法，并介绍了一些推荐的最佳实践。我们希望这能让您更好地了解ApachePulsar及其地理复制功能。

原文地址：https://www.splunk.com/en_us/blog/devops/geo-replication-in-apache-pulsar-part-2-patterns-and-practices.html