Azure 托管 Redis 中的可靠性

Azure 托管 Redis 在 Azure 上提供完全集成和管理的 Redis Enterprise，为应用程序提供高性能内存中数据存储。 此服务专为需要超低延迟、高吞吐量和高级数据结构的企业工作负荷构建。

使用 Azure 时， 可靠性是共同的责任。 Microsoft提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。

本文介绍 Azure 托管 Redis 中的可靠性，包括对暂时性故障、可用性区域故障和区域范围的故障的复原能力。 本文还介绍了备份策略和服务级别协议（SLA）。

生产部署建议

为了确保生产 Azure 托管 Redis 实例的高可用性，建议：

• 启用高可用性，为缓存部署多个节点。
• 通过将高度可用的缓存部署到具有可用性区域的区域中来启用区域冗余。
• 对于需要跨区域故障转移的关键业务工作负载，考虑实施主动异地复制。

可靠性体系结构概述

本部分介绍从可靠性的角度来看，服务工作原理最相关的一些重要方面。 本部分介绍逻辑体系结构，其中包括部署和使用的某些资源和功能。 它还讨论了物理架构，该架构提供了服务内部运作方式的详细信息。

逻辑体系结构

Azure 托管 Redis 基于 Redis Enterprise 构建，通过高可用性配置和复制功能提供可靠性。

部署 Azure 托管 Redis 实例，该 实例 也被称为 缓存实例 或 缓存。 客户端应用程序使用 Redis API 在缓存中存储和交互数据。

物理体系结构

规划 Azure 托管 Redis 的复原能力时需要了解两个关键概念：节点和分片。

• 节点： 每个缓存实例都包含 节点，即虚拟机（VM）。 每个 VM 充当群集中的独立计算单元。 你不会直接看到或管理这些 VM。 平台会自动管理实例创建、运行状况监视和替换不正常的实例。 VM 集也称为 群集。

  可以配置实例以实现高可用性。 执行此作时，Azure 托管 Redis 可确保至少有两个节点，并且会自动在节点之间复制数据。 在具有可用性区域的区域中，节点将放置在不同的可用性区域中。 有关详细信息，请参阅 可用性区域故障的复原能力。

  该服务抽象化每个配置中使用的特定节点数，以避免复杂性并确保最佳配置。

• 碎片： 每个节点都运行多个名为 分片的 Redis 服务器进程，这些进程管理缓存数据的子集。 将缓存配置为高可用性时，分片会自动分布并跨节点复制。 指定 群集策略，用于确定分片在节点之间分布的方式。

有关详细信息，请参阅 Azure 托管 Redis 体系结构 和 Azure 托管 Redis 的故障转移和修补。

暂时性故障的复原能力

暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。

与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循 Azure 暂时性故障处理指南。 有关详细信息，请参阅 处理暂时性故障的建议。

使用 Azure 托管 Redis 时，请遵循以下建议来管理暂时性故障：

• 使用 SDK 配置 ，这些配置会在发生暂时性故障时自动重试，并使用适当的退避和超时期限。 请考虑在应用程序中使用 重试模式 和 断路器模式 。
• 设计缓存旁路模式，即使 Redis 暂时不可用，应用程序也可以通过回退到主数据存储来继续运行，只是性能会有所下降。

应对可用区故障的弹性

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

Azure 托管 Redis 缓存实例可以是 区域冗余的，它会自动将缓存节点分布到区域中的多个可用性区域。 区域冗余可降低数据中心或可用性区域中断导致缓存不可用的风险。

若要使缓存区域冗余，必须将缓存区域部署到受支持的区域并启用高可用性配置。 在没有可用性区域的区域中，高可用性配置仍至少创建两个节点，但它们不在单独的区域中。

下图显示了一个区域冗余缓存，其中包含两个节点，每个节点位于单独的区域中：

要求

• 区域支持： 区域冗余的 Azure 托管 Redis 缓存可以部署到支持可用性区域的任何区域以及服务可用的任何区域。 有关支持可用性区域的最新区域列表，请参阅 具有可用性区域的 Azure 区域。 有关支持 Azure 托管 Redis 的区域的列表，请参阅 产品可用性（按区域）。

• 高可用性配置： 必须在缓存上启用高可用性配置，使其成为区域冗余配置。

• 层： 所有 Azure 托管 Redis 层都支持可用性区域。

成本

区域冗余要求你的缓存配置为高可用性，这会为缓存部署至少两个节点。 高可用性配置的计费率高于非高可用性配置。 有关详细信息，请参阅 Azure 托管 Redis 定价

配置可用性区域支持

• 创建新的区域冗余实例： 创建新的 Azure 托管 Redis 实例时，启用高可用性配置并将其部署到具有可用性区域的区域中。 然后，它默认自动包含区域冗余。 无需再执行任何配置。

  有关详细步骤，请参阅 快速入门：创建 Azure 托管 Redis 实例。

• 在现有实例上启用区域冗余： 若要将现有 Azure 托管 Redis 实例配置为区域冗余，请确保它部署在支持可用性区域的区域中，并在缓存上启用高可用性。

• 禁用区域冗余： 无法在现有实例上禁用区域冗余，因为在缓存实例上启用高可用性后，无法禁用高可用性。

容量计划和管理

在区域故障事件期间，你的实例可能拥有更少的可用资源来处理工作负载。 如果实例经常面临资源压力，并且需要为可用性区域故障做好准备，请考虑以下方法之一：

• 过度配置实例： 过度配置是指选择比实际需求更高的性能等级。 它允许实例容忍某些容量丢失并继续正常运行，而不会降低性能。 有关过度预配原则的详细信息，请参阅 通过过度预配管理容量。 若要了解如何缩放实例，请参阅 缩放 Azure 托管 Redis 实例。

• 使用活动异地复制： 可以在不同的区域中部署多个实例，并配置 活动异地复制 ，以跨这些单独的实例分散负载。

所有区域正常时的行为

本部分介绍当托管的 Redis 缓存系统具有区域冗余且所有可用性区域均正常运行时可以预期的情况：

• 区域间的流量路由：分片根据你的群集策略跨节点分布。 群集策略还确定如何将流量路由到每个节点。 区域冗余不会更改流量的路由方式。

• 区域之间的数据复制： 分片自动跨节点复制，并使用异步复制。 通常，分片之间的复制滞后时间以秒为单位，但根据缓存的工作负荷，可能会有所不同，写入密集型和网络密集型方案通常会看到更高的复制滞后时间。

区域故障期间的行为

本部分介绍托管 Redis 缓存区域冗余且一个或多个可用性区域不可用时会发生什么情况：

• 检测和响应： Azure 托管 Redis 负责检测可用性区域中的故障。 无需执行任何操作即可启动区域故障转移。

• 通知：当区域关闭时，Microsoft不会自动通知你。 但是，可以使用 Azure 服务运行状况 来了解服务的总体运行状况，包括任何区域故障，并且可以设置 服务运行状况警报 来通知问题。

• 活动请求：正在处理的请求可能会被丢弃，应进行重试。 应用程序应 实现重试逻辑 来处理这些临时中断。

• 预期数据丢失： 未复制到另一个区域中的分片的任何数据可能会在区域故障期间丢失。 通常，数据丢失量以秒为单位，但这取决于复制滞后时间。

• 预期的停机时间： 在分片切换到正常区域节点时，可能会发生少量的停机时间（通常为 10-15 秒）。 有关计划外故障转移过程的信息，请参阅设计应用程序时 故障转移的说明 ，遵循 暂时性故障处理的做法。

• 流量重新路由： Azure 托管 Redis 会自动将流量重定向到正常区域中的节点。

区域恢复

当受影响的可用性区域恢复时，Azure 托管 Redis 会自动恢复该区域的操作。 Azure 平台完全管理此过程，不需要任何客户干预。

针对局部区域故障进行测试

由于 Azure 托管 Redis 会全权管理区域故障的流量路由、故障转移和故障恢复，你无需验证可用性区域故障流程或提供任何进一步输入。

对区域范围的故障的复原能力

Azure 托管 Redis 通过主动地理复制提供原生多区域支持，使你可以将多个分布在不同 Azure 区域的 Azure 托管 Redis 实例关联到一个复制组。 之后，你可以在实例之间配置自己的故障转移方式。

主动地理复制

使用 活动异地复制时，应用程序可以在组中读取和写入任何缓存实例，更改会自动在所有区域中同步。 该服务支持双活复制模式，其中每个地区可以同时处理读取和写入操作。 当由于不同区域中的并发写入而发生冲突时，服务会使用预先确定的冲突解决算法自动解决冲突，而无需手动干预。 此方法为区域故障提供复原能力，同时保持全球分布式应用程序的低延迟访问。

下图显示了同一活动异地复制组中不同区域中的两个缓存实例，以及连接到每个缓存实例的客户端应用程序：

你负责配置客户端应用程序，以便，如果任何区域实例失败，他们可以将其请求重定向到正常的实例。 下图显示了应用程序在通常使用失败的实例时如何将请求重定向到正常的缓存实例：

要求

• 区域支持 可以在服务可用的任何 Azure 区域之间配置 Azure 托管 Redis 活动异地复制。

• 实例配置： 活动异地复制需要跨所有参与区域具有相同层和大小的 Azure 托管 Redis 实例。 复制组中的所有缓存实例都必须配置相同的设置，包括持久性选项、模块和群集策略。

• 其他要求： 缓存实例必须满足其他要求，包括使用的模块，并且会影响缓存实例的缩放方式。 有关详细信息，请参阅 活动异地复制先决条件。

注意事项

• 故障转移责任： 当你使用活动异地复制时，你负责缓存实例之间的故障转移。 你应准备并配置应用程序以处理故障转移。 故障转移涉及准备工作，可能需要你完成多个步骤。 有关详细信息，请参阅 发生区域中断时强制取消链接。

• 最终一致性： 应用程序应设计为处理最终一致性方案，因为根据网络条件和地理距离，更改可能需要时间跨所有区域传播。 在区域中断期间，在恢复连接并同步完成之前，可能会遇到更多数据不一致的情况。

成本

启用活动异地复制时，系统会为复制组内每个区域中的每个 Azure 托管 Redis 实例付费。 此外，在区域之间进行跨区域复制流量时，您可能会产生数据传输费用。 有关定价的详细信息，请参阅 Azure 托管 Redis 定价 和 带宽定价详细信息。

配置多区域支持

• 创建新的异地复制缓存实例：通过在缓存预配期间配置活动异地复制，方法是指定复制组并链接多个实例。 有关详细信息，请参阅 创建或加入活动异地复制组。

• 为异地复制启用现有缓存实例：可以将现有缓存实例添加到活动异地复制组。

  但是，将现有实例添加到活动异地复制组时，需要刷新实例中的数据，并且停机时间很小。 如果可能，请计划在创建缓存实例时启用活动异地复制。

  有关详细信息，请参阅 将现有实例添加到活动异地复制组。

• 在缓存实例上禁用异地复制：通过删除缓存实例从异地复制组中删除实例。 其余实例会自动重新配置自身。

容量计划和管理

在区域故障事件期间，其他实例可能会面临更大压力。 如果一个实例经常已经面临较大的资源负荷压力，并且需要为区域故障期间增加的容量需求做好准备，请考虑对实例进行冗余预配。 若要了解如何缩放实例，请参阅 缩放 Azure 托管 Redis 实例。

当所有区域都正常时的行为

本部分介绍当实例配置为使用活动异地复制且所有区域都正常运行时会发生什么情况。

• 区域之间的流量路由：负责配置应用程序以连接到特定缓存实例。 应用程序可以连接到复制组中的任何缓存实例，并同时执行读取和写入作。 流量路由由应用程序处理，使你能够将客户端定向到最近的区域，以尽量减少延迟。 Azure 托管 Redis 不提供区域之间的自动流量路由。

• 区域之间的数据复制：服务使用区域之间的异步复制来保持最终一致性。 写入操作会立即在本地区域提交，然后在后台传播到其他区域。 无冲突复制数据类型（CRDT）可确保自动合并不同区域中的并发写入。

区域故障期间的行为

本部分介绍当实例配置为使用主动地理复制功能且一个区域出现故障时会发生什么情况：

• 检测和响应：您负责检测缓存实例的故障，并确定何时进行切换。 你可以监视异地复制群集的运行状况，这有助于你决定何时启动故障转移。 有关详细信息，请参阅 异地复制指标。

  故障转移需要你执行多个步骤。 有关更多详细信息，请参阅区域中断时的强制取消链接。

• 通知： Microsoft不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 来了解服务的总体运行状况，包括任何区域故障，并且可以设置 服务运行状况警报 来通知问题。

  还可以监视每个实例的健康状态。

  若要监视异地复制关系的运行状况，可以使用 异地复制正常 指标。 指标始终具有 1 值（正常）或 0 （不正常）。 可以对此指标配置 Azure Monitor 警报，以了解实例何时可能不同步。

• 活动请求：对失败区域的请求将终止，必须由应用程序的故障转移逻辑处理。 应用程序应实现可将流量重定向到正常缓存的重试策略。

• 预期数据丢失：由于区域之间的异步复制，如果尚未复制到其他区域，则对失败区域的一些最近写入可能会丢失。 潜在的数据丢失量取决于失败时的复制滞后时间。 有关更多信息，请参阅活动-活动异地分布式 Redis 以及 CRDB 区域故障中的一致性和数据丢失注意事项。

• 预期停机时间：应用程序仅在检测到故障和将流量重定向到正常区域所需的持续时间内才会停机。 这通常从秒到几分钟不等，具体取决于配置应用程序的运行状况检查和故障转移配置的方式。

• 重新路由流量：负责在应用程序中实现逻辑，以检测区域故障并将流量路由到正常区域。 这可以通过运行状况检查、断路器模式或外部负载均衡解决方案来实现。

区域恢复

在发生故障的区域恢复时，Azure 托管 Redis 会自动将该区域中的实例重新集成到活动异地复制组中，而无需干预。 该服务会自动将数据从健康的实例同步过来。 在此过程中，恢复的实例会逐渐赶上中断期间发生的更改。 同步完成后，恢复的实例将完全处于活动状态，并且可以处理读取和写入作。

你负责重新配置应用程序，以将流量路由回恢复的区域实例。

针对区域故障进行测试

应定期测试您的应用程序的故障转移程序。 你的应用程序能够在实例之间进行故障转移，并且在此过程中满足业务对停机时间的要求，这一点至关重要。 此外，还必须测试整个响应过程，包括防火墙和其他基础结构的任何重新配置，以及恢复过程。

服务维护期间的系统弹性能力

Azure 托管 Redis 执行常规服务升级和其他维护任务。

进行维护时，Azure 托管 Redis 会自动创建新节点并自动执行故障转移。 客户端应用程序可能会看到连接中断和其他暂时性故障。 应用程序应 实现重试逻辑 来处理这些临时中断。

若要详细了解 Azure 托管 Redis 的维护过程，请参阅 Azure 托管 Redis 的故障转移和修补。

备份和还原

Azure 托管 Redis 提供数据持久性和备份功能，以防止其他可靠性功能无法解决的数据丢失方案。 备份可以针对数据损坏、意外删除或配置错误等方案提供保护。

• 数据持久性： 默认情况下，Azure 托管 Redis 将所有缓存数据存储在内存中。 它可以选择使用 数据持久性将数据的快照写入磁盘。 如果存在影响节点的硬件故障，Azure 托管 Redis 会自动还原数据。 可以选择不同类型的数据持久性，在快照频率与缓存的性能影响之间提供不同的权衡。

  但是，数据文件无法还原到另一个实例，并且无法访问这些文件。 数据持久性不会防止数据损坏或意外删除。

• 导入和导出： Azure 托管 Redis 支持使用 导入和导出功能备份数据，该功能可将备份文件保存到 Azure Blob 存储。 可以在 Azure 存储帐户上配置异地冗余存储，也可以将备份 Blob 复制或移动到其他位置，以便进一步保护。

  导出的文件可以还原到同一缓存实例或不同的缓存实例。

  没有内置的导入或导出计划程序，但你可以开发自己的自动化过程，使用 Azure CLI 或 Azure PowerShell 启动导出作。

服务级别协议

Azure 服务的服务级别协议(SLA)描述了每个服务的预期可用性，以及解决方案为实现该可用性预期而必须满足的条件。 有关详细信息，请参阅 联机服务的 SLA。

Azure 托管 Redis 的 SLA 涵盖与缓存终结点的连接。 SLA 不涉及对数据丢失的防护。

为获得 Azure 托管 Redis 的可用性 SLA 资格，

• 必须启用高可用性配置。
• 不得启动任何已记录会导致临时不可用的产品功能或管理操作。

当您的实例是区域冗余的时，将应用更高可用性的 SLA。 在某些层中，如果已使用活动异地复制将区域冗余实例部署到至少三个区域，则可以有资格获得更高的可用性 SLA。