我在查询缓存的单个计算机的高负载情况下使用Azure Redis缓存.这台机器每秒大约可以获得约20件物品.在白天,这种情况会增加,在夜间这种情况会减少.
到目前为止,事情一直很好.今天我意识到"连接客户端"的指标非常高,尽管我只有一个客户端只是经常获取和设置项目.以下是我所指的指标的屏幕截图:
我的代码看起来像这样:
public class RedisCache: ICache { private IDatabase cache; private ConnectionMultiplexer connectionMultiplexer; public RedisCache() { ConfigurationOptions config = new ConfigurationOptions(); config.EndPoints.Add(GlobalConfig.Instance.GetConfig("RedisCacheUrl")); config.Password = GlobalConfig.Instance.GetConfig("RedisCachePassword"); config.ConnectRetry = int.MaxValue; // retry connection if broken config.KeepAlive = 60; // keep connection alive (ping every minute) config.Ssl = true; config.SyncTimeout = 8000; // 8 seconds timeout for each get/set/remove operation config.ConnectTimeout = 20000; // 20 seconds to connect to the cache connectionMultiplexer = ConnectionMultiplexer.Connect(config); cache = connectionMultiplexer.GetDatabase(); } public virtual bool Add(string key, TValue item) { return cache.StringSet(key, RawSerializationHelper.Serialize(item)); }
我不是创建这个类的多个实例,所以这不是问题.也许我错过了解连接度量标准,它们真正意味着我访问缓存的次数,但是,在我看来这不是真的有意义.任何想法,或任何有类似问题的人?
StackExchange.Redis的竞争条件可能导致在某些情况下泄露的连接.这已在build 1.0.333或更新版本中修复.
如果要确认这是您遇到的问题,请获取客户端应用程序的故障转储并在调试器中查看堆上的对象.查找大量StackExchange.Redis.ServerEndPoint对象.
此外,一些用户的代码中存在错误,导致泄露的连接对象.这通常是因为他们的代码在看到失败或断开状态时尝试重新创建ConnectionMultiplexer对象.实际上没有必要重新创建ConnectionMultiplexer,因为它在内部具有逻辑以根据需要重新创建连接.只需确保在连接字符串中将abortConnect设置为false.
如果您决定重新创建连接对象,请确保在释放对它的所有引用之前处置旧对象.
以下是我们推荐的模式:
private static Lazy lazyConnection = new Lazy(() => { return ConnectionMultiplexer.Connect("contoso5.redis.cache.windows.net,abortConnect=false,ssl=true,password=..."); }); public static ConnectionMultiplexer Connection { get { return lazyConnection.Value; } }