我们最近创建了一个Standard 1 GB专门用于分布式锁定的新 Azure Redis 缓存 - 与我们的主 Redis 缓存分开。这样做是为了提高我们主要 Redis 缓存的稳定性，这是一个非常长期的问题，此操作似乎对解决有很大帮助。
在我们的新缓存上，我们每隔 1 到 3 天会在相同的几秒钟内观察到大约 100 个错误。错误是：
No connection is available to service this operation（StackExchange.Redis 错误）
或者：
Could not acquire distributed lock: Conflicted（RedLock.net 错误）
由于它们是来自不同包的错误，我怀疑 Redis 缓存本身就是这里的问题。在此期间，没有任何统计数据看起来异常，工作负载应该适合标准 1GB 大小。
我猜这可能是由广告宣传的Low网络性能引起的，这可能是原因吗？
你的理论听起来很有道理。
检查网络带宽不足
这是一个方便的表格，显示了各种定价层的最大观察带宽。查看观察到的 SKU 的最大带宽，然后转到 Azure 门户中的 Redis 刀片并选择指标。将聚合设置为 Max，并查看缓存读取和缓存写入的总和。这是您消耗的总带宽。将这两者的总和与您遇到错误的时间段相叠加，看看问题是否出在网络吞吐量上。如果是这种情况，请扩大规模。
检查服务器负载
同样在 Metrics 选项卡上，查看服务器负载。这是 Redis 繁忙且无法处理请求的百分比。如果达到 100%，Redis 将无法响应新请求，您将遇到超时问题。如果是这种情况，请扩大规模。
重用连接多路复用器
如果您为每个请求启动 StackExchange.Redis.ConnectionMultiplexer 的新实例，您也可能会用完与 Redis 服务器的连接。基于您的 SKU 的可用连接数量的服务限制在定价页面上。您可以在 Metrics 选项卡上查看您是否超过了 SKU 允许的最大连接数，选择 max aggregation，然后选择 Connected Clients 作为您的指标。
线程耗尽
这听起来不像您的错误，但为了完整起见，我会将它包含在这个 Rogue 的 Redis 问题库中，并且它与 Azure Web 应用程序一起发挥作用。默认情况下，线程池将从 4 个可以立即分配工作的线程开始。当您需要四个以上的线程时，它们会以每 500 毫秒一个线程的速度分配。因此，如果您在短时间内将大量请求转储到 Web 应用程序上，您最终可能会排队工作并最终在请求到达 Redis 之前就被丢弃。要测试这是否是一个问题，请转到您的 Web 应用程序的指标并选择线程并将聚合设置为最大值。如果您在短时间内看到与您的麻烦相对应的巨大峰值，那么您已经找到了罪魁祸首。解决方案包括正确使用 async/await。当这让你没有进一步的时候，
Rob 有一些很好的建议，但确实想添加有关故障排除流量突发和不良 ThreadPool 设置的信息。请参阅：解决 Azure Cache for Redis 客户端问题
突发的流量加上糟糕的 ThreadPool 设置可能会导致延迟处理已由 Redis 服务器发送但尚未在客户端消费的数据。
使用示例 ThreadPoolLogger监控 ThreadPool 统计信息如何随时间变化。您可以使用来自 StackExchange.Redis 的 TimeoutException 消息，如下所示进一步调查：
System.TimeoutException: Timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)
- 请注意，在
IOCPsection 和WORKERsection 中，您的Busy值大于该Min值。这种差异意味着您的ThreadPool设置需要调整。- 你也可以看到
in: 64221。该值表示客户端的内核套接字层已收到 64,211 个字节，但尚未被应用程序读取。这种差异通常意味着您的应用程序（例如 StackExchange.Redis）从网络读取数据的速度不如服务器向您发送数据的速度。您可以配置您的线程池设置，以确保您的线程池在突发情况下快速扩展。
我希望这些附加信息对您有所帮助。