标题：Disaster Recovery and High Availability 101
原文：https://blog.rabbitmq.com/posts/2020/07/disaster-recovery-and-high-availability-101/
时间：2020-07-07
在这篇文章中，我将讨论我收到的关于企业中RabbitMQ的最常见问题。
如何让RabbitMQ高可用，建议采用哪些架构或做法进行灾难恢复？
RabbitMQ提供了支持高可用性和灾难恢复的功能，但在我们开始之前，我想先做一点准备。首先，我想回顾一下业务连续性规划，并从这些方面阐述我们的需求。从这里开始，我们需要对可能发生的事情设定一些期望。有一些基本定律，如光速和CAP定理，它们都对我们决定采用哪种DR/HA解决方案有严重影响。
最后，我们将了解RabbitMQ的可用特性及其优缺点。
What is the difference between High Availability and Disaster Recovery?
高可用性（High Availability）通常是指在发生局部故障时（如服务器或磁盘故障或有限的网络中断），从已部署软件的一个实例到另一个实例的某种自动故障切换。故障对可用性的影响要么不可见，要么极低。
灾难恢复（Disaster Recovery）通常是指对更重大事件（灾难）的响应，例如整个数据中心的故障、海量数据损坏或任何其他可能导致服务和（或）数据完全丢失的故障。灾难恢复试图避免系统永久的部分或全部故障，通常涉及构建一个在地理位置上与主站点分离的冗余系统。
两者都属于业务连续性（Business Continuity）领域。
The recovery time objective (RTO) is the maximum tolerable length of time that a computer, system, network or application can be down after a failure or disaster occurs.
Recovery point objective (RPO) is the maximum acceptable amount of data loss after an unplanned data-loss incident, expressed as an amount of time.
Business Continuity Planning 101
最终，我们希望能够从重大事件中快速恢复（灾难恢复），并在更轻微的事件中提供持续的可用性（高可用性）。
重大事故可能涉及由于火灾、停电或极端天气而导致整个数据中心故障。更轻微的事故可能涉及部分数据中心故障，或者仅仅是磁盘驱动器或服务器故障。
实现一个能够从故障和灾难中恢复的系统可能在成本上和性能上都很昂贵。最终的实现将是在实现成本、数据丢失成本和服务中断成本之间的平衡。
为了实现这一平衡，我们需要考虑：
- 用于冗余/可用性的工具及其局限性；
- 数据类型以及丢失时的相关业务成本。
首先，我们将介绍可测量的目标，这些目标定义了发生事件时可接受的数据丢失和不可用时间窗口，然后我们将介绍上述考虑因素。
Loss of Data and Availability Objectives
作为业务连续性计划的一部分，企业必须决定灾难恢复方面的两个关键目标。
Recovery Point Objective(RPO)确定了企业可以接受的因重大事件导致的数据丢失的最大量（用时间进行衡量）。显而易见的答案是0秒，这意味着没有数据丢失，但这可能很难实现，即使实现了，也可能带来成本或性能方面的问题。其他值可能是1小时或24小时，值越高，实现成本越低。最终，实现成本会丢失数据带来的业务影响两者之间达到平衡。
Recovery Time Objective(RTO)确定了不可用的最长时间段，即恢复和再次运行所需的时间。显而易见的答案可能是0秒，这意味着无缝故障切换具有持续的可用性，但这在技术上可能无法实现，如果实现了，那么成本可能远远高于企业愿意支付的数量。
这些可用性和数据丢失窗口可能重叠，也可能不重叠。
最终，RPO和RTO都是业务连续性带来的收益与各种不利因素（如成本和性能影响）之间的权衡。
Types of Data and Business Impact
持久性数据会一周又一周甚至年复一年地持续存在。如果一个企业丢失了最有价值的持久性数据，它可能会毁掉公司。瞬态数据的寿命很短，可能是两个系统之间传输的数据，也可能是可以随时收回的数据。虽然丢失临时数据可能会产生影响，但不太可能导致公司倒闭。
Source-of-truth数据是主数据和并且（或者）其他任何地方都不存在的数据。二级数据是source-of-truth数据的备份（可能经过过滤或转换），可以从Source-of-truth的持久化存储中恢复。辅助数据的示例包括：
- 缓存存储二级数据可以从持久性存储重新加载；
- 微服务在数据库中存储少量属于其他服务的数据；
- 分布式日志流数据库中的数据是对其他系统数据的修改。
二级数据丢失可能会导致：
- 从source-of-truth恢复数据过程中失去可用性；
- 丢失热数据导致性能损失。
最具破坏性的数据丢失将是丢失source-of-truth的持久数据，而损失最小的将是瞬态二次数据。
在持久/瞬态光谱图中，在持久化数据端是数据库，瞬态数据端是消息队列（例如RabbitMQ），中间是分布式日志（如Apache Kafka）。数据库、消息队列和分布式日志都能存储source-of-truth数据和二级数据。缓存和搜索引擎通常存储二级数据。
RabbitMQ存储瞬态数据。一条消息只是从一个源传输到一个或多个目的地的数据。一旦被消费，消息将被销毁。如果希望该消息中的数据保持不变，则需要将该消息数据写入某种持久性存储，如数据库、文件系统或对象存储。虽然消息是暂时的，但它仍然可能是source-of-truth数据，因为它在其他任何地方都不存在，如果丢失，则永远无法恢复。
在定义RPO和RTO值时，考虑数据在光谱图中的位置非常重要。因为这些值是实现成本与服务中断代价之间的平衡，所以请确保为存储和服务的数据类型选择适当的平衡。
Data Redundancy Tools - Back-ups and Replication
数据库、缓存和消息队列等数据系统通常提供一种或两种在发生故障时保护数据的方法。
所有数据库系统都提供某种备份功能。完全备份可以按计划进行，如每晚或每周，此外还可以以更快的节奏（如每15分钟）提供增量备份。
关于备份，需要记住的一点是，从备份中恢复可能会导致数据丢失，因为自上次备份以来，可能有新数据进入系统。从备份中恢复还可能需要时间，将备份文件移动到其目标位置需要时间，数据系统从这些文件中恢复需要时间。
另一个常见功能是复制。这是讲数据修改从一个节点流到另一个节点，这意味着数据现在至少位于两个位置。复制有两种风格：同步或异步，它们之间有很大的区别。
对于同步复制，只有在将操作复制到其他节点后，客户端才能确认该操作已成功。这是唯一一种不会造成数据丢失的复制形式，但代价是：
- 等待复制操作会增加延迟；
- 如果节点之间的网络中断，则可能会失去可用性；
- 如果跟随者节点关闭，则可能会失去可用性。
同步复制通常是数据中心内部或云区域内部实现高可用性的解决方案。故障转移通常是自动化的，速度很快，对客户端的影响很小或没有影响。一些数据系统使用异步复制实现高可用性，从而提供最终的一致性（可能会丢失数据）。
使用异步复制，当操作已在本地提交时，客户端将得到操作已成功的确认。该操作在后台复制，这意味着如果primary节点和secondary节点之间的网络断开，客户端不会有额外的延迟，也不会失去可用性。缺点是primary和secondary之间会存在延迟，这意味着如果主节点失效，可能会发生数据丢失。
异步复制和备份通常是灾难恢复的解决方案。
Fundamental Limits
在设计高可用性和灾难恢复策略时，我们需要考虑一些基本限制，如光速和CAP定理。这些限制会影响我们选择的RPO和RTO值的成本和可行性。
CAP定理指出，在网络分区的情况下，您可以具有一致性或可用性，但不能同时具有两者。它使用字母C表示一致性，A表示可用性，P表示分区容错。我们总是要选择P，但我们只得到A或C中的其中之一。
CAP将系统分类为：
- AP - Availability in a partitioned network
- CP - Consistency in a partitioned network
如果CP系统由于失去与对等节点的连接而无法满足必要的冗余程度，则CP系统将失去可用性。CP系统同步复制，并且仅当这些操作安全地提交到多个节点时才向客户端确认。这以更高的延迟为代价避免了数据丢失。
当一致性是最重要的考虑因素时，可以选择CP系统。
AP系统持续可用，尽管没有达到所需的冗余程度。AP系统异步复制，但如果节点宕机，可能会导致数据丢失，这种丢失是由于复制延迟造成的。好处是延迟较低，因为可以立即向客户端确认操作。
当可用性和/或延迟是最重要的考虑因素时，可以选择AP系统。
Single Data Center
在单个数据中心内，可以选择AP或CP系统，许多数据系统都是可配置的，允许您根据可用性或一致性对其进行调整。
在单个数据中心内，网络可以提供高度的可靠性和低延迟。在这种环境中，CP系统使用基于仲裁（多数）的复制算法会使不可用成为罕见的事件。基于Quorum的CP系统可以容忍少数节点的故障或网络隔离，并在不丢失数据的情况下提供可用性，是一个很好的高可用性解决方案。
Multiple Data Centers
数据中心之间网络的可靠性和延迟不如局域网，以可接受的可用性和延迟构建一个CP系统充是很有挑战的，甚至是不可行的。
AP系统可以跨多个数据中心构建，但它们增加了数据丢失的可能性，也增加了数据丢失窗口的大小。
Rack Awareness
这是数据系统的一项功能，可确保跨机架、可用区或数据中心（基本上是基础架构中的任何类型的故障域）复制数据。其思想是，如果数据被复制，但仍然只存在于单个机架上，那么整个机架失效意味着我们丢失了数据。机架感知是一种额外的弹性功能。
当跨AZ分布时，一个AZ的丢失不会导致数据丢失或可用性损失。
HA and DR Considerations Overview
- 高可用性是指在出现故障时保持可用的能力；
- 灾难恢复是指在有限的数据丢失和不可用的情况下从灾难中恢复的能力；
- Recovery Point Objective（RPO）定义了发生灾难时可以接受的数据丢失时间长度；
- Recovery Time Objective（RTO）定义了恢复的最长时间段，即不可用时间长度；
- RPO和RTO是实现成本和数据丢失（服务中断）成本之间的权衡；
- 同步复制以可用性和额外延迟为代价提供了数据安全，是0秒RPO（不允许数据丢失）的唯一选择，通常不支持多DC；
- 异步复制提供了更高的可用性、更低的延迟，但以故障转移中潜在的数据丢失为代价，当允许RPO>0时，这是一个很好的选择，通常与多DC兼容；
- 备份的恢复速度可能较慢，但也有其他好处，如能够根据时间回溯；
- 机架感知为复制的数据存储增加了额外的弹性。
现在，让我们看看RabbitMQ的特性，这些特性与我们目前所讨论的内容相对照。
RabbitMQ
RabbitMQ支持：
- 多节点集群部署；
- 同步复制——复制队列
- 异步的cluster-to-cluster消息路由——联邦exchange和shovels插件
- 有限的备份支持
- 有限的机架感知支持
接下来，我们将了解如何将这些功能用于高可用性和灾难恢复。
High Availability
为了实现高可用性，我们建议在单个数据中心或云区域内部署多个RabbitMQ代理的集群，并使用复制队列。群集需要在代理之间建立高度可靠、低延迟的连接。非常不鼓励通过WAN进行集群部署。
Clustering and Availability Zones
AWS、Azure和GCP中的大多数区域都提供多个可用区。可用区本质上是通过超可靠、低延迟链路连接的数据中心，但不存在地理上的隔离（同一地理位置）。与仅在一个AZ中托管集群相比，在这些云中跨AZ进行集群部署可以提供更高的可用性。然而，如果云提供商对跨AZ数据传输收费，则可能会增加成本。
多AZ群集是实现高可用性的良好选择，但由于缺乏地理隔离，可能无法满足你的灾难恢复需求。需要注意的是，AZ的概念没有标准化，其他云平台可能会更松散地使用这个术语。
RabbitMQ提供了两种类型的复制队列：镜像队列（HA队列）和仲裁队列。这些队列类型使用同步复制，并在遇到服务器、磁盘和网络等故障时提供数据安全性和高可用性。
Clustering and Multiple Data Centers
由于网络分区的影响，我们强烈反对跨WAN进行群集部署。公共互联网上的隧道链接根本不可行。来自运营商的租用链接更好，但也是一个危险的选择。如果一个企业有自己的光纤连接其数据中心，以一种高可靠且持续低延迟的方式（例如on-prem可用区）进行部署，那么它可能是一种选择。
Quorum Queues
仲裁队列是CP系统，只要仲裁（多数）仍在运行，就可以容忍broker的失效。同样，在网络分区的情况下，只要队列的大多数节点仍然可以通信，队列就会继续工作。仲裁队列不使用RabbitMQ的传统分区处理策略，而是使用其自己的故障检测器，该检测器可以更快地检测分区和故障，也不太容易出现误报，这提供了最快速度的故障转移复制队列类型。
Classic Mirrored Queues
可以针对可用性（AP）或一致性（CP）配置经典的镜像队列。使用auto-heal 或ignore分区处理策略将允许集群中的所有代理继续为发布者和消费者提供服务，即使一个或多个代理被网络分区切断。但是，从分区恢复时，数据可能会丢失。
使用pause_minority分区处理策略可以使镜像队列倾向于一致性。在网络分区的情况下，少数端的任何代理都将暂停自己，关闭所有网络连接。不会丢失任何已确认的写入，但少数端的任何代理都会丢失可用性，如果不存在多数派分区，则整个集群将变得不可用。同样，如果大多数节点关闭，其余代理将暂停自己。
故障转移的速度不如仲裁队列快，并且存在一些边缘情况，对于非常大的队列，故障转移可能需要几分钟或几小时。
请参阅我们最近关于仲裁队列和镜像队列的文章，其中对这一点进行了更详细的解释。
Client Reconnections
为了实现高可用性，客户端还需要能够在连接失败或代理脱机时自动重新连接。大多数RabbitMQ客户端提供自动重新连接功能。当通过各自的主机名访问集群代理时，请确保所有代理地址都提供给客户端，以便客户端可以尝试重新连接到集群中的所有节点，直到找到一个正在运行的代理。使用负载平衡时，请确保负载均衡不带有亲和力/粘性，以保证当客户端重新连接时，它们不会总是路由回同一个代理（该代理现在可能已关闭）。
Rack Awareness
虽然RabbitMQ目前没有机架感知，但可以通过手动指定复制队列应分布的节点来实现相同的结果。使用镜像队列，你可以指定它应该分布的节点列表。对于仲裁队列，您当前必须创建初始组大小为1的队列，然后在节点上添加成员以实现所需的分布。
Capacity Planning
良好的容量规划与业务连续性规划齐头并进，因为这两者都是实现可靠性和弹性所必需的。查看我们的RabbitMQ规模指南。
Disaster Recovery
灾难恢复通常需要在数据中心之间异步复制数据。RabbitMQ目前不支持此功能，但可以利用其他消息路由功能提供部分解决方案。
RabbitMQ支持schema复制（包括exchanges, queues, bindings, users, permissions, policies等），允许不同数据中心中的第二集群成为主集群的空镜像。仅使用schema同步的故障恢复将提供可用性，但有一个数据丢失窗口。
Schema Replication
RabbitMQ有两个用于schema复制的特性。
- 定义导出/导入是management插件的一项功能，允许通过JSON文件导出和导入schema；
- Tanzu RabbitMQ提供了schema同步插件，可以将schema更改主动复制到第二集群。
Data
RabbitMQ还没有适合所有多DC场景的异步数据复制功能。但是，您可以利用exchange federation或shovels，这是一种跨群集工作的异步消息路由功能。这些功能不是为active-passive体系结构构建的，因此确实存在一些缺点。这类插件是为在集群之间移动要主动处理的消息而构建的，而不是为冗余而镜像集群的数据。
复制和跨集群消息路由的区别在于，复制涉及复制入队和确认操作，而消息路由仅涉及复制消息。实际上，联邦exchange或shovel不会处理已经被消费并从队列中移除的消息（因为这不是这些插件的目的）。
上面这段的意思是，replication会复制数据和消费进度，而cross-cluster message routing只复制数据，不复制消费进度。
例如，exchange E1绑定到了DC1中的一个仲裁队列。DC2有一个到DC1的federation链接和一个E1的federation exchange，后者也同样绑定到了一个仲裁队列。当消息m1和m2发布到DC1上的E1时，这些消息将路由到DC1上的队列中，也将异步路由到DC2上的E1，并在那里进入队列。现在，两个DC中的队列上都存在消息m1和m2。
但现在消费者消费并确认DC1上的消息m1和m2，并发布新消息m3和m4。仲裁队列leader同步复制新消息和确认信息。Federation会将m3和m4消息路由到DC2，而不包括acks（federation只路由消息）。现在m1和m2只存在于DC2上，这两条消息已在DC1上被消费了。如果DC1失效，我们故障切换到DC2，m1和m2将再次消耗。
这意味着当RabbitMQ发生故障切换集群时，需要容忍消息重复。此外，随着消息的累积，队列将继续增长。
为了缓解复制问题，你可以在被动集群上应用消息TTL策略，在一段时间后删除消息，也可以在队列长度达到限制时删除消息。诚然，这些都是不完美的解决方案，因为它们实际上可能导致消息丢失。给定一个24小时的TTL，当DC1宕机时，一条消息可能已经在DC1中的队列中等待了25个小时而未被消费，并且该消息将在一小时前从DC2中的同一队列中被删除。
为了应对重复，您的系统要么需要容忍重复（通过幂等），要么有去重方案（例如将消息ID存储在Redis中）。任何at-least-once的消息队列或总线都会不时导致重复，因此这可能已经得到了处理。
A Note on Back-ups
RabbitMQ确实支持备份，但支持有限，因此不常用。限制是，必须完全关闭集群才能备份其数据目录。这使备份成为大多数企业无法选择的灾难恢复策略。
Summary
RabbitMQ通过使用集群和复制队列，为单个数据中心内或跨多个可用区的高可用性提供了极好的支持。
对于需要多个数据中心的业务连续性计划，在active-passive架构中实现地理隔离是一个挑战。只有单群集才能实现0分钟的RPO，在多DC（或多地区）场景中是不现实的。RPO在0分钟以上时，我们可以利用federation和shovel，但这也带来了消息重复方面的挑战。这种重复可以通过去重策略来解决。
RabbitMQ的road-map上有许多功能，包括对灾难恢复的真正异步复制支持、数据恢复工具、机架感知等。所以请继续关注，因为RabbitMQ变化很快。
标签：Disaster,队列,可用性,RabbitMQ,High,复制,丢失,数据,Availability From： https://www.cnblogs.com/oyld/p/16829945.html