突发的Redis错误

Question

我们最近创建了一个新的Redis Azure Redis缓存，专门用于分布式锁定-从我们的主Standard 1 GB缓存中分离出来。这样做是为了提高我们的主Redis缓存的稳定性，这是一个非常长期的问题，这个操作似乎对此有很大的帮助。

在我们的新缓存上，我们每1-3天在相同的几秒钟内观察到大约100个错误的突发。错误是：

No connection is available to service this operation (StackExchange.Redis错误)

或者：

Could not acquire distributed lock: Conflicted (RedLock.net错误)

由于它们是来自不同包的错误，我怀疑Redis缓存本身就是问题所在。这段时间内的统计数据看起来都没有异常，工作负载应该适合标准的1 1GB大小。

我猜这可能是由通告的Low网络性能引起的，这可能是原因吗？

Answer 1

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

检查网络带宽不足

显示各种价格层的最大观察带宽的Here is a handy table。查看观察到的SKU的最大带宽，然后转到Azure门户中的Redis刀片并选择指标。将聚合设置为Max，并查看缓存读取和缓存写入的总和。这是您消耗的总带宽。当您遇到错误时，将这两个值的总和与时间段叠加，看看问题是否出在网络吞吐量上。如果是这样的话，就进行扩展。

检查服务器负载

同样在Metrics选项卡上，查看服务器负载。这是Redis繁忙且无法处理请求的百分比。如果达到100%，Redis将无法响应新的请求，您将遇到超时问题。如果是这样的话，就进行扩展。

重用ConnectionMultiplexer

如果您正在为每个请求创建一个新的StackExchange.Redis.ConnectionMultiplexer实例，那么您也可能会耗尽到Redis服务器的连接。根据您的SKU，可用连接数的服务限制为定价页面上的here。您可以在Metrics选项卡上查看是否超过了SKU允许的最大连接数，选择最大聚合，然后选择Connected Clients作为您的指标。

线程耗尽

这听起来不像你的错误，但我将把它包含在这个Rogue's Gallery of Redis issues中，并且它将在Azure Web Apps中发挥作用。默认情况下，线程池将从4个线程开始，这些线程可以立即分配给工作。当你需要四个以上的线程时，它们会以每500ms一个线程的速度被分配。因此，如果你在短时间内将大量请求转储到Web应用程序上，你可能会导致工作排队，甚至在请求到达Redis之前就被丢弃了。要测试这是否存在问题，请转到您的Web应用程序的Metrics，选择Thread并将聚合设置为max。如果你在短时间内看到一个与你的麻烦相对应的巨大峰值，你就找到了罪魁祸首。解决方案包括正确使用async/await。如果没有结果，请将ThreadPool.SetMinThreads设置为一个更高的值，最好是接近或高于突发中看到的最大线程使用率的值。

Answer 2

Rob有一些很好的建议，但他确实想添加有关排除traffic burst和糟糕的ThreadPool设置的信息。请参阅：Troubleshoot Azure Cache for Redis client-side issues

突发流量加上糟糕的ThreadPool设置可能会导致延迟处理已由Redis服务器发送但尚未在客户端使用的数据。

使用an example 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)

• 请注意，在IOCP部分和WORKER部分中，Busy值大于Min值。这种不同意味着你的ThreadPool设置需要adjusting.
• You也可以看到in: 64221。该值表示已在客户端的内核套接字层接收到64,211字节，但尚未被应用程序读取。这种差异通常意味着您的应用程序(例如StackExchange.Redis)从网络中读取数据的速度不如服务器向您发送数据的速度快。

您可以使用configure your ThreadPool Settings来确保您的线程池在突发场景下能够快速扩展。

我希望这些附加信息对您有所帮助。