Azure Redis缓存-GET调用超时

Question

Azure中有多个Web和辅助角色通过StackExchange.Redis库连接到我们的Azure Redis缓存，并且我们收到的定期超时使我们的端到端解决方案陷入停顿。下面是其中一个示例：

System.TimeoutException：执行GET流的超时：459，inst：4，mgr：不活动，队列：12，在StackExchange.Redis上qu = 0，qs = 12，qc = 0，wr = 0/0，in = 65536/0 .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, ResultProcessor1处理器，ServerEndPoint服务器）位于c：\ TeamCity \ buildAgent \ work \ 58bc9a6df18a3782 \ StackExchange.Redis \ StackExchange \ Redis \ RedisBase.cs：StackExchange.Redis.RedisDatabase的第79行.StringGet（RedisKey键，CommandFlags标志）位于c：\ TeamCity \ buildAgent \ work \ 58bc9a6df18a3782 \ StackExchange.Redis \ StackExchange \ Redis \ RedisDatabase.cs：OptiRTC.Cache.RedisCacheActions的第1346行。<> c__DisplayClass41.<Get>b__3() in c:\dev\OptiRTCAzure\OptiRTC.Cache\RedisCacheActions.cs:line 104 at Polly.Retry.RetryPolicy.Implementation(Action action, IEnumerableOptiRTC.Cache.RedisCacheActions.Get [T]（String key，Boolean allowDirtyRead）中的1 shouldRetryPredicates，Func`1 policyStateFactory）位于OptiRTC.Cache.RedisCacheAccess的c：\ dev \ OptiRTCAzure \ OptiRTC.Cache \ RedisCacheActions.cs：line：107中.d__e4.MoveNext（）在c：\ dev \ OptiRTCAzure \ OptiRTC.Cache \ RedisCacheAccess.cs：line 1196; TraceSource'WaWorkerHost.exe'事件

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

        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％的时间超时。超时具有与上述格式相同的格式，并且在将db.StringGet调用包装在处理RedisException和System.TimeoutException的Polly重试块中之后，它们继续发生，并在500ms之后重试一次。

我们已就此问题与Microsoft联系，他们确认没有在Redis日志中看到任何指示Redis服务端问题的消息。在Redis服务器上，我们的缓存未命中百分比非常低，但是我们继续遇到这些超时问题，这大大阻碍了我们应用程序的功能。

对于这些评论，是的，我们在qs中总是有一个数字，而在qc中从来没有。in的第一部分中总是有一个数字，而第二部分中从来没有。

甚至更多的信息：

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

Answer 1

我知道这个线程已有几个月的历史，但我认为自己的经验可以在这里增加一些价值。我在Azure Redis缓存中遇到了相同的问题（Gets上的超时），但意识到它几乎完全发生在Gets上，在其中字符串值相对较大（长度大于250K）。我在Gets和Sets上都实现了gzip（当字符串值很大时），现在我几乎从没有超时。

即使这不能解决您的特定问题，通常还是最好压缩这些值以降低成本并提高性能。