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