问题描述
Azure Redis 出现连接失败，过一会儿后，又能自动恢复。
问题解答
其实，因为Azure Redis服务一直都有升级维护的操作(平均每月一次)，Redis服务更新是平台自动进行的计划内的维护升级行为，一般客户端都有重试机制，是不会影响应用。
故障转移发生的情况有：
- 系统更新，例如 Redis 修补或 OS 升级。
- 管理操作，例如缩放和重新启动。
由于节点会提前收到更新通知，因此它们可以协作交换角色，并在更改后快速更新负载均衡器。 计划性故障转移通常可在 1 秒内完成。对应用侧的影响主要是所有的连接都需要重新建立，在客户端SDK的重试机制触发前，会出现以下几类的异常：
- 超时异常
- 连接异常
- 套接字异常
异常的数目和类型取决于当缓存关闭其连接时，请求在代码路径中所处的位置。 例如，在发生故障转移时发送了请求但未收到响应的操作可能会收到超时异常。 对关闭的连接对象发出的新请求将收到连接异常，直到重新连接成功为止。
大多数客户端库会尝试重新连接到缓存（如果采用此配置）。 但是，不可预测的 bug 偶尔会将库对象置于不可恢复状态。 如果出错的持续时间超过了预先配置的时间，则应重新创建连接对象。
但是为了更进一步的减少升级维护对Redis的正常业务的影响，可以配置更新窗口然更新发生在业务空闲期，详细参考：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-administration#schedule-updates
参考资料
计划更新 ：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-administration#schedule-updates
故障转移 ：https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-failover
Redis重试 ：https://docs.microsoft.com/zh-cn/azure/architecture/best-practices/retry-service-specific#azure-cache-for-redis 和 https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-best-practices#client-library-specific-guidance
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!