ApachePulsar中的地理复制：概念和特性

灾难恢复计划以及最佳的灾难避免战略的重要性怎么强调都不为过。在任何一周，都有大量的头条新闻表明这是真的。无论是哪个行业，当发生不可预见的事件并导致日常运营中断时，组织都需要尽快恢复，以继续向其客户提供服务。从数据安全漏洞到自然灾害，必须有一个快速、灵活应对灾难的计划。如果没有灾难恢复计划，可能会使公司面临高财务成本、声誉损失的风险，甚至会给客户和客户带来更大的风险。

在多方面的企业软件系统中，灾难避免策略和恢复计划需要多数据中心部署，其中数据中心在地理上是分散的。在这种多数据中心部署中，可以部署地理复制机制，以便在数据中心发生故障或其他事件导致无法继续正常运行时提供额外冗余。

在本篇和后续的博客文章中，我们将介绍ApachePulsar提供的另一个企业级功能：Geo-replication 地理复制。Apache Pulsar利用Apache BookKeeper的可扩展流存储，是一个消息传递系统，支持跨多个数据中心的同步地理复制（通过Apache BookKeeper）和异步地理复制（在代理级别配置）。我们将在这篇博文中从一些简单的概念和特性开始，并在下一篇博文中描述一些部署实践。

概念

Geo-replication地理复制是用于提供灾难恢复的典型机制。许多数据系统声称支持地理复制。但是，这些系统通常只复制到两个数据中心，并且在复制到两个以上的数据中心时具有严重的限制。这可能会让用户感到困惑，并被迫对系统做一些难以处理的事情，试图将其复制到多个数据中心。在讨论ApachePulsar中的地理复制功能之前，我想花一些时间讨论一下地理复制中的一些基本概念。

不同数据系统中使用的地理复制机制可分为两类：同步地理复制和异步地理复制。Apache Pulsar支持两种地理复制策略。下面的图1说明了同步地理复制和异步地理复制之间的区别。

在本例中，假设有3个数据中心：美国西部、美国中部和美国东部，同时客户机向美国中部发出写入请求。在同步地理复制情况下，当客户端向us-central发出写入请求时，写入us-central的数据将复制到其他两个数据中心，即us-west和us-east。写入请求通常仅在大多数数据中心已发出写入已持久化的确认时才向客户端确认。在这种情况下，至少有2个数据中心必须确认此写入请求已被持久化。这种机制称为“同步地理复制”，因为数据同步复制到多个数据中心，客户端必须等待来自其他数据中心的确认。

相反，使用异步地理复制，客户端不必等待其他数据中心的响应。us-central成功保存数据后，客户端立即收到响应。然后以异步方式将数据从us-central复制到另外两个数据中心，即us-west和us-east。

同步地理复制提供了最高的可用性，所有物理上可用的数据中心构成了数据系统的全局逻辑实例。您的应用程序可以在任何数据中心的任何地方运行，并且仍然能够访问数据。它还保证了不同数据中心之间更强的数据一致性，当数据中心发生故障时，应用程序无需任何手动操作即可轻松依赖这些数据一致性。但是，您的应用程序必须支付额外的跨数据中心延迟罚款，从美国西海岸到美国东海岸的延迟通常在几十毫秒左右。

异步地理复制提供了较低的延迟，因为客户端不必等待其他数据中心的响应。但是，由于异步复制，它还导致一致性保证较弱。由于异步复制中始终存在复制延迟（复制延迟通常意味着数据尚未从源复制到目标），因此始终存在一些尚未从源复制到目标的数据。当灾难发生时（无论是洪水、火灾、地震等自然灾害，还是单纯的断电或外部连接中断），整个数据中心都可能瘫痪，导致未复制的数据丢失。由于复制滞后，当数据中心发生故障时，通常需要编写或配置应用程序以容忍此类情况。异步地理复制通常用于具有宽松一致性要求的用例中，并且通常在消息传递或非数据库存储系统中观察到。

Apache Pulsar依靠Apache BookKeeper实现持久的消息存储，能够支持两种地理复制方法。

在开始讨论细节之前，让我花30秒来解释一个典型的Pulsar装置。这将有助于解释Apache Pulsar如何支持同步和异步地理复制。

图2展示了Apache Pulsar的典型安装。Pulsar集群由两层组成：无状态服务层，由一组代理组成，用于服务发布/订阅流量；还有一个有状态持久层，由一组BookKeeper bookies组成，用于持久存储消息。

这种将存储与服务发布子流量分离的体系结构模式具有很多优点。它使brokers成为“无状态”的，这使得负载平衡和流量转移变得便宜。这已被证明是多租赁成功的关键。它也是使Apache Pulsar能够支持同步和异步地理复制的关键。

BookKeeper中的同步地理复制

同步地理复制实际上是由ApacheBookKeeper在Pulsar的存储层中实现的（贡献合并自ApacheDistributedLog）。图3显示了提供同步地理复制的典型Pulsar安装。

同步地理复制脉冲星安装包括一个全球Zookeeper安装（Zookeeper集成运行在多个数据中心）、一个运行在多个数据中心的博彩公司集群，以及一个也运行在多个数据中心的代理集群。Pulsar代理配置并使用簿记员区域感知放置策略跨多个数据中心存储数据，并保证写入时的可用性约束（例如，在确认之前至少写入2个数据中心）。

当数据中心发生故障时，同步地球同步复制Pulsar集群可以继续正常工作。在它上面运行的应用程序在很大程度上不会受到影响。添加新数据中心或使旧数据中心退役将对应用程序透明。添加或停用数据中心甚至可以在运行时完成，在执行此类操作时，停机时间为零。这种设置适用于能够容忍稍高延迟的任务关键型用例。

Pulsar中的异步地理复制

相反，异步地理复制Pulsar集群由多个物理集群组成，这些物理集群设置在不同的数据中心。Pulsar brokers在这些不同的集群之间异步复制数据。图5展示了一个异步地理复制pulsar安装，与图3所示的同步地理复制集群形成对比。

在异步地理复制中，当在Pulsar主题上生成消息时，它们首先被持久化到本地集群，然后异步复制到远程集群。在正常情况下，当没有连接问题时，消息会立即复制，同时发送给本地消费者。通常，端到端交付延迟由数据中心之间的网络往返时间（RTT）定义。应用程序可以在任何集群中创建生产者和消费者，即使远程集群不可访问（例如，在网络分区期间）。

在Pulsar中，可以基于每个属性（每个租户）启用异步地理复制。这意味着只有在创建了允许访问两个集群的属性时，才能在集群之间启用异步地理复制。尽管由于权限限制，必须在每个属性的基础上启用地理复制，但它实际上是在命名空间级别进行管理的。这意味着，如果租户拥有访问数据中心A、B、C和D的权限，则可以为A和B之间的地理复制创建一个命名空间，为C和D之间的地理复制创建另一个命名空间，同时为A、B、C和D之间的全网格复制创建第三个命名空间。

Pulsar为租户定制复制策略提供了很大的灵活性。这意味着应用程序能够在多个数据中心之间设置主从式复制、主动-主动双向复制和全网格复制（图5显示了3个数据中心中的全网格复制设置）。此外，复制由Pulsar代理自动执行，对应用程序透明。这意味着，与需要设置额外复杂流程以在数据中心之间镜像消息的其他发布-订阅消息系统不同，地理复制可以在运行时启用、禁用或动态更改（例如，从主从复制到主动-主动双向复制），只需发出一个管理命令。有关在Pulsar中使用异步地理复制的故障切换、回切和最佳实践的详细信息，我们将在下一篇博文中详细介绍。

Yahoo上的多数据中心复制

自2015年以来，Pulsar已在雅虎全球10多个数据中心部署，采用全网格异步地理复制。此地理复制已用于关键任务服务，如邮件、金融、双子座广告、Sherpa（雅虎的分布式关键价值服务）等。它每天在140万个主题上复制1000亿条消息。

在这种规模下，拥有有效管理复制的灵活性和工具变得至关重要。从添加或删除区域，到命名空间的复制集，再到进行监视，以显示数据保留的位置、数据量以及复制缓慢发生的原因。

最后，也是最重要的一点，通过地理复制，不同数据中心之间发生网络分区或网络性能降级的可能性要比单个数据中心内高出很多。因此，对于消息传递和存储组件来说，能够维持一段从数小时到数天的长时间构建待办事项是至关重要的。同样重要的是，当网络问题得到解决时，能够在不影响通信量的情况下，以比发布新消息更快的速度排出积压。

结论

Apache Pulsar利用Apache BookKeeper的可扩展流存储，是一个消息传递系统，支持同步地理复制（通过Apache BookKeeper）和异步地理复制（在broker级别配置）。在这篇博文中，我们研究了数据系统地理复制中使用的两种常用方法，并解释了它们的区别和权衡。Pulsar通过不同的机制支持两种地理复制方法。我们希望这能让您更好地了解ApachePulsar及其地理复制功能。

原文地址：https://www.splunk.com/en_us/blog/it/geo-replication-in-apache-pulsar-part-1-concepts-and-features.html