Question

我们在Azure中通过StackExchange.Redis库连接到我们的Azure Redis缓存中有多个Web和辅助角色，我们正在接收定期超时，这使得我们的端到端解决方案可以解决停了下来。其中一个例子如下：

System.TimeoutException：执行GET流的超时：459，inst：4， mgr：无效，队列：12，qu = 0，qs = 12，qc = 0，wr = 0/0，in = 65536/0 at StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImpl [T]（消息消息，ResultProcessor 1 processor, ServerEndPoint server) in c:\TeamCity\buildAgent\work\58bc9a6df18a3782\StackExchange.Redis\StackExchange\Redis\ConnectionMultiplexer.cs:line 1785 at StackExchange.Redis.RedisBase.ExecuteSync[T](Message message, ResultProcessor 1处理器，ServerEndPoint服务器） C：\ TeamCity的\ buildAgent \工作\ 58bc9a6df18a3782 \ StackExchange.Redis \ StackExchange \ Redis的\ RedisBase.cs：行 79在StackExchange.Redis.RedisDatabase.StringGet（RedisKey键， CommandFlags标志） C：\ TeamCity的\ buildAgent \工作\ 58bc9a6df18a3782 \ StackExchange.Redis \ StackExchange \ Redis的\ RedisDatabase.cs：行 1346年 OptiRTC.Cache.RedisCacheActions＆LT;＆GT; c__DisplayClass4 1.<Get>b__3() in c:\dev\OptiRTCAzure\OptiRTC.Cache\RedisCacheActions.cs:line 104 at Polly.Retry.RetryPolicy.Implementation(Action action, IEnumerable 1 shouldRetryPredicates，Func`1 policyStateFactory）at OptiRTC.Cache.RedisCacheActions.Get [T]（String key，Boolean allowDirtyRead）in c：\ dev \ OptiRTCAzure \ OptiRTC.Cache \ RedisCacheActions.cs：第107行 OptiRTC.Cache.RedisCacheAccess.d__e4.MoveNext（）在c：\ dev \ OptiRTCAzure \ OptiRTC.Cache \ RedisCacheAccess.cs：第1196行; TraceSource＆＃39; WaWorkerHost.exe＆＃39;事件

所有超时都有不同的队列和qs数字，但其余的消息是一致的。这些StringGet调用跨越缓存中的不同键。在我们的每个服务中，我们使用单一缓存访问类和单个ConnectionMultiplexer，它在Web或辅助角色启动中向我们的IoC容器注册：

        container.RegisterInstance<ICacheAccess>(cacheAccess);

在我们的ICacheAccess实现中，我们按如下方式创建多路复用器：

            ConfigurationOptions options = new ConfigurationOptions();
            options.EndPoints.Add(serverAddress);
            options.Ssl = true;
            options.Password = accessKey;                    
            options.ConnectTimeout = 1000;
            options.SyncTimeout = 2500;

            redis = ConnectionMultiplexer.Connect(options);

在整个实例中使用redis对象。我们通过此ICacheAccess实现获得了大约20个连接到缓存的Web和辅助角色实例，但管理控制台平均显示了200个缓存并发连接。

我已经看过使用StackExchange.Redis版本1.0.333引用的其他帖子，我们正在通过NuGet进行，但是当我查看添加的StackExchange.Redis.dll引用的实际版本时，它显示1.0.316.0。我们尝试添加和删除NuGet参考以及将其添加到新项目中，我们总是会遇到版本差异。

任何见解都将受到赞赏。感谢。

其他信息：

我们已升级到1.0.371。我们有两个服务，每个服务以不同的间隔访问同一个缓存对象，一个用于编辑和偶尔读取，另一个用于每秒读取此对象几次。这两个服务都使用相同的缓存代码和StackExchange.Redis库版本进行部署。我几乎从未在编辑对象的服务中看到超时，但是在读取它的服务上有50％到75％的时间超时。超时具有与上面指示的格式相同的格式，并且在将Polss重试块中的db.StringGet调用包装起来后继续发生，该块处理RedisException和System.TimeoutException并在500ms后重试一次。

我们就此问题与Microsoft联系，他们确认他们在Redis日志中没有看到任何表明Redis服务端出现问题的内容。我们的缓存未命中％在Redis服务器上非常低，但我们继续获得这些超时，这实质上阻碍了我们的应用程序的功能。

在回应评论时，是的，我们总是有一个qs的数字而不是qc。我们总是在第一部分有一个数字而在第二部分没有。

更多其他信息：

当我在较高CPU上运行具有较少实例的服务时，与实例在较低CPU运行时相比，我得到的这些超时错误要多得多。更具体地说，我今天早上从我们的服务中提取了一些数字。当他们以大约30％的CPU运行时，我看到很少的超时问题 - 在30分钟内只有42个。当我删除了一半的实例并开始以大约60-65％的CPU运行时，速率在30分钟内增加了10倍，达到536。

Answer 1

我知道这个帖子已经有几个月了，但我认为我自己的经历可以在这里增加一些价值。我在Azure Redis缓存中遇到了同样的问题（在获取时超时）但是意识到它几乎完全发生在字符串值相对较大的Get（长度> 250K）上。我在Get和Sets上实现了gzip（当字符串值很大时），现在我几乎从未得到超时。

即使这不能解决您的特定问题，通常也可以通过压缩值来降低成本和提高性能。

Answer 2

关于版本号，似乎最后几个版本的AssemblyVersion已锁定在1.0.316，但AssemblyFileVersion已更新以匹配NuGet包版本。目前，我建议忽略AssemblyVersion并仅使用AssemblyFileVersion来确保您拥有正确的二进制文件。

如果您仍然看到使用Azure Redis缓存超时，请通过AzureCache@microsoft.com与我们联系。

Azure Redis缓存 - GET调用超时

2 个答案: