在Azure VM中使用Booksleeve Redis客户端时的Redis连接错误

Question

我最近开始在新的Azure
VM上托管我的一个副项目。该应用程序将Redis用作内存缓存。在本地环境中一切正常，但是现在我已将代码移至Azure，我发现Bookleeve中出现了一些奇怪的异常。

当应用首次启动时，一切正常。但是，在闲置约5-10分钟后，对应用程序的下一个请求遇到了网络异常（我现在正在工作，并且没有确切的错误消息，因此我回到家时会张贴这些消息，如果人们认为他们与讨论密切相关），这将导致内部MessageQueue关闭，从而导致随后的每个Enqueue（）都引发异常（“队列已关闭”）。

因此，经过一番谷歌搜索后，我发现了这样的帖子：使用BookSleeve关于DIY连接管理器维护开放的Redis连接。如果那是最好的做法，那么我当然可以实施类似的措施。

所以，问题：

1. RedisConnection在一定时间后定期关闭是否正常？
2. 我已经看过该conn.SetKeepAlive()方法，但是我尝试了许多不同的值，但似乎没有任何作用。还有更多的东西吗？还是我吠错了树？
3. 上面的帖子中的连接管理器想法是处理这种情况的最佳方法吗？
4. 任何人都可以进一步说明为什么在新的Azure VM中托管我的Redis实例会导致此问题吗？我还可以确认，如果我对Azure Redis VM运行本地环境，则会遇到此问题。

就像我说的那样，如果不活动后Redis连接死掉是不寻常的，那么我回到家时会从日志中发布堆栈跟踪和异常。

谢谢！

UPDATE
Didier在评论中指出，这可能与Azure使用的负载平衡器有关：http :
//blogs.msdn.com/b/avkashchauhan/archive/2011/11/12/windows-azure-load-
balancer-
超时详细信息

假设是这种情况，那么实现可解决此愚蠢问题的连接管理器的最佳方法是什么。我假设我不应该为每个工作单元创建连接，对吗？

Answer 1

从其他答案/评论来看，这听起来像是由于天青的基础架构关闭了看上去空闲的套接字而引起的。您 可能
只是在某个地方有一个定期执行某种操作的计时器，但是请注意，它已经内置在Booksleeve中：在连接时，它会检查redis连接超时，并配置心跳以防止redis关闭套接字。您可能可以背负此操作，以防止天蓝色也关闭套接字。例如，在redis-
cli会话中：

config set timeout 30

应该将redis（运行中，无需重新启动）配置为具有30秒的连接超时。然后，书架应自动采取措施，以确保在30秒之前不久出现心跳。请注意，如果此操作成功，则还应该编辑配置文件，以便在下次重启后也应用此设置。