如何使用 StackExchange.Redis 在客户端解决 Redis 超时？答案

【问题标题】：How to solve a Redis timeout on client side with StackExchange.Redis?如何使用 StackExchange.Redis 在客户端解决 Redis 超时？
【发布时间】：2017-11-23 18:49:36
【问题描述】：

我在 c# wcf 应用程序中使用 StackExchange.Redis 客户端：我只使用同步命令来获取和设置值。问题是我有这个奇怪的日志超时：

Timeout performing EXISTS DataKey:50, 
inst: 1, queue: 1, qu: 0, qs: 1, qc: 0, wr: 0, wq: 0, in: 0, ar: 0, clientName: Machine1, 
serverEndpoint: redis-server:6381, keyHashSlot: 7984, 
IOCP: (Busy=1,Free=799,Min=8,Max=800), 
WORKER: (Busy=5,Free=795,Min=8,Max=800) 
(Please take a look at this article for some common client-side issues that can 
cause timeouts: http://stackexchange.github.io/StackExchange.Redis/Timeouts)

如果我理解正确，这意味着我的 get 值已排队，因为有五个工作线程？使用 netstat，我看到我的应用程序正在打开到服务器的两个物理连接。我确保在我的线程池中有足够的线程可用。在我的连接设置中，我有一个 syncTimeout=3000... 如果我使用redis-cli，我可以在0.64秒内得到key的值。

有人可以帮忙吗？我能做些什么？我必须一直在我的代码中使用 async 还是找到另一个 redis 客户端库？

【问题讨论】：

标签： c# timeout stackexchange.redis

【解决方案1】：

有几个解决方案。首先，他们在 github repo 上有一篇关于他们提出的解决方案的文章，发现 here。

我发现只是尽可能多地使用异步函数，它只是超时的同步函数。在我看来，超时是他们的设计决定，基于他们不想在出现问题时阻止您的代码的想法。我不买那个，所以我使用的解决方法是使用异步函数，然后等待任务。所以我只做db.StringGetAsync("thestring").Result 而不是db.StringGet("thestring")。也就是说，如果我因任何原因不能使用 await 。

无论如何，您可能希望尽可能多地使用 async/await。如果合适，您可能还想使用 FireAndForget。您也可以使用 ContinueWith。他们谈论这些解决方案here。

【讨论】：

我已经阅读了这些解决方案，我将尝试使用异步版本，然后等待任务......我们没有使用异步代码，因为我的团队不精通异步/等待模式，我们担心由于异步性而有很多错误......另一方面，调用异步函数并等待它对我来说似乎很奇怪：这样做我会花时间打开另一个线程，等待然后切换回主线程没有？
我不确定您的意思，但这与同步函数发生的情况没有什么不同。所发生的只是当前线程一直等到调用完成然后继续，但这正是同步调用所发生的情况。
备份塞巴斯蒂安的说法：异步不等于并行。

【解决方案2】：

从“WORKER: (Busy=5,Free=795,Min=8,Max=800)”中，我看到有 5 个 Busy 工作线程，最少只有 8 个工作线程。我怀疑如果您查看收到的所有错误集，您可能会发现在某些情况下 Busy 大于 Min 计数。这将指示threadpool throttling。该链接还提供了一些关于增加 Worker 和 IOCP 线程的最小线程数的解决方案。

【讨论】：

你不知道这个答案对我有多大帮助。谢谢！

【解决方案3】：

修复RedisTimeout异常总是一个挑战，有很多因素导致超时异常，

在您的日志中，您可以看到 IOCP 线程有 1 繁忙线程，并且您的系统配置为允许 8 最少线程。所以不是这样，因为1 不是> 8

一旦我遇到同样的情况并通过在连接字符串中增加syncTimeout 来修复超时异常，您可以尝试增加它

我还意识到打开的连接数会影响 Redis 的性能，你可以通过运行这个命令来查看打开的连接

info clients

在引发超时异常时，我有大约 90 个打开的连接，我重新启动服务器以重置打开的连接并且超时异常消失了

【讨论】：