Apache Pulsar 中的地域复制，第 1 篇：概念和功能

灾难恢复规划，甚至更理想情况下使用的防灾规划，它们的重要性怎么强调都不为过，每周都会有相关的头条新闻报道证明这个结论的正确性。无论什么行业，如果遭遇无法预见的事件并影响到日常运维，组织都需要尽可能快速恢复运转，继续为自己的客户提供服务。从数据安全入侵到自然灾害，必须具备妥善的规划，以便快速灵活地应对灾难性事件。如果不具备行之有效的灾难恢复规划，可能导致组织面临各种风险，例如遭受巨大经济损失、声誉受损，甚至为组织的客户和用户造成更严峻的风险。

在多面性的企业软件系统中，防灾策略和恢复规划需要部署在地理位置分散的多个数据中心内。在此类多数据中心部署中，通常会使用地域复制机制提供额外的冗余，以防某个数据中心故障或其他事件导致无法照常继续运作。

本文和下一篇文章将介绍 Apache Pulsar 自带的另一个企业级功能：地域复制。Apache Pulsar 使用了 Apache BookKeeper 这一可伸缩的流存储机制，这是一种可跨越多个数据中心，同时支持同步地域复制（借助 Apache BookKeeper）和异步地域复制（通过 Broker 级别的配置）的消息系统。首先本文将介绍一些简单的概念和功能，下篇文章将侧重于具体的部署实践。

概念

地域复制是一种典型的灾难恢复机制。虽然很多数据系统都宣称支持地域复制，然而这些系统通常只能复制到两个数据中心，如果要复制到更多位置，通常会遇到不少的局限。这可能会造成用户困惑，并且不得以只能通过繁琐的方式试着复制到多个数据中心。在介绍 Apache Pulsar 的地域复制功能之前，下文首先将介绍几个有关地域复制的基本概念。

很多数据系统所用的地域复制机制主要可分为两个类别：同步地域复制和异步地域复制。Apache Pulsar 可同时支持这两种类型。下文图 1 展示了同步和异步地域复制之间的差异。

本例假设了 3 个数据中心：us-west、us-central和us-east，客户端向us-central发出写操作请求。如果使用同步地域复制，客户端向 us-central 发起请求后，写入 us-central 的数据会复制到另外两个数据中心：us-west 和 us-east。通常只有在大多数的数据中心确认写操作已成功完成后，客户端才会获得有关该写入请求的确认。也就是说在本例中，至少要求两个数据中心确认写入请求已成功完成。这种机制也叫做“同步地域复制”，因为数据会以同步的方式复制到多个数据中心，客户端必须等待其他数据中心的确认。

图 1：同步地域复制和异步地域复制

与之相对的异步地域复制中，客户端不需要等待其他数据中心的回应，客户端会在 us-central 成功完成写入操作后立刻收到回应。随后这些数据会从 us-central 复制到另外两个数据中心：us-west 和 us-east，只不过会以异步的方式进行。

同步地域复制可提供最高可用性，此时所有可用的物理数据中心将为数据系统提供一个全球化的逻辑实例。应用程序可在任何数据中心内运行，并且任何时候都可以访问这些数据。这种模式还可以确保不同数据中心之间更强的数据一致性，如果一个数据中心故障，无需任何手工操作即可保障应用程序继续运行。然而应用程序需要承受额外的跨数据中心延迟作为代价，美国东西海岸之间这样的通信延迟通常约为数十毫秒。

异步地域复制的延迟更低，因为客户端不需要等待其他数据中心的回应。然而这种模式提供的一致性保证较弱，毕竟复制是异步进行的。由于异步复制始终存在复制滞后（复制滞后通常是指数据尚未从源复制到目标），因此始终存在还没有从源完全复制到目标的数据。当面临会影响整个数据中心的灾难（例如洪水、火灾、地震等自然灾害，或断电断网等情况）时，尚未完成复制的数据将会丢失。由于复制滞后的存在，应用程序在开发或配置时通常需要考虑此类整个数据中心出现故障的情况。异步地域复制通常主要用于一致性要求不那么高的场合，例如消息系统或非数据库的存储系统。

Apache Pulsar 依赖 Apache BookKeeper 实现持久的消息存储，可同时支持这两种地域复制方法。

在介绍细节前，下文打算简单谈谈典型的 Pulsar 安装过程，这有助于解释 Apache Pulsar 何以同时支持同步和异步的地域复制。

图 2 展示了一个典型安装的 Apache Pulsar。Pulsar 集群包含两层：一个无状态的服务层（Serving Layer），其中包含一系列用于为 pub/sub 流量提供服务的中介（Broker）；以及一个有状态的持久层（Persistence layer），其中包含一系列用于提供持久消息存储能力的 BookKeeper bookie。

图 2：典型安装的 Apache Pulsar

这种架构模式实现了存储与 pub-sub 流量服务的分离，可获得多种优势。Broker 可以是“无状态”的，因此可以用更低成本实现负载均衡和流量转移。这种架构已被证明是多租户功能得以成功实现的关键（有关多租户的详情可参阅这篇博客文章）。同时这也是使得Apache Pulsar 能够同时支持同步和异步地域复制的关键。

BookKeeper 中的同步地域复制

同步地域复制实际上是由 Apache BookKeeper 在存储层为 Pulsar 实现的。典型的 Pulsar 安装通常会提供图 3 所示的同步地域复制。

图 3：使用同步地域复制的 Pulsar 环境

