问Azure Redis缓存- GET呼叫超时

EN

我们在Azure中有几个web和工作角色，通过StackExchange.Redis库连接到Azure缓存，并且我们正在接收定期超时，使我们的端到端解决方案陷入停顿。其中一个例子如下：

超时执行GET流:459，inst: 4，mgr: Inactive，queue: 12，qu=0，qs=12，qc=0，wr=0/0，in=65536/0，in =65536/0在c:\TeamCity\buildAgent\work\58bc9a6df18a3782\StackExchange.Redis\StackExchange\Redis\ConnectionMultiplexer.cs:line 1785年，StackExchange.Redis.RedisBase.ExecuteSyncT，c:\TeamCity\buildAgent\work\58bc9a6df18a3782\StackExchange.Redis\StackExchange\Redis\RedisBase.cs:line 79，StackExchange.Redis.RedisDatabase.StringGet(RedisKey键，( c:\TeamCity\buildAgent\work\58bc9a6df18a3782\StackExchange.Redis\StackExchange\Redis\RedisDatabase.cs:line 1346 at OptiRTC.Cache.RedisCacheActions.<>c__DisplayClass41.<Get>b__3() in c:\dev\OptiRTCAzure\OptiRTC.Cache\RedisCacheActions.cs:line 104 at Polly.Retry.RetryPolicy.Implementation(Action action, IEnumerable1 shouldRetryPredicates，Func`1‘1 policyStateFactory) in OptiRTC.Cache.RedisCacheActions.GetT in c:\dev\OptiRTCAzure\OptiRTC.Cache\RedisCacheActions.cs:line 107 at OptiRTC.Cache.RedisCacheAccess.d__e4.MoveNext() in c:\dev\OptiRTCAzure\OptiRTC.Cache\RedisCacheAccess.cs:line 1196；TraceSource 'WaWorkerHost.exe‘事件

所有超时都有不同的队列和qs编号，但其余的消息是一致的。这些StringGet调用跨越缓存中的不同键。在我们的每个服务中，我们使用一个带有单个ConnectionMultiplexer的单例缓存访问类，该类在web或worker角色启动中注册到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对象。我们已经有大约20个web和worker角色实例通过这个ICacheAccess实现连接到缓存，但是管理控制台显示了到缓存的平均200个并发连接。

我已经看到了使用StackExchange.Redis版本1.0.333引用的其他帖子，我们正在通过NuGet进行这种引用，但是当我查看添加的StackExchange.Redis.dll引用的实际版本时，它显示了1.0.316.0。我们尝试添加和删除NuGet引用，并将其添加到新项目中，并且始终得到版本差异。

任何洞察力都将不胜感激。谢谢。

附加信息：

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

我们就这个问题联系了微软，他们确认他们在Redis服务端的Redis日志中没有发现任何问题。我们的缓存丢失%在Redis服务器上非常低，但是我们继续得到这些超时，这严重阻碍了应用程序的功能。

作为对评论的回应，是的，我们总是在qs中有一个数字，而在qc中却没有。我们总是有一个数字在第一部分，而从来没有在第二个。

更多的附加信息：

当我在较高CPU上运行实例较少的服务时，这些超时错误明显多于在较低CPU上运行的实例。更确切地说，我今天早上从我们的服务中提取了一些数字。当它们以大约30%的CPU运行时，我几乎没有看到超时问题-- 30分钟内只有42次。当我删除了一半的实例，它们开始以60%-65%的CPU运行时，在30分钟内，速度增加了10倍，达到536个。