Azure Cosmos DB for NoSQL 中的高可用性（可靠性）

本文介绍 Azure Cosmos DB for NoSQL 中的高可用性（可靠性）支持，包括可用性区域以及跨区域灾难恢复和业务连续性。

计算节点的复原能力

Azure Cosmos DB 以透明方式管理单个计算节点的所有详细信息。 无需考虑任何类型的修补或计划内维护。 Azure Cosmos DB 通过系统执行的所有自动维护操作来保证 SLA 的可用性和 P99 延迟。

Azure Cosmos DB 保证四个副本仲裁内的帐户的每个 Azure 区域中至少有三个数据副本，从而自动缓解副本中断。 对于单个节点中断，此保证会使 RTO 为 0，RPO 为 0，无需更改或配置应用程序。 有关 RTO 和 RPO 的信息，请参阅什么是业务连续性、高可用性和灾难恢复？

可用性区域支持

可用性区域 是每个 Azure 区域内物理上独立的数据中心群组。 当一个区域发生故障时，服务可以故障转移到其他区域。

Azure Cosmos DB 支持 区域冗余。 启用区域冗余时，Azure 跨多个可用性区域分发数据的副本，从而为数据中心问题和中断提供复原能力。 可以在支持可用性区域的 Azure 区域中启用区域冗余。 若要查看你所在的区域是否支持可用性区域，请参阅支持的区域列表。

建议在支持的区域中使用区域冗余，尤其是对于单区域帐户。

区域冗余和单区域帐户

当您拥有单区域 Cosmos DB 帐户时，确保具有应对可用性区域内问题的能力是很重要的。 启用区域冗余机制可以防范由于可用性区域发生故障而导致的总可用性损失。

由于可用性区域在物理上是独立的，并且提供不同的电源、网络和冷却，因此 Azure Cosmos DB 的可用性 SLA 对于区域冗余帐户比不使用可用性区域的帐户更高。

区域冗余和多区域帐户

如果有多区域帐户，可以选择对支持可用性区域的任何或所有帐户区域启用区域冗余。 多区域帐户可以实现高可用性服务级别协议（SLA），启用区域冗余可以进一步增强在这些区域中实现的总体可用性 SLA。

对于多区域帐户，区域冗余对 Cosmos DB for NoSQL 数据库的可用性的影响取决于帐户的一致性级别以及启用了区域冗余的区域。 请参阅下表，估算在多区域帐户配置中使用可用性区域的影响：

启用区域冗余的成本

启用区域冗余的区域会收取 25% 的溢价费。 但是，对于配置了多区域写入的帐户和/或配置了自动缩放模式的集合，可以免除可用性区域的溢价。

向 Cosmos DB 帐户添加一个额外的区域通常会使每个区域的现有帐单增长 100%。 但是，各个区域的成本差异很小。

有关详细信息，请参阅定价页。

SLA 改进

若要提高 Azure Cosmos DB 帐户的复原能力和可用性，可以实现分层方法，其中包括：

• 启用区域冗余。
• 添加一个或多个其他区域。
• 启用多区域写入功能。

分层方法在每个步骤都保护帐户，从无区域冗余的单区域配置的四个九的可用性，到具有区域冗余的单个区域的四个半九的可用性，一直到启用多区域写入选项的多区域配置的五个九的可用性。

下表包含每个配置的 SLA 摘要：

1 对于无服务器帐户，RU 乘以系数 1.25。

2 1.25 速率仅适用于启用可用性区域的区域。

配置可用性区域

创建支持可用性区域的资源

只有在将新区域添加到 Azure Cosmos DB NoSQL 帐户时，才可以配置可用性区域。

若要启用可用性区域支持，可以使用：

• Azure 门户

• Azure CLI

• Azure 资源管理器模板

启用可用性区域支持

若要了解如何在 Azure Cosmos DB 帐户上启用区域冗余，请参阅 将 Azure Cosmos DB for NoSQL 迁移到可用性区域支持。

跨区域灾难恢复和业务连续性

灾难恢复（DR）是指组织用来从高影响事件（例如自然灾害或导致停机和数据丢失的部署）中恢复的做法。 不管灾难的原因是什么，最好的补救措施就是一个定义全面且经过测试的 DR 计划，以及一个主动支持 DR 的应用程序设计。 在开始创建灾难恢复计划之前，请参阅 有关设计灾难恢复策略的建议。

