Множественный кэш памяти в веб-API ASp .Net Core

У меня есть ASP .Net Core 2.2. Веб-API. Я бы хотел повысить производительность с помощью MemoryCache. Однако мне нужно кэшировать 2 разных типа, оба из которых используют целочисленные ключи. Один тип - это список пользователей, а другой - список групп.

Теперь я добавляю службу MemoryCache в файл Startup.cs:

services.AddMemoryCache();

а затем я использую внедрение зависимостей для доступа к этому кешу в двух разных местах (в промежуточном программном обеспечении и в сервисе, который я написал).

Насколько я понимаю, оба этих кеша - это один и тот же экземпляр. Поэтому, когда я добавляю в него своих различных пользователей и группы, поскольку у них обоих есть целочисленные ключи, возникнут конфликты. Как мне с этим справиться? Я думал об использовании двух кешей - по одному для каждого типа - но (а) я не уверен, как это сделать, и (б) я где-то читал, что не рекомендуется использовать несколько кешей. Любые идеи?


person Fabricio Rodriguez    schedule 05.02.2019    source источник
comment
Использовать составной ключ? Например. пользователь_1, группа_1.   -  person juunas    schedule 05.02.2019
comment
Спасибо, juunas. Да, это действительно хорошее предложение!   -  person Fabricio Rodriguez    schedule 05.02.2019


Ответы (1)


Да, у меня была такая же проблема раньше, и я прибегал к созданию расширенной версии MemoryCache, которая позволяет мне подключать разные «хранилища». Вы можете сделать это, просто упаковав данные, которые вы ' повторно втыкаются в кеш в классе типа "метаданные". Я полагаю, это похоже на то, как дескрипторы ServiceDescriptors оборачивают ваши регистрации служб в DI?

Также в конкретном ответе на пункт «Я думал об использовании двух кешей - по одному для каждого типа». Вот где возникнет проблема, потому что я считаю, что IMemoryCache по умолчанию регистрируется как синглтон.

person Robert Perry    schedule 06.02.2019
comment
Спасибо, Роберт. Это тоже очень хорошее предложение. На данный момент я выбрал более простое решение, предложенное juunas, но вполне могу переключиться на ваш метод. Должен сказать, ваше решение звучит как более элегантное ... - person Fabricio Rodriguez; 06.02.2019