使用同步地域复制的 Pulsar 环境包含一个全局的 Zookeeper（一整套 ZooKeeper 环境将跨越多个数据中心运行），一个在多个数据中心内运行的 Bookie 集群，以及一个同样在多个数据中心内运行的 Broker 集群。此外需要为 BookKeeper 配置使用区域感知安放策略，Pulsar Broker 将使用该策略跨越数据中心存储数据，同时为写操作提供一致性保障（例如确认之前至少写入到两个数据中心）。

图 4：同步地域复制 Pulsar 环境在一个数据中心故障后的应对方式

如果一个数据中心故障，同步地域复制的 Pulsar 环境依然可以继续正常运转。其中运行的应用程序基本上不受任何影响，无论添加新的数据中心，或停用老的数据中心，这些操作对应用程序都是透明的。甚至可在应用程序运行过程中不停机增减数据中心。此类配置很适合可以容忍较高延迟的关键业务应用。

Pulsar 中的异步地域复制

作为对比，异步地域复制 Pulsar 集群包含位于多个数据中心内的多个物理集群环境。Pulsar Broker 会在这些集群之间以异步的方式复制数据。图 5 展示了一个异步地域复制的 Pulsar 环境，建议与图 3 的同步地域复制环境对比着看。

图 5：异步地域复制 Pulsar 环境

在异步地域复制的情况下，如果针对某个 Pulsar 主题产生了新的消息，消息首先会持久保存在本地集群中，随后异步复制到远程集群。大部分情况下如果网络连接正常，消息均可以在供本地消耗的同时立刻复制。通常来说，端到端交付延迟是由数据中心之间的网络往返耗时（RTT）决定的。应用程序可以在任何集群中创建生产者（Producer）和消费者（Consumer），哪怕此时远程集群并不可访问（例如在有网络分区操作发生的过程中）。

Pulsar 中，可在每个资产（每个租户）的层面上启用异步地域复制。这意味着只有当一个资产已经成功创建，并允许访问所有集群的情况下，才可以在集群间启用异步地域复制。虽然从权限的限制出发，地域复制必须针对每个资产启用，但可以从名称空间的层面加以管理。也就是说，如果租户有权访问数据中心 A、B、C 和 D，即可在数据中心 A 和 B 之间为地域复制创建名称空间，并为 C 和 D 的地域复制创建另一个名称空间，同时为 A、B、C 和 D 之间的全连接（Full-mesh）复制创建第三个名称空间。

在复制策略的定制方面，Pulsar 为租户提供了巨大的灵活性。这意味着应用程序可以在多个数据中心之间设置主从模式的复制，双活双向复制，以及全连接复制（图 5 展示的是用 3 个数据中心建立的全连接复制）。此外复制操作可由 Pulsar Broker 自动进行，对应用程序完全透明。其他 pub-sub 消息系统往往需要额外设置复杂的进程来为数据中心之间的消息创建镜像，Pulsar 的地域复制则可在运行过程中随时启用、禁用或更改（例如从主从复制改为双活双向复制），这些操作只需要一条管理命令即可。有关 Pulsar 中使用异步地域复制实现故障转移、失败回滚等操作，以及其他最佳实践的详情，建议等待下一篇文章。

Yahoo 的多数据中心复制

Yahoo 自从 2015 年开始，已经在全球十几个数据中心内部署了 Pulsar，并使用了全连接异步地域复制的配置。这一地域复制机制主要被用于关键业务服务，例如邮件、财经、Gemini 广告、Sherpa（Yahoo 的分布式键 - 值服务）等，整个系统针对超过 140 万个主题，每天复制上千万亿条消息。

以这样的规模来看，整个系统必须足够灵活，并且提供必要的工具，帮助用户高效管理复制过程。从增减地域到名称空间的复制集，再到全面了解数据到底会被保存到何处，复制的数据量是多少，为何复制过程非常缓慢的监视能力，都必须充分考虑到。

最后最重要的是，在使用地域复制后，产生网络分区或导致不同数据中心间网络性能退化的可能性会远远高于只使用一个数据中心的时候。因此所用消息和存储组件也必须能够承受更长时间段的构建积压，可能从数小时到数天不等。同样重要的还有，当网络问题顺利解决后，必须能用快过新消息抵达的速度更快速地处理掉积压的内容，同时不能对流量产生影响。

结论

Apache Pulsar 充分利用了 Apache BookKeeper 的可伸缩流存储，这是一种可同时支持同步地域复制（借助 Apache BookKeeper）和异步地域复制（在 Broker 层面配置）的消息系统。本文介绍了数据系统中常用的两种地域复制机制，并探讨了两者的差异和必要的权衡。Pulsar 可通过不同机制同时支持这两种地域复制方法。希望本文可以帮你更好地理解 Apache Pulsar 及其地域复制功能。下篇文章将介绍在 Apache Pulsar 中使用异步地域复制的几种常见模式和实践。

如果对 Pulsar 感兴趣，你也可以通过下列方式加入 Pulsar 社区：

• Pulsar Slack 频道，请在这里注册： https://apache-pulsar.herokuapp.com/ 。
• Pulsar邮件列表。

有关 Apache Pulsar 项目的常规信息，请访问官网： http://pulsar.incubator.apache.org/ ，此外也可关注 Twitter 帐号 @apache_pulsar 。

作者：Sijie Guo，阅读英文原文： Geo-replication in Apache Pulsar, part 1: concepts and features

感谢杜小芳对本文的审校。