对于灾难恢复，Microsoft使用共同责任模型。 在此模型中，Microsoft确保基线基础结构和平台服务可用。 但是，许多 Azure 服务不会自动复制数据，也不会从失败的区域回退到另一个已启用的区域。 对于这些服务，你负责设置适用于工作负载的灾难恢复计划。 在 Azure 平台即服务 (PaaS) 产品/服务上运行的大多数服务都提供支持 DR 的功能和指南。 可以使用服务特定的功能来支持快速恢复，从而帮助制定灾难恢复计划。

区域中断指的是跨所有可用性区域影响 Azure 区域中所有 Azure Cosmos DB 节点的中断。 对于极少数区域中断的情况，可以将 Azure Cosmos DB 配置为支持持续性和可用性的各种结果。

持续性

当在单个区域中部署 Azure Cosmos DB 帐户时，通常不会发生数据丢失。 在受影响的区域中恢复 Azure Cosmos DB 服务后，会还原数据访问。 只有在 Azure Cosmos DB 区域发生不可恢复的灾难时，才可能发生数据丢失。

为了帮助防止区域中的毁灭性灾难可能导致数据完全丢失，Azure Cosmos DB 提供了两种备份模式：

• 连续备份 每 100 秒备份一次每个区域。 它们使你能够以 1 秒的粒度将数据还原到任何时间点。 在每个区域，备份取决于该区域提交的数据。 如果该区域已启用可用性区域，则备份将存储在区域冗余的存储帐户中。
• 定期备份，从帐户下的所有容器完全备份所有分区，不跨分区同步。 最小备份间隔为 1 小时。

在多个区域中部署 Azure Cosmos DB 帐户时，数据持续性取决于在该帐户上配置的一致性级别。 对于所有一致性级别，下表详细说明了在至少两个区域中部署的 Azure Cosmos DB 帐户的 RPO。

K = 某项的版本（即更新）数。

T = 自上次更新以来的时间间隔。

对于多区域帐户，K 和 T 的最小值为 100,000 次写入操作或 300 秒。 此值定义了使用有限过期时数据的最小 RPO。

有关一致性级别之间差异的详细信息，请参阅 Azure Cosmos DB 中的一致性级别。

服务托管故障转移

如果解决方案需要在区域中断期间保持持续运行，可以将 Azure Cosmos DB 配置为跨多个区域复制数据，并在需要时透明地故障转移到正常工作的区域。

发生区域性服务中断时，单区域帐户的可访问性可能会丢失。 要确保始终保持业务连续性，建议设置具有单写入区域和至少第二个（读取）区域的 Azure Cosmos DB 帐户并启用服务托管的故障转移。

借助服务托管故障转移，Azure Cosmos DB 可以对多区域帐户的写入区域进行故障转移，从而以数据丢失为代价来保持业务连续性，如前面的持久性部分所述。 区域故障转移是在 Azure Cosmos DB 客户端中检测和处理的。 它们不需要在应用程序中进行任何更改。 有关如何启用多个读取区域和服务托管故障转移的说明，请参阅使用 Azure 门户管理 Azure Cosmos DB 帐户。

多个写入区域

可以将 Azure Cosmos DB 配置为接受多个区域内的写入。 此配置有助于减少地理分散式应用程序中的写入延迟。

为多个写入区域配置 Azure Cosmos DB 帐户时，不支持强一致性，可能会出现写入冲突。 有关如何解决这些冲突的详细信息，请参阅使用多个写入区域时的冲突类型和解决策略。

冲突解决区域

当 Azure Cosmos DB 帐户配置了多区域写入时，其中一个区域将充当写入冲突中的仲裁者。

多区域写入的最佳做法

下面是写入多个区域时要考虑的一些最佳做法。

将本地流量保持在本地

使用多区域写入时，应用程序应严格向本地 Cosmos DB 区域发出源自本地区域的读写流量。 为了获得最佳性能，请避免跨区域调用。

应用程序必须避免以下反模式以最大程度地减少冲突：

• 将相同的写入操作发送到所有区域，从而提高获得快速响应时间的几率

• 根据每个请求随机确定读取或写入操作的目标区域

• 使用轮循机制策略根据每个请求确定读取或写入操作的目标区域。

避免依赖复制延迟

无法配置多区域写入帐户来实现强一致性。 在 Azure Cosmos DB 在本地复制数据后，写入的区域会立即响应，同时以异步方式全局复制数据。

虽然不常见，但在异地复制数据时，一个或几个分区上可能会发生复制延迟。 复制延迟可能是由于网络流量中的罕见波动或冲突解决率高于平常导致。

例如，应用程序写入区域 A 但从区域 B 读取的体系结构引入了对两个区域之间复制延迟的依赖。 但是，如果应用程序读取和写入同一区域，即使存在复制延迟，性能也会保持不变。

