Несколько определений IDistributedCache не закрывают подключения Redis

Question

У меня есть следующее решение для реализации нескольких определений IDistributedCache:

public interface IDBCache : IDistributedCache
{
}

public class DBCacheOptions : RedisCacheOptions { }

public class DBCache : RedisCache, IDBCache
{
    public DBCache(IOptions<DBCacheOptions> optionsAccessor) : base(optionsAccessor)
    {

    }
}

И у меня есть другие определения, такие как вышеуказанный pointint для разных экземпляров redis.

Я регистрирую службу кэширования в Startup.cs как:

services.Configure<DBCacheOptions>(options => options.Configuration = configuration.GetValue<string>("Cache:DB"));
services.Add(ServiceDescriptor.Singleton<IDBCache, DBCache>());

А затем я обертываю IDBCache как:

public class DBCacheManager
{
    private const string DB_CACHE_FORMAT = "DB:{0}";
    private const int DB_EXPIRATION_HOURS = 8;

    private readonly IDistributedCache _cache;

    public DBCacheManager(IDBCache cache)
    {
        _cache = cache;
    }

    public Task AddDBItem(string name, string value)
    {
            return _cache.SetStringAsync(string.Format(DB_CACHE_FORMAT, name), value,
                new DistributedCacheEntryOptions { AbsoluteExpirationRelativeToNow = TimeSpan.FromDays(DB_EXPIRATION_HOURS) });
    }
}

И когда я проверяю, подключены ли клиенты к redis (команда info clients) connected_clients увеличиваются без остановки, также когда я вижу список клиентов (команда client list), я вижу большой список соединений с длинными возрастами и бездействующими.

Выводы. Я использую реализацию Redis AWS ElasticCache, которая по умолчанию имеет неограниченный тайм-аут простоя, но я полагаю, что не следует заставлять закрывать эти соединения, не так ли? Я полагаю, что моя заявка должна быть ответственной.

Answer 1

Это была плохая реализация внедрения зависимостей. Интерфейс IDistributedCache имеет реализацию команды redis INCR, поэтому где-то в нашем проекте мы подключались напрямую, используя StackExchange.Redis с DI-оболочкой, которая создавала несколько мультиплексоров соединений и баз данных.

Итог: мой плохой