azure - Redis 错误的爆发

Question

我们最近创建了一个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网络性能引起的，这可能是原因吗？

标签： azureredisstackexchange.redisredlock.net

Answer 1

你的理论听起来很有道理。

检查网络带宽不足

这是一个方便的表格，显示了各种定价层的最大观察带宽。查看观察到的 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。当这让你没有进一步的时候，