评估写入操作的会话一致性使用情况

在会话一致性中，使用会话令牌执行读写操作。

对于读取操作，Azure Cosmos DB 会将缓存的会话令牌发送到服务器，保证接收与指定（或较新）会话令牌相对应的数据。

对于写入操作，Azure Cosmos DB 会将会话令牌发送到数据库，并确保只有在服务器赶上提供的会话令牌时才会持久化数据。 在单区域写入帐户中，可始终确保写入区域已赶上会话令牌。 但在多区域写入帐户中，你进行写入操作的区域可能尚未赶上向另一个区域发出的写入。 如果客户端使用来自区域 B 的会话令牌写入区域 A，在赶上区域 B 中所做的更改之前，区域 A 将无法保留数据。

在客户端实例之间传递会话令牌时，最好仅将会话令牌用于读取操作而非写入操作。

缓解对同一文档的频繁更新

当重复更新同一文档时，服务器用于解决或确认不存在冲突的更新可能会与应用程序触发的写入发生冲突。 在解决冲突期间，对同一文档的连续快速重复更新会导致更高的延迟。

尽管重复更新同一文档时无法避免出现偶发激增，但如果在较长时间内持续频繁地更新同一文档，可以考虑采用创建新文档的体系结构。

读取和写入中断

在服务还原之前，单区域帐户的客户端会遇到读写可用性损失的情况。

多区域帐户会经历不同的行为，具体取决于以下配置和中断类型。

有关读取区域中断的其他信息

• 断开受影响区域的连接，并将其标记为脱机。 Azure Cosmos DB SDK 会将读取调用重定向到首选区域列表中的下一个可用区域。

• 如果首选区域列表中无可用区域，调用会自动回退到当前的写入区域。

• 处理读取区域服务中断不需要对应用程序代码进行更改。 受影响的读取区域重新联机后，它会自动与当前写入区域同步，并在完全回复后再次可用于处理读取请求。

• 后续的读取会重定向到恢复的区域，不需更改应用程序代码。 在故障转移和重新加入之前发生故障的区域期间，Azure Cosmos DB 会继续遵循读取一致性保证。

• 即使在发生了 Azure 区域永久无法恢复的罕见不幸事件中，如果为多区域 Azure Cosmos DB 帐户配置了强一致性，也不会丢失数据。 多区域 Azure Cosmos DB 帐户具有前面持续性部分指定的持续性特征。

有关写入区域中断的其他信息

• 在写入区域中断期间，如果在 Azure Cosmos DB 帐户上配置了服务托管故障转移，该帐户会将次要区域提升为新的主要写入区域。 会按你指定的区域优先级顺序故障转移到其他区域。

• 不应触发手动故障转移，这在存在源或目标区域中断时不会成功。 原因是故障转移过程包括一致性检查，要求在区域之间建立连接。

• 当上一个受影响的区域重新联机时，可以通过 冲突源 使用该区域失败时未复制的任何写入数据。 应用程序可以读取冲突源，根据特定于应用程序的逻辑解决冲突，并根据需要将更新后的数据写回 Azure Cosmos DB 容器。

• 在之前受影响的写入区域恢复后，它会在 Azure 门户中显示为“联机”，可用作读取区域。 目前，可以使用 [PowerShell、Azure CLI 或 Azure 门户](/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account 安全地切换回作为写入区域的恢复区域。 在切换写入区域之前、期间或之后，数据或可用性都不会丢失。 应用程序仍然高度可用。

服务中断检测、通知和管理

对于单区域帐户，在 Azure Cosmos DB 区域中断期间，客户端会遇到读写可用性损失的情况。 多区域帐户会经历不同的行为，如下表所述。

高可用性测试

即使 Azure Cosmos DB 帐户高度可用，应用程序也不一定能够正常保持高可用性。 要测试应用程序的端到端高可用性，请在应用程序测试或灾难恢复(DR)演练过程中，暂时禁用帐户的服务托管故障转移。 使用 PowerShell、Azure CLI 或 Azure 门户调用手动故障转移，然后监视应用程序。 完成测试后，可以故障转移到主要区域，并重新启用帐户的服务托管故障转移。

相关内容

• Azure Cosmos DB 中的一致性级别

• Azure Cosmos DB 中的请求单位

• Azure Cosmos DB 全局数据分布 - 揭秘

• Azure Cosmos DB 中的一致性级别

• 在使用 Azure Cosmos DB 的应用程序配置多区域写入

• 诊断多区域环境中 Azure Cosmos DB SDK 的可用性并对其进行故障排除

• Azure 中的可靠性