你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
高可用性和灾难恢复
与任何云系统一样，可能会发生计划外中断，导致虚拟机 (VM) 实例、可用性区域或者整个 Azure 区域的故障。 我们建议客户制定计划来处理区域或地区性中断。
本文向客户提供了为 Azure Cache for Redis 或 Azure Cache for Redis Enterprise 实现创建业务连续性和灾难恢复计划所需的信息。
“标准”、“高级”和“企业”层级中提供了各种高可用性选项：
| 选项 | 说明 | 可用性 | 标准 | 高级 | Enterprise |
|---|---|---|---|---|---|
| 标准复制 | 单个数据中心中具有自动故障转移功能的双节点复制配置 | 99.9%（查看详细信息） | 是 | 是 | 是 |
| 区域冗余 | 可用性区域中具有自动故障转移功能的多节点复制配置 | 高级版，99.9%；Enterprise，99.99%（查看详细信息） | 是 | 是 | 是 |
| 异地复制 | 两个区域中的链接缓存实例，具有用户控制的故障转移 | 高级版；Enterprise（查看详细信息） | 否 | 被动 | 活动 |
| 导入/导出 | 缓存中数据的时间点快照。 | 99.9%（查看详细信息） | 否 | 是 | 是 |
| 持久性 | 定期将数据保存到存储帐户。 | 99.9%（查看详细信息） | 否 | 是 | 预览 |
用于高可用性的标准复制
适用的层：标准、高级、Enterprise、Enterprise Flash
建议用于：高可用性
Azure Cache for Redis 具有高可用性体系结构，确保即使发生影响基础虚拟机 (VM) 的中断，也可以使托管实例正常运行。 无论是计划内中断还是计划外中断，Azure Cache for Redis 都能提供比在单个 VM 上托管 Redis 时能够实现的百分比可用率更大的百分比可用率。
默认情况下，在适用层级中，Azure Cache for Redis 在一对 Redis 服务器上运行。 这两个服务器托管在专用 VM 上。 开源 Redis 只允许一台服务器处理数据写入请求。
使用 Azure Cache for Redis 时，一个服务器是主节点，另一个服务器是副本。 预配服务器节点后，Azure Cache for Redis 可向其分配主要角色和副本角色。 主节点通常负责为来自客户端的写入和读取请求提供服务。 在执行写入操作时，它会向其内部内存提交一个新密钥和密钥更新，并立即回复客户端。 它以异步方式将操作转发给副本。
注意
通常，Azure Cache for Redis 客户端应用程序与缓存中的主节点通信，以获取所有读取和写入请求。 某些客户端可以配置为从副本节点进行读取。
如果缓存中的主节点不可用，副本会自动将自己提升为新的主节点。 此过程称为故障转移。 故障转移就是两个节点（主/副本）在转换角色（副本/主），其中一个节点可能会脱机几分钟。 在大多数故障转移中，主节点和副本节点会协调交接，没有主节点的时间几乎为零。
前主节点会短暂脱机，以便从新主节点接收更新。 然后，现在的副本节点会重新联机，并重新联接已完全同步的缓存。 关键是节点不可用是暂时的，节点会重新联机。
当主节点需要关闭以进行维护时，典型的故障转移顺序如下所示：
- 主节点和副本节点协商出一个协调的故障转移并互换角色。
- 副本节点（以前的主节点）脱机进行重启。
- 几秒钟或几分钟后，副本节点重新联机。
- 副本节点从主节点同步数据。
主节点在计划内维护活动（例如 Redis 软件或操作系统更新）期间可能会停止服务。 它还可能因为计划外事件（例如底层硬件、软件或网络故障）而停止工作。 Azure Cache for Redis 的故障转移和修补提供了有关故障转移类型的详细说明。 Azure Cache for Redis 在其生存期内会经历许多故障转移。 高可用性体系结构的设计能使缓存中的这些更改对其客户端尽可能透明。
此外，Azure Cache for Redis 在高级层中提供更多副本节点。 可以为多副本缓存配置最多三个副本节点。 具有更多副本通常可提高复原能力，因为你的节点会为主节点提供备份。 即使有多个副本，Azure Cache for Redis 实例仍可能会受到数据中心或可用性区域服务中断的严重影响。 可使用多个具有区域冗余的副本来提高缓存可用性。
区域冗余
适用的层：标准、高级、Enterprise、Enterprise Flash
建议用于：高可用性、灾难恢复 - 区域内
Azure Cache for Redis 在“标准”、“高级”和“企业”层中支持区域冗余配置。 区域冗余缓存可以将其节点置于同一区域中的不同Azure 可用性区域上。 这消除了数据中心或可用性区域中断造成的单一故障点，并提高了缓存的总体可用性。
如果一个缓存被配置为使用本文前面所述的两个或更多个区域，缓存节点将在不同的区域中创建。 当一个区域发生故障时，其他区域中的缓存节点可以用来保持缓存的正常运行。
重要
对于标准层和高级层，Azure Cache for Redis 默认使用 Automatic_Zonal_Allocation 在支持区域的地区中创建具有区域冗余的缓存。 有关详细信息，请参阅为 Azure Cache for Redis 启用区域冗余。
高级层
下图说明了“高级”层级的区域冗余配置：
Azure Cache for Redis 在所选的可用性区域上将节点以循环方式分布在区域冗余缓存中。 它还确定最初用作主节点的节点。
Premium 层的区域故障体验
区域冗余缓存提供自动故障转移。 若当前主节点不可用，则由其中一个副本接管。 如果新的主节点位于不同的 AZ，则应用程序可能会遇到更长的缓存响应时间。 可用性区域在地理位置上是分开的。 从一个 AZ 切换到另一 AZ 会改变应用程序和缓存的托管位置之间的物理距离。 此更改会影响应用程序到缓存的往返网络延迟。 额外的延迟应在大多数应用程序的可接受范围内。 建议对应用程序进行测试，确保它可以正常使用区域冗余缓存。
Enterprise 和 Enterprise Flash 层级
在任一“Enterprise”层中，缓存都在 Redis Enterprise 群集上运行。 它总是需要保持奇数个服务器节点才能形成仲裁。 默认情况下，它有三个节点，每个节点都托管在专用 VM 上。
- Enterprise 缓存有两个大小相同的数据节点和一个较小的仲裁节点 。
- Enterprise Flash 缓存有三个大小相同的数据节点。
Enterprise 群集在内部将 Azure Cache for Redis 数据划分为多个分区。 每个分区有一个主分区和至少一个副本 。 每个数据节点都包含一个或多个分区。 Enterprise 群集可确保任何分区的主分区和副本永远不会并置在同一数据节点上。 分区将数据从主分区异步复制到其相应的副本。
Enterprise 层的区域故障体验
当数据节点不可用或发生网络拆分时，会发生类似于标准复制中描述的故障转移。 Enterprise 群集使用基于仲裁的模型来确定哪些未受影响的节点将参与新的仲裁。 它还根据需要将这些节点中的分区副本提升为主分区。
区域可用性
区域冗余高级、标准层缓存在以下区域中可用：
| 美洲 | 欧洲 | 中东 | 非洲 | 亚太区 |
|---|---|---|---|---|
| 巴西南部 | 法国中部 | 卡塔尔中部 | 南非北部 | 澳大利亚东部 |
| 加拿大中部 | 意大利北部 | 阿拉伯联合酋长国北部 | 印度中部 | |
| 美国中部 | 德国中西部 | 以色列中部 | 日本东部 | |
| 美国东部 | 挪威东部 | |||
| 美国东部 2 | 北欧 | 东南亚 | ||
| 美国中南部 | 英国南部 | 东亚 | ||
| US Gov 弗吉尼亚州 | 西欧 | 中国北部 3 | ||
| 美国西部 2 | 瑞典中部 | 韩国中部 | ||
| 美国西部 3 | 瑞士北部 | 新西兰北部 | ||
| 墨西哥中部 | 波兰中部 | |||
| 西班牙中部 |
区域冗余 Enterprise 和 Enterprise Flash 层缓存在以下区域中可用：
| 美洲 | 欧洲 | 中东 | 非洲 | 亚太区 |
|---|---|---|---|---|
| 加拿大中部* | 北欧 | 澳大利亚东部 | ||
| 美国中部* | 英国南部 | 印度中部 | ||
| 美国东部 | 西欧 | 东南亚 | ||
| 美国东部 2 | 日本东部* | |||
| 美国中南部 | 东亚* | |||
| 美国西部 2 | ||||
| 美国西部 3 | ||||
| 巴西南部 |
* Enterprise Flash 层在此区域中不可用。
可用性区域重新部署和迁移
目前，将缓存从非 AZ 配置转换为 AZ 配置的唯一方法是重新部署缓存。 若要了解如何重新部署当前缓存，请参阅将 Azure Cache for Redis 实例迁移到可用性区域支持。
持久性
适用的层：高级、Enterprise（预览版）、Enterprise Flash（预览版）
建议用于：数据持续性
由于缓存数据是存储在内存中的，因此，如果多个节点出现罕见的计划外故障，会导致所有数据被删除。 为了避免数据完全丢失，Redis 持久性允许定期创建内存中数据的快照，并将其存储到存储帐户。 如果在多个节点中发生故障，导致数据丢失，缓存会从存储帐户加载快照。 有关详细信息，请参阅为 Azure Cache for Redis 高级实例配置数据持久性。
用于持久性的存储帐户
请考虑选择异地冗余存储帐户，以确保持久化数据的高可用性。 有关详细信息，请参阅 Azure 存储冗余。
导入/导出
适用的层：高级、Enterprise、Enterprise Flash
建议用于：灾难恢复
Azure Cache for Redis 支持导入和导出 Redis 数据库 (RDB) 文件的选项，以提供数据可移植性。 这让你可以将数据导入 Azure Cache for Redis，或者使用 RDB 快照将数据从 Azure Cache for Redis 导出。 高级缓存中的 RDB 快照将导出到 Azure 存储帐户中的 blob。 可以创建脚本来定期触发将数据导出到存储帐户。 有关详细信息，请参阅在 Azure Cache for Redis 中导入和导出数据。
用于导出的存储帐户
请考虑选择异地冗余存储帐户，以确保导出数据的高可用性。 有关详细信息，请参阅 Azure 存储冗余。
被动异地复制
适用的层：高级
建议用于：灾难恢复 - 单一区域
异地复制是用于链接两个或以上 Azure Cache for Redis 实例的机制，这两个实例通常跨越两个 Azure 区域。 异地复制主要是为跨区域灾难恢复设计的。 两个“高级”层缓存实例通过异地复制进行连接，这种连接方式提供对主缓存的读取和写入，并且该数据将被复制到辅助缓存。
有关如何对其进行设置的详细信息，请参阅为“高级”Azure Cache for Redis 实例配置异地复制。
如果托管主缓存的区域出现故障，你将需要启动故障转移：首先取消链接辅助缓存，然后更新应用程序以指向辅助缓存进行读取和写入。
活动异地复制
适用的层：Enterprise、Enterprise Flash
建议用于：高可用性、灾难恢复 - 多区域
Enterprise 层支持一种更高级的异地复制形式（称为 主动异地复制），可在多个区域之间提供更高的可用性和跨区域灾难恢复。 Azure Cache for Redis Enterprise 软件使用无冲突复制数据类型来支持对多个缓存实例的写入、合并更改以及解决冲突。 可以在不同的 Azure 区域中最多联接五个“Enterprise”层缓存实例，形成一个异地复制组。
使用此类缓存的应用程序可以通过相应的终结点来读取和写入任何地理位置分散的缓存实例。 应用程序应使用距离每个应用程序实例最近的缓存实例，以实现最低的延迟。 有关详细信息，请参阅为 Azure Cache for Redis Enterprise 实例配置活动异地复制。
如果复制组中其中一个缓存的区域出现故障，应用程序需要切换到另一个可用的区域。
当复制组中的缓存不可用时，建议监视同一复制组中其他缓存的内存使用情况。 当其中一个缓存出现故障时，复制组中的所有其他缓存将开始保存它们无法与出现故障的缓存共享的元数据。 如果可用缓存的内存使用率在其中一个缓存出现故障后开始高速增长，请考虑取消链接复制组中不可用的缓存。
有关强制取消链接的详细信息，请参阅发生区域中断时强制取消链接。
删除并重新创建缓存
适用的层：标准、高级、Enterprise、Enterprise Flash
如果遇到区域性服务中断，请考虑在其他区域中重新创建缓存，并更新应用程序，改为连接到新缓存。 必须记住，在区域性服务中断期间，数据会丢失。 在发生数据丢失时，你的应用程序代码应具备可复原性。
还原受影响的区域后，不可用的 Azure Cache for Redis 会自动还原并再次可供使用。 有关将缓存移到其他区域的更多策略，请参阅将 Azure Cache for Redis 实例移到其他区域。
后续步骤
详细了解如何配置 Azure Cache for Redis 高可用性选项。