你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
连接复原能力
重试命令
将客户端连接配置为使用指数退避重试命令。 有关详细信息，请参阅重试指导原则。
测试复原
使用重启来模拟某个补丁，测试系统对连接中断的复原能力。 有关如何测试性能的详细信息，请参阅性能测试。
Linux 托管客户端应用程序的 TCP 设置
某些 Linux 版本中的默认 TCP 设置可能会导致 Redis 服务器连接失败 13 分钟或更长时间。 默认设置可以防止客户端应用程序检测关闭的连接，并在连接未正常关闭的情况下防止自动还原这些关闭的连接。
如果网络连接中断或 Redis 服务器脱机进行计划外维护，重新建立连接可能会失败。
建议使用以下 TCP 设置：
| 设置 | “值” |
|---|---|
net.ipv4.tcp_retries2 |
5 |
有关此方案的详细信息，请参阅在 Linux 上运行时，长达 15 分钟无法重新建立连接。 虽然此讨论与 StackExchange.Redis 库有关，但 Linux 上运行的其他客户端库也会受到影响。 该说明仍然有用，可以通用化到其他库。
将 ForceReconnect 与 StackExchange.Redis 一起使用
在极少数情况下，Stackexchange.Redis 在删除连接后会无法重新连接。 在这些情况下，重新启动客户端或创建新的 ConnectionMultiplexer 可解决此问题。 建议使用单一实例 ConnectionMultiplexer 模式，同时允许应用定期强制重新连接。 请查看与应用程序使用的框架和平台最匹配的快速入门示例项目。 在我们的快速入门中，可以查看此代码模式的示例。
ConnectionMultiplexer 的用户必须处理因处置该类的旧实例而可能发生的任何 ObjectDisposedException 错误。
针对 RedisConnectionExceptions 和 RedisSocketExceptions 调用 ForceReconnectAsync()。 也可以针对 RedisTimeoutExceptions 调用 ForceReconnectAsync()，但前提是你使用大量的 ReconnectMinInterval 和 ReconnectErrorThreshold。 否则，建立新连接可能会导致超时的服务器发生连锁故障，因为服务器已过载。
在 ASP.NET 应用程序中，可以在 Microsoft.Extensions.Caching.StackExchangeRedis 包中使用集成实现，而不是直接使用 StackExchange.Redis 包。 如果在 ASP.NET 应用程序中使用 Microsoft.Extensions.Caching.StackExchangeRedis，而不是直接使用 StackExchange.Redis，则可以将 UseForceReconnect 属性设置为 true：
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
配置适当的超时
在连接复原能力方面必须考虑两个超时值：connect timeout 和 command timeout。
连接超时
connect timeout 是指客户端等待与 Redis 服务器建立连接的时间。 将客户端库配置为使用 5 秒的 connect timeout，这样，即使在 CPU 负载较高的情况下，系统也有足够的时间建立连接。
如果 connection timeout 值很小，则无法保证在该期限内建立连接。 如果出现问题（客户端 CPU 负载过高、服务器 CPU 负载过高，等等），则使用很短的 connection timeout 值会导致连接尝试失败。 此行为通常会使问题变得更糟。 使用较短的超时不仅无助于解决问题，而且会加剧问题，这会强制系统重启尝试重新连接的进程，从而可能导致出现“连接 -> 失败 -> 重试”循环。
命令超时
大多数客户端库为 command timeouts（客户端等待 Redis 服务器做出响应的时间）使用另一种超时配置。 尽管我们建议使用不到 5 秒的初始设置，但请根据你的方案和存储在缓存中的值的大小来调高或调低 command timeout。
如果 command timeout 太小，则连接可能不稳定。 但是，如果 command timeout 太大，则应用程序可能需要等待很长时间才能确定命令是否会超时。
避免出现客户端连接高峰
在连接断开后重新连接时，避免同时创建多个连接。 与使用很短的连接超时可能导致长时间的服务中断一样，同时发起多个重新连接尝试也会增大服务器负载，并延长所有客户端成功重新连接所需的时间。
如果要重新连接许多客户端实例，请考虑错开新的连接，以避免连接的客户端数出现陡峰。
注意
如果使用 StackExchange.Redis 客户端库abortConnect，请在连接字符串中将 设置为 false。 建议让 ConnectionMultiplexer 处理重新连接。 有关详细信息，请参阅 StackExchange.Redis 最佳做法。
避免残余连接
缓存对每个缓存层的客户端连接数施加了限制。 确保客户端应用程序在重新创建连接时关闭并删除旧连接。
提前发出维护通知
使用通知来通告即将进行维护。 有关详细信息，请参阅我是否可以提前收到计划内维护的通知。
计划维护时段
调整缓存设置以顺应维护工作。 若要详细了解如何创建维护时段以降低对缓存造成的任何负面影响，请参阅更新通道和计划更新。
可实现复原的其他设计模式
应用设计模式来实现复原。 有关详细信息，请参阅如何使我的应用程序能够复原。
空闲超时
Azure Cache for Redis 空闲连接的超时时间为 10 分钟。 10 分钟的超时允许服务器自动清理泄漏的连接或客户端应用程序孤立的连接。 大多数 Redis 客户端库都具有内置功能，可以定期发送 heartbeat 或 keepalive 命令，以防止连接关闭，即使没有来自客户端应用程序的请求。
如果存在连接空闲 10 分钟的风险，请将 keepalive 间隔配置为小于 10 分钟的值。 如果应用程序使用的客户端库本身不支持 keepalive 功能，则可通过定期发送 PING 命令在应用程序中实现它。