你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 托管 Redis 的故障转移和修补（预览版）
要构建可复原且成功的客户端应用程序，了解 Azure 托管 Redis（预览版）服务中的故障转移至关重要。 故障转移可能是计划的管理操作中的一部分，也可能由意外硬件或网络故障引发。 当管理服务修补 Azure 托管 Redis 二进制文件时，往往会使用缓存故障转移。
在本文中，你将找到以下信息：
- 什么是故障转移？
- 在修补期间如何进行故障转移。
- 如何构建可复原的客户端应用程序。
什么是故障转移？
让我们从 Azure 托管 Redis 故障转移的概述开始。
缓存体系结构的快速摘要
缓存由具有单独的专用 IP 地址的多个虚拟机构成。 每个虚拟机（或“节点”）并行运行多个 Redis 服务器进程（称为“分片”）。 多个分片可让系统可更高效地利用每个虚拟机上的 vCPU 并提高性能。 并非所有主要 Redis 分片都位于同一 VM/节点上。 相反，主分片和副本分片分布在这两种节点之间。 由于主分片使用的 CPU 资源比副本分片多，此方法使得更多的主分片可以并行运行。 每个节点都有一个高性能代理进程来管理分片、处理连接管理并触发自我修复。 一个分片可处于关闭状态，其他节点仍保持可用。
可在此处找到 Azure 托管 Redis 体系结构的深入详细信息。
故障转移的说明
当一个或多个副本分片自行提升为主分片，且原有主分片关闭现有连接时，会发生故障转移。 故障转移可以是计划性的，也可以是非计划的。
计划的故障转移发生在两个不同的时间：
- 系统更新，例如 Redis 修补或 OS 升级。
- 管理操作，例如缩放和重新启动。
由于节点会提前收到更新通知，因此它们可以协作交换角色，并在更改后快速更新负载均衡器。 计划性故障转移通常可在 1 秒内完成。
发生非计划性故障转移的可能原因是硬件故障、网络故障或群集中一个或多个节点的其他意外中断。 剩余节点上的副本分片将自行提升为主副本，以保持可用性，但此过程需要更长的时间。 副本分片必须先检测到其主分片不可用，然后才能启动故障转移过程。 副本分片还必须验证此非计划性故障不是暂时性的或局部性的，以避免不必要的故障转移。 检测时出现的这种延迟意味着非计划性故障转移通常要在 10 到 15 秒内完成。
修补是如何进行的？
Azure 托管 Redis 服务定期使用最新的平台功能和修补程序更新缓存。 该服务遵循以下步骤来修补缓存：
- 该服务会创建最新 VM，以替换正在修补的所有 VM。
- 然后，该服务会将其中一个新 VM 提升为群集领导者。
- 所有要修补的节点都会逐个从群集中删除。 这些 VM 上的任何分片都将降级并迁移到新 VM 之一。
- 最后，系统将删除已替换的所有 VM。
群集缓存的每个分片单独进行修补，不会关闭与另一个分片的连接。
同一资源组和区域中的多个缓存也是每次修补一个。 不同资源组或区域中的缓存可以同时修补。
由于完整数据同步在进程重复之前发生，缓存不太可能发生数据丢失。 可以使用导出数据功能并启用持久性来进一步防止数据丢失。
额外的缓存负载
每当发生故障转移时，缓存都需要将数据从一个节点复制到另一个节点。 这种复制会导致负载消耗的服务器内存和 CPU 增大。 如果缓存实例的负载已很繁重，客户端应用程序遇到的延迟可能会增大。 在极端情况下，客户端应用程序可能会收到超时异常。
故障转移如何影响我的客户端应用程序？
客户端应用程序可能会从其 Azure 托管 Redis 收到一些错误。 客户端应用程序遇到的错误数目取决于故障转移时该连接上挂起的操作数目。 通过已关闭其连接的节点路由的任何连接都将遇到错误。
在连接中断时，许多客户端库可能会引发不同类型的错误，包括：
- 超时异常
- 连接异常
- 套接字异常
异常的数目和类型取决于当缓存关闭其连接时，请求在代码路径中所处的位置。 例如，在发生故障转移时发送了请求但未收到响应的操作可能会收到超时异常。 对关闭的连接对象发出的新请求将收到连接异常，直到重新连接成功为止。
大多数客户端库会尝试重新连接到缓存（如果采用此配置）。 但是，不可预测的 bug 偶尔会将库对象置于不可恢复状态。 如果出错的持续时间超过了预先配置的时间，则应重新创建连接对象。 在 Microsoft.NET 及其他面向对象的语言中，可以通过使用 ForceReconnect 模式在不重启应用程序的情况下重新创建连接。
维护中包括哪些更新？
维护包括以下更新：
- Redis 服务器更新：Redis 服务器二进制文件的任何更新或修补程序。
- 虚拟机 (VM) 更新：托管 Redis 服务的虚拟机的任何更新。 VM 更新包括修补托管环境中的软件组件以升级网络组件或解除授权。
维护是否在修补之前显示在 Azure 门户中的服务运行状况中？
否，维护不会显示在门户的服务运行状况下或其他任何位置。
客户端网络配置更改
某些客户端网络配置更改可能会触发“无可用连接”错误。 此类更改可能包括：
- 在过渡槽与生产槽之间交换客户端应用程序的虚拟 IP 地址。
- 缩放应用程序实例的大小或数量。
此类更改可能会导致通常持续一分钟以下的连接问题。 客户端应用程序可能会断开与其他外部网络资源的连接，同时也会断开与 Azure 托管 Redis 服务的连接。
内置的复原能力
无法完全避免故障转移。 应该合理编写客户端应用程序，使之能够弹性应对连接中断和请求失败的问题。 大多数客户端库可以自动重新连接到缓存终结点，但有少量的客户端库会重试失败的请求。 根据具体的应用方案，使用支持退让的重试逻辑可能有作用。
如何使应用程序能够复原？
请参考这些设计模式来构建可复原的客户端，特别是断路器和重试模式：