高可用性和灾难恢复
与任何云系统一样，可能会发生计划外中断，导致虚拟机 (VM) 实例、可用性区域或者整个 Azure 区域的故障。 我们建议客户制定计划来处理区域或地区性中断。
本文向客户提供了为 Azure Cache for Redis 创建业务连续性和灾难恢复计划所需的信息。
“标准”和“高级”层级中提供了各种高可用性选项：
| 选项 | 说明 | 可用性 | 标准 | 高级 |
|---|---|---|---|---|
| 标准复制 | 单个数据中心中具有自动故障转移功能的双节点复制配置 | 99.9%（查看详细信息） | 是 | 是 |
| 区域冗余 | 可用性区域中具有自动故障转移功能的多节点复制配置 | 在高级层级中为 99.9%；（请参阅详细信息） | 是（预览版） | 是 |
| 异地复制 | 两个区域中的链接缓存实例，具有用户控制的故障转移 | 高级层；（请参阅详细信息） | 否 | 被动 |
| 导入/导出 | 缓存中数据的时间点快照。 | 99.9%（查看详细信息） | 否 | 是 |
| 持久性 | 定期将数据保存到存储帐户。 | 99.9%（查看详细信息） | 否 | 是 |
用于高可用性的标准复制
适用层：标准、高级
建议用于：高可用性
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 实例仍可能会受到数据中心或可用性区域服务中断的严重影响。 可使用多个具有区域冗余的副本来提高缓存可用性。
区域冗余
适用层级：标准层（预览版）、高级层
建议用于：高可用性、灾难恢复 - 区域内
Azure Cache for Redis 支持标准层（预览版）和高级层中的区域冗余配置。 区域冗余缓存可以将其节点置于同一区域中的不同Azure 可用性区域上。 这消除了数据中心或可用性区域中断造成的单一故障点，并提高了缓存的总体可用性。
注意
在高级版缓存中，只有“自动区域分配”处于公共预览状态。 手动选择可用性区域不变。 手动选择是正式版 (GA)。
如果一个缓存被配置为使用本文前面所述的两个或更多个区域，缓存节点将在不同的区域中创建。 当一个区域发生故障时，其他区域中的缓存节点可以用来保持缓存的正常运行。
重要
现在可以为适用层级和区域中的所有缓存启用“自动区域分配”。 有关详细信息，请参阅为 Azure Cache for Redis 启用区域冗余。
高级层
下图说明了“高级”层级的区域冗余配置：
Azure Cache for Redis 在所选的可用性区域上将节点以循环方式分布在区域冗余缓存中。 它还确定最初用作主节点的节点。
Premium 层的区域故障体验
区域冗余缓存提供自动故障转移。 若当前主节点不可用，则由其中一个副本接管。 如果新的主节点位于不同的 AZ，则应用程序可能会遇到更长的缓存响应时间。 可用性区域在地理位置上是分开的。 从一个 AZ 切换到另一 AZ 会改变应用程序和缓存的托管位置之间的物理距离。 此更改会影响应用程序到缓存的往返网络延迟。 额外的延迟应在大多数应用程序的可接受范围内。 建议对应用程序进行测试，确保它可以正常使用区域冗余缓存。
区域可用性
区域冗余 Premium 层缓存在以下区域中可用：
| 美洲 | 欧洲 | 中东 | 非洲 | 亚太区 |
|---|---|---|---|---|
| 巴西南部 | 法国中部 | 卡塔尔中部 | 南非北部 | 澳大利亚东部 |
| 加拿大中部 | 德国中西部 | 印度中部 | ||
| 美国中部 | 北欧 | 日本东部 | ||
| 美国东部 | 挪威东部 | 韩国中部 | ||
| 美国东部 2 | 英国南部 | 东南亚 | ||
| 美国中南部 | 西欧 | 东亚 | ||
| US Gov 弗吉尼亚州 | 瑞典中部 | 中国北部 3 | ||
| 美国西部 2 | 瑞士北部 | |||
| 美国西部 3 | 波兰中部 |
可用性区域重新部署和迁移
目前，将缓存从非 AZ 配置转换为 AZ 配置的唯一方法是重新部署缓存。
持久性
适用的层：高级
建议用于：数据持续性
由于缓存数据是存储在内存中的，因此，如果多个节点出现罕见的计划外故障，会导致所有数据被删除。 为了避免数据完全丢失，Redis 持久性允许定期创建内存中数据的快照，并将其存储到存储帐户。 如果在多个节点中发生故障，导致数据丢失，缓存会从存储帐户加载快照。 有关详细信息，请参阅为 Azure Cache for Redis 高级实例配置数据持久性。
用于持久性的存储帐户
请考虑选择异地冗余存储帐户，以确保持久化数据的高可用性。 有关详细信息，请参阅 Azure 存储冗余。
导入/导出
适用的层：高级
建议用于：灾难恢复
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 实例配置异地复制。
如果托管主缓存的区域出现故障，你将需要启动故障转移：首先取消链接辅助缓存，然后更新应用程序以指向辅助缓存进行读取和写入。
删除并重新创建缓存
适用层：标准、高级
如果遇到区域性服务中断，请考虑在其他区域中重新创建缓存，并更新应用程序，改为连接到新缓存。 必须记住，在区域性服务中断期间，数据会丢失。 在发生数据丢失时，你的应用程序代码应具备可复原性。
还原受影响的区域后，不可用的 Azure Cache for Redis 会自动还原并再次可供使用。 有关将缓存移到其他区域的更多策略，请参阅将 Azure Cache for Redis 实例移到其他区域。
后续步骤
详细了解如何配置 Azure Cache for Redis 高可用性选项。