Azure托管 Redis 提供了多种功能，每个功能可防范不同类型的故障：高可用性、可用性区域分发、数据持久性、活动异地复制以及应用程序级备份和重新生成策略。 这些功能相互补充，而不是互相替代，并且没有一项功能涵盖每个故障方案。 本文可帮助你了解每种功能的用途和失败范围、协同工作方式、适用于层和模块的约束，以及规划恢复点目标（RPO）和恢复时间目标（RTO）时需要回答的问题。
高可用性
高可用性（HA）部署缓存，其中主要分片和副本分片分布在至少两个节点上。 如果某个节点或分片变得不可用，副本分片会自动提升为主分片；除了处理由此导致的连接中断之外，应用程序无须采取任何操作。
- 它防范的内容： 单个缓存部署中的节点、VM 或分片故障，包括计划内维护和修补导致的故障。
- 它无法防范的内容： 可用性区域中断（除非缓存也是区域冗余）、区域范围的中断或数据损坏。 HA 也不会创建可从中还原的任何备份。
- 约束： 可以在现有缓存上启用 HA，但在启用后不能禁用它。 在没有 HA 的情况下运行仅适用于开发和测试方案，因为它会删除对可用性 SLA 的访问，并增加数据丢失和停机的风险。
可用区分布
可用性区域分发（区域冗余）将已启用 HA 的缓存的节点分散到区域中多个物理上独立的可用性区域。 如果某个区域不可用，服务会将流量重定向到剩余正常区域中的节点。
- 它防范的内容： 区域中的数据中心或可用性区域中断。
- 它无法防范的内容： 区域范围的服务中断，或区域之间最近复制周期后写入的数据。
- 约束：区域冗余需要 HA，并且可在支持可用性区域的区域以及Azure托管 Redis 可用的区域中使用。 所有 Azure 托管 Redis 层级在这些区域中都支持该功能。 默认情况下，在部署 HA 缓存时，区域冗余会自动应用，无需执行额外的配置步骤。 应用区域冗余后，无法关闭区域冗余，因为无法撤消缓存上的 HA。
自动冗余模式（预览版）
自动冗余模式允许新的高可用缓存实例在区域冗余部署不可用时使用本地冗余部署。 Azure首先尝试进行可用区冗余部署。 如果该位置不可用，Azure可能会部署具有本地冗余高可用性的缓存。 本地冗余高可用性可防范节点故障，但不受可用性区域故障的影响。
若要启用此行为，请使用门户、Azure CLI或Azure PowerShell注册预览功能。 搜索提供程序命名空间 Microsoft.Cache 和功能名称 AllowAutomaticRedundancyMode。 注册是订阅范围的，并且为订阅中创建的每个新的高可用性缓存启用冗余模式回退行为。 它不会影响现有缓存，并且不能为单个新缓存选择冗余模式。 注册不保证可以部署缓存。
部署后，检查群集资源 properties.redundancyMode 的属性以确定应用了哪个冗余模式。
数据持久性
数据持久性会将缓存数据的快照（RDB）或连续写入日志（AOF）写入托管磁盘。 如果主分片和副本分片都发生故障，则在服务重新联机后，系统会自动根据最近持久化的文件恢复 同一个 缓存实例。
Important
发生意外故障后，数据持久性会自动还原到同一缓存。 它不是数据备份或时间点恢复功能：用户无法访问持久化文件或导入到新的或不同的缓存中，并且写入缓存的损坏数据也会持久保存。 对于可移植备份，请改用 导入和导出 。
- 其防范的问题： 当同一缓存的主分片和副本分片均发生故障时，内存中数据的丢失。
- 它无法防范的情况： 区域级中断、数据损坏或意外删除（因为持久化文件会反映实际写入的任何内容，包括错误写入），以及将系统恢复到较早状态的时间点恢复。
- 约束： 持久性需要 HA。 它在“内存优化”、“均衡”和“计算优化”层上可用，并在“闪存优化”层上以预览版提供。 不能在同一缓存上同时启用持久性和活动异地复制。
主动异地复制
主动异地复制可将分布在不同 Azure 区域的最多五个 Azure Managed Redis 实例连接成一个主动-主动复制组。 每个链接实例都支持读写，并且更改会通过无冲突复制数据类型（CRDT）在所有实例之间双向同步。
- 可防范： 区域性中断。 如果一个区域不可用，应用程序可以继续针对另一个区域中的链接实例运行。
- 它无法防范的内容： 数据损坏、意外删除或实例之间的保证同步时间。 复制最终一致，服务不会在同步时提供 SLA。
-
约束： 要求对每个链接实例使用 HA，并且组中的所有实例必须共享相同的配置，包括 SKU、容量、逐出策略、群集策略、模块和 TLS 设置。 在均衡 B0 和 B1 SKU 或闪存优化层上不支持它。 只有 RediSearch 和 RedisJSON 模块 与活动异地复制一起受支持，RediSearch 还需要企业群集策略和
NoEviction逐出策略。 活动异地复制不能与数据持久性相结合。
应用程序级备份和重新生成策略
通过导入和导出，可以将缓存数据的 RDB 快照保存到Azure Blob 存储，并将该快照还原到相同或不同的缓存实例。 由于 Azure Managed Redis 不包含内置备份调度程序，因此你需要自行构建自动化方案（例如，使用 Azure CLI 或 Azure PowerShell 脚本），以定期导出数据并管理生成的 Blob 的保留期。
- 可防范以下情况：数据损坏、意外删除，以及需要从已知良好的时间点在新的区域或订阅中重新填充缓存数据或重新构建缓存。
- 它无法防范的内容： 实时故障。 导入和导出是手动或脚本化操作，不是自动故障转移机制，在导入期间，客户端无法使用缓存。
- 约束： 在所有层（包括 Flash Optimized）上可用。 大于 2 GB 的单个密钥无法导入。
这些功能如何相互补充
这五项能力针对的是不同但有时会重叠的故障范围。 大多数生产缓存都需要多个缓存，因为没有任何一项功能可以防范每个故障方案：
- 高可用性和可用性区域分发保护单个缓存实例下的基础结构，并由Azure托管 Redis 完全管理。
- 数据持久性 为同一实例中的数据添加持久性，但仅在发生故障后自动恢复同一缓存，而不是作为可移植备份。
- 活动异地复制 通过让应用程序使用另一个实时实例来保护整个区域的丢失，但它要求应用程序检测故障并围绕它进行路由。
- 应用程序级备份和重新生成（导入/导出） 是唯一防止数据损坏、意外删除或需要还原到某个时间点的功能，它是在未启用持久性或异地复制时使用的机制，或者不足以满足恢复要求。
由于持久化和活动异地复制在同一缓存上是互斥的，因此请根据您的主要风险选择相应的方案：如果您主要担心的是区域内某个节点发生故障而导致整个缓存丢失，请使用持久化；如果您主要担心的是整个区域丢失，请使用活动异地复制。 如果需要从数据损坏、意外删除或已知时间点恢复，请计划独立的导入/导出备份过程。
生产默认设置
对于生产环境中的 Azure 托管 Redis 部署：
- 启用 高可用性。 可用性 SLA、区域冗余、持久性和活动异地复制都需要它。
- 部署到支持可用性区域的区域以及Azure托管 Redis 的可用位置，以便在没有额外的配置步骤的情况下自动将区域冗余应用到 HA 缓存。
- 如果主要问题是在节点级故障后自动恢复同一缓存，并且不需要活动异地复制，请添加 数据持久性 。
- 为在区域性中断期间仍必须保持运行的任务关键型工作负载添加主动异地复制，并构建检测发生故障的区域并重定向流量所需的应用程序逻辑。
- 如果在恢复目标内无法重新构造缓存数据，或者需要从数据损坏、意外删除或已知时间点恢复，请生成定期 导入/导出 过程。
层级、SKU 和模块约束
| 能力 | 内存优化，均衡，计算优化 | 闪存优化 |
|---|---|---|
| 高可用性 | 支持;生产所需的 | 支持;生产所需的 |
| 可用区分布 | 在具有可用区且提供 Azure Managed Redis 的区域中受支持 | 支持在具有可用性区域且提供 Azure 托管 Redis 的区域中使用 |
| 数据持久性 | 支持 | 支持（预览） |
| 主动异地复制 | 受支持，但 Balanced B0 和 B1 SKU 除外 | 不支持 |
| 应用程序级备份和重新生成（导入/导出） | 支持 | 支持 |
针对以下额外约束进行规划：
- 不能在同一缓存上启用活动异地复制和数据持久性。
- 活动异地复制要求每个链接实例使用相同的 SKU、容量、逐出策略、群集策略、模块和 TLS 设置。
- 只能将 RediSearch 和 RedisJSON 模块 用于活动异地复制。 RediSearch 还需要企业群集策略和
NoEviction逐出策略，该策略会排除该组合的 OSS 群集策略。
RPO 和 RTO 注意事项
Azure 托管 Redis 不提供有保障的 RPO 或 RTO，且该服务的 SLA 仅涵盖与缓存终结点的连接，不涵盖数据丢失保护。 使用以下记录的典型行为来通知规划;将它们视为设计输入，而不是承诺：
- 计划内故障转移（打补丁、扩缩容和其他管理操作）通常可在一秒内完成。
- 区域中计划外故障转移（未检测到的节点或分片故障）通常在 10 到 15 秒内完成，因为副本必须先确认故障不是暂时性的，然后再升级自身。
- 可用性区域故障：受影响区域中的节点通常在大约 10 到 15 秒内故障转移到正常的区域。 可以丢失尚未复制到另一区域中的分片的任何写入;区域之间的复制延迟通常以秒为单位，但取决于工作负荷。
- 发生活动异地复制的区域故障：停机时间取决于应用程序检测故障和重定向流量的速度，通常从秒到几分钟不等。 在服务中断之前，尚未来得及从发生故障的区域复制出去的写入可能会丢失，而且潜在丢失量会随故障发生时的复制延迟而增加。
- 未启用主动异地复制时的区域故障：没有平台管理的区域故障转移。 恢复时间和恢复点完全取决于您最近一次导出备份是在多久之前，以及您能多快预配一个新实例并将备份导入其中。
若要符合可用性 SLA 的条件，缓存必须使用 HA 配置，并且不得执行记录的临时不可用管理操作。 当缓存配置为区域冗余时，可适用更高可用性 SLA 层级；在某些层级中，当使用主动异地复制将区域冗余实例部署到至少三个区域时，同样可适用更高可用性 SLA 层级。 有关当前的 SLA 条款，请参阅 Azure 托管 Redis SLA。 将本文中的计时和资格详细信息视为规划输入，不保证。
为区域性故障制定预案
Azure 托管 Redis 针对区域性中断有两种不同的处理路径，具体采用哪种路径取决于是否配置了主动异地复制：
- 配置活动异地复制后，应用程序可以将请求重定向到另一区域中的链接实例。 你负责监视复制组的运行状况（例如，使用异地复制正常指标）、决定何时进行故障转移和重定向流量。 在长时间中断期间，如果元数据生成对剩余实例造成内存压力，请考虑强制取消链接受影响的实例。 如果实例保持链接状态，Azure托管 Redis 会在区域恢复时自动重新初始化并重新同步它。 如果强制取消链接，则必须删除受影响的缓存，创建替换，并将替换添加到复制组。
- 如果未配置主动异地复制，则不会自动进行区域故障转移。 数据持久性仅解除同一区域中的同一缓存的冻结，并且持久化文件无法移动到新实例。 若要在此方案中从完全区域中断中恢复，必须在幸存区域中预配新缓存并还原最近的导入/导出备份，因此恢复时间和恢复点取决于备份节奏和预配自动化。
应用程序路由和故障转移责任
Azure 托管 Redis 可在单个缓存内和跨可用区自动进行故障转移：它会检测节点、分片和可用区故障，提升副本节点，并将流量重新路由到运行正常的节点，无需你采取任何操作。 超出该范围后，故障转移由你的应用程序负责：
- 应用程序必须实现重试、退避和断路器模式，以应对任何计划内或计划外的故障转移期间发生的连接中断。 有关详细信息，请参阅 连接复原能力。
- 当区域或区域不正常时，Azure不会自动通知你。 使用Azure 服务运行状况警报和异地复制运行状况指标来检测需要你关注的问题。
- 使用活动异地复制时，应用程序负责选择要用于读取和写入的链接实例、检测失败的区域、将流量重定向到正常实例，并在恢复后重新配置路由回原始区域。
- 如果没有活动异地复制，应用程序（或操作员）负责在发生区域性中断后预配替换缓存和还原导入/导出备份。
决策矩阵
| 能力 | 防止 | 不防范 | 故障转移由 | 典型生产用途 |
|---|---|---|---|---|
| 高可用性 | 节点、VM 或分片故障 | 可用区故障、区域故障、数据损坏 | Azure托管 Redis （自动） | 始终启用 |
| 可用区分布 | 某个区域内的数据中心/可用区中断 | 区域中断，数据损坏 | Azure托管 Redis （自动） | 在具有可用区且 Azure 托管 Redis 可用的区域中，默认启用 HA |
| 数据持久性 | 主节点和副本均发生故障后，该缓存丢失 | 区域中断、数据损坏、时间点恢复 | Azure 托管 Redis（自动恢复） | 当不需要异地复制时使用 |
| 主动异地复制 | 区域范围中断 | 数据损坏，保证同步时序 | 您的应用程序 | 任务关键型跨区域工作负荷 |
| 应用程序级备份和重新生成（导入/导出） | 数据损坏、意外删除、在新实例或区域中重新生成 | 实时故障处理，自动故障转移 | 您的应用程序/自动化 | 需要可移植备份或时间点恢复的工作负荷 |
生产规划清单
- 在每个生产缓存上启用高可用性。
- 部署到同时支持可用区且提供 Azure Managed Redis 的区域，以便自动启用可用区冗余。
- 根据主要风险是节点故障还是区域中断，选择数据持久性或活动异地复制 - 不能将它们组合在一起。
- 对于任务关键型跨区域工作负荷，请配置活动异地复制，并生成检测失败区域和重定向流量所需的应用程序逻辑。
- 在组合使用这些功能之前，请先确认 SKU、层级和模块的兼容性，尤其是在将 RediSearch 与主动异地复制结合使用时（需要采用 Enterprise clustering policy 和
NoEviction策略）。 - 如果无法在恢复目标内重新构造缓存数据，请生成并计划定期导入/导出备份过程，而不考虑持久性或异地复制。
- 实现客户端重试、退避机制和断路器模式，以应对任何故障转移过程中的连接中断。
- 设置监视和警报，包括异地复制正常指标和Azure 服务运行状况警报，以检测区域或区域问题。
- 定期测试应用程序的区域故障转移和备份还原过程，因为两者都是你负责的，而不是平台的。
- 在最终确定业务关键型设计之前，请先查看 Azure 托管 Redis SLA 的资格要求以及 Azure 托管 Redis 可靠性指南。