Azure Cache for Redis 的故障转移和修补
要构建可复原且成功的客户端应用程序，了解 Azure Cache for Redis 服务中的故障转移至关重要。 故障转移可能是计划的管理操作中的一部分，也可能由意外硬件或网络故障引发。 当管理服务修补 Azure Cache for Redis 二进制文件时，往往会使用缓存故障转移。
在本文中，你将找到以下信息：
- 什么是故障转移？
- 在修补期间如何进行故障转移。
- 如何构建可复原的客户端应用程序。
什么是故障转移？
让我们从 Azure Cache for Redis 故障转移的概述开始。
缓存体系结构的快速摘要
缓存由具有单独的专用 IP 地址的多个虚拟机构成。 每个虚拟机（也称为节点）通过单个虚拟 IP 地址连接到一个共享的负载均衡器。 每个节点运行 Redis 服务器进程，可通过主机名和 Redis 端口进行访问。 每个节点被视为主节点或副本节点。 当客户端应用程序连接到缓存时，其流量将流经此负载均衡器，并自动路由到主节点。
在基本缓存中，单一节点始终为主节点。 标准或高级缓存中有两个节点，其中一个为主节点，另一个为副本节点。 由于标准缓存和高级缓存有多个节点，其中一个节点可处于不可用状态，而其他节点可继续处理请求。 群集缓存由许多分片组成，每个分片具有不同的主节点和副本节点。 一个分片可处于关闭状态，其他节点仍保持可用。
注意
基本缓存没有多个节点，并且不提供可用性方面的服务级别协议 (SLA)。 基本缓存仅建议用于开发和测试目的。 对多节点部署使用标准或高级缓存可提高可用性。
故障转移的说明
当某个副本节点将其自身提升为主节点，且旧主节点关闭现有连接时，将发生故障转移。 主节点重新启动后，它会注意到角色的变化，从而将自身降级为副本节点。 然后，它将连接到新的主节点并同步数据。 故障转移可以是计划性的，也可以是非计划的。
计划的故障转移发生在两个不同的时间：
- 系统更新，例如 Redis 修补或 OS 升级。
- 管理操作，例如缩放和重新启动。
由于节点会提前收到更新通知，因此它们可以协作交换角色，并在更改后快速更新负载均衡器。 计划性故障转移通常可在 1 秒内完成。
发生非计划性故障转移的可能原因是硬件故障、网络故障或主节点的其他意外中断。 副本节点可将自身提升为主节点，但该过程需要更长时间。 副本节点必须先检测到其主节点不可用，然后才能启动故障转移过程。 副本节点还必须验证此非计划性故障不是暂时性的或局部性的，以避免不必要的故障转移。 检测时出现的这种延迟意味着非计划性故障转移通常要在 10 到 15 秒内完成。
修补是如何进行的？
Azure Cache for Redis 服务定期使用最新的平台功能和修补程序更新缓存。 该服务遵循以下步骤来修补缓存：
- 该服务首先修补副本节点。
- 修补的副本以协作方式将自身提升为主副本。 这种升级被视为计划性故障转移。
- 以前的主节点将重新启动以接受新的更改，并作为副本节点备份。
- 副本节点连接到主节点并同步数据。
- 数据同步完成后，将对剩余的节点重复修补过程。
因为修补属于计划性故障转移，所以副本节点会快速将自身提升为主节点。 然后，节点开始为请求和新连接提供服务。 基本缓存没有副本节点，在更新完成之前不可用。 群集缓存的每个分片单独进行修补，不会关闭与另一个分片的连接。
重要
每次修补一个节点以防数据丢失。 基本缓存会发生数据丢失。 每次修补缓存群集的一个分片。
同一资源组和区域中的多个缓存也是每次修补一个。 不同资源组或区域中的缓存可以同时修补。
由于完全数据同步在该过程重复之前发生，因此，在使用标准或高级缓存时不太可能发生数据丢失。 可以使用导出数据功能并启用持久性来进一步防止数据丢失。
额外的缓存负载
每当发生故障转移时，标准和高级缓存需要将数据从一个节点复制到另一个节点。 这种复制会导致负载消耗的服务器内存和 CPU 增大。 如果缓存实例的负载已很繁重，客户端应用程序遇到的延迟可能会增大。 在极端情况下，客户端应用程序可能会收到超时异常。 为了帮助减轻负载增加的影响，请配置缓存的 maxmemory-reserved 设置。
故障转移如何影响我的客户端应用程序？
客户端应用程序可能会从其 Azure Cache For Redis 收到一些错误。 客户端应用程序遇到的错误数目取决于故障转移时该连接上挂起的操作数目。 通过已关闭其连接的节点路由的任何连接都将遇到错误。
在连接中断时，许多客户端库可能会引发不同类型的错误，包括：
- 超时异常
- 连接异常
- 套接字异常
异常的数目和类型取决于当缓存关闭其连接时，请求在代码路径中所处的位置。 例如，在发生故障转移时发送了请求但未收到响应的操作可能会收到超时异常。 对关闭的连接对象发出的新请求将收到连接异常，直到重新连接成功为止。
大多数客户端库会尝试重新连接到缓存（如果采用此配置）。 但是，不可预测的 bug 偶尔会将库对象置于不可恢复状态。 如果出错的持续时间超过了预先配置的时间，则应重新创建连接对象。 在 Microsoft.NET 及其他面向对象的语言中，可以通过使用 ForceReconnect 模式在不重启应用程序的情况下重新创建连接。
是否可以在维护前收到通知？
Azure Cache for Redis 在名为 AzureRedisEvents 的发布/订阅 (pub/sub) 通道上发布运行时维护通知。 许多常用的 Redis 客户端库都支持订阅 pub/sub 通道。 通常，在客户端应用程序中添加从 AzureRedisEvents 通道接收通知的功能很简单。 有关维护事件详细信息，请参阅 AzureRedisEvents。
注意
AzureRedisEvents 通道不是可提前几天或几小时发出通知的机制。 该通道可以向客户端通知即将发生的可能会影响服务器可用性的计划内服务器维护事件。 AzureRedisEvents 仅适用于“基本”、“标准”和“高级”层。
维护中包括哪些更新？
维护包括以下更新：
- Redis 服务器更新：Redis 服务器二进制文件的任何更新或修补程序。
- 虚拟机 (VM) 更新：托管 Redis 服务的虚拟机的任何更新。 VM 更新包括修补托管环境中的软件组件以升级网络组件或解除授权。
维护是否在修补之前显示在 Azure 门户中的服务运行状况中？
否，维护不会显示在门户或其他任何位置的服务运行状况下的任何位置。
我能在计划内维护之前多长时间收到通知？
使用 AzureRedisEvents 通道时，会在维护前 15 分钟收到通知。
客户端网络配置更改
某些客户端网络配置更改可能会触发“无可用连接”错误。 此类更改可能包括：
- 在过渡槽与生产槽之间交换客户端应用程序的虚拟 IP 地址。
- 缩放应用程序实例的大小或数量。
此类更改可能会导致通常持续一分钟以下的连接问题。 客户端应用程序可能会断开与其他外部网络资源的连接，同时也会断开与 Azure Cache for Redis 服务的连接。
内置的复原能力
无法完全避免故障转移。 应该合理编写客户端应用程序，使之能够弹性应对连接中断和请求失败的问题。 大多数客户端库可以自动重新连接到缓存终结点，但有少量的客户端库会重试失败的请求。 根据具体的应用方案，使用支持退让的重试逻辑可能有作用。
如何使应用程序能够复原？
请参考这些设计模式来构建可复原的客户端，特别是断路器和重试模式：
若要测试客户端应用程序的复原能力，请使用重新启动作为连接中断时的手动触发器。
此外，建议使用计划更新来选择更新通道和维护时段，以便缓存在特定每周时段应用 Redis 运行时修补程序。 通常，这些时段是客户端应用程序流量较低的时段，目的是避免潜在的事件。 有关详细信息，请参阅更新通道和计划更新。
有关详细信息，请参阅连接复原能力。