StackExchange.Redis 超时和 "No connection is available to service this operation"_编程设计

我在生产环境(Web-Farm - 4 个节点，其上有负载均衡器)中遇到以下问题:

1) 执行 HGET key 超时，inst: 3，queue: 29, qu=0, qs=29, qc=0, wr=0/0 在 StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImpl[T](Message message, ResultProcessor``1processor, ServerEndPoint server) in ConnectionMultiplexer.cs:line 1699 这种情况在一分钟内发生 3-10 次

2) 没有可用于服务此操作的连接:ConnectionMultiplexer.cs 中 StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImpl[T](Message message, ResultProcessor``1 处理器，ServerEndPoint 服务器) 处的 HGET 键:第 1666 行

我尝试按照 Marc 的建议来实现(也许我解释错误)——与 Redis 的连接越少越好。我做了以下实现:

public class SeRedisConnection 
{ 
    private static ConnectionMultiplexer _redis; 
 
    private static readonly object SyncLock = new object(); 
 
    public static IDatabase GetDatabase() 
    { 
        if (_redis == null || !_redis.IsConnected || !_redis.GetDatabase().IsConnected(default(RedisKey))) 
        { 
            lock (SyncLock) 
            { 
                try 
                { 
                    var configurationOptions = new ConfigurationOptions 
                    { 
                        AbortOnConnectFail = false 
                    }; 
                    configurationOptions.EndPoints.Add(new DnsEndPoint(ConfigurationHelper.CacheServerHost, 
                        ConfigurationHelper.CacheServerHostPort)); 
 
                    _redis = ConnectionMultiplexer.Connect(configurationOptions); 
                } 
                catch (Exception ex) 
                { 
                   IoC.Container.Resolve<IErrorLog>().Error(ex); 
                    return null; 
                } 
            } 
        } 
        return _redis.GetDatabase(); 
    } 
 
    public static void Dispose() 
    { 
        _redis.Dispose(); 
    } 
}

实际上现在没有使用dispose。另外，我还有一些可能导致这种行为的实现细节(我只使用哈希值): 1. 添加、删除哈希值 - 异步 2. 获取-sync

有人可以帮助我如何避免这种行为吗？

提前非常感谢!

已解决 - 评估网络功能后增加客户端连接超时。

更新2:实际上并没有解决问题。当缓存容量开始增加时，例如2GB起。然后我看到了同样的模式，实际上这些超时大约每 5 分钟发生一次。我们的站点每 5 分钟就会卡住一段时间，直到 fork 操作完成。然后我发现有一个选项可以每 x 秒创建一次 fork(保存到磁盘):

save 900 1 
save 300 10 
save 60 10000

就我而言，它是“保存 300 10” - 如果至少发生 10 次更新，则每 5 分钟保存一次。我还发现“ fork ”可能非常昂贵。注释“保存”部分完全解决了问题。我们可以评论“保存”部分，因为我们仅使用 Redis 作为“内存中的缓存”——我们不需要任何持久性。以下是我们的缓存服务器“Redis 2.4.6”Windows 端口的配置:https://github.com/rgl/redis/downloads

也许在 MSOpentech 的最新版本的 Redis windows 端口中已经解决了这个问题:http://msopentech.com/blog/2013/04/22/redis-on-windows-stable-and-reliable/ 但我还没有测试过。

无论如何，StackExchange.Redis 与此问题无关，并且它在我们的生产环境中运行得非常稳定，这要感谢 Marc Gravell。

最终更新: Redis 是单线程解决方案 - 它最终速度很快，但是当涉及到释放内存(删除陈旧或过期的项目)时，由于一个线程应该回收内存(这不是快速操作)，因此出现了问题 -无论使用什么算法)并且同一个线程应该处理 GET、SET 操作。当然，当我们谈论中等负载的生产环境时，就会发生这种情况。即使您使用带有从站的集群，当达到内存屏障时，它也会有相同的行为。

请您参考如下方法:

在大多数情况下，此异常似乎是客户端问题。以前版本的 StackExchange.Redis 直接使用 Win32 套接字，这有时会产生负面影响。可能 Asp.net 内部路由与它有某种关系。
好消息是 StackExchange.Redis 的网络基础设施最近已完全重写。最后版本是2.0.513。尝试一下，您的问题很有可能会得到解决。