Один против нескольких экземпляров MemoryCache

Question

MemoryCache по умолчанию поставляется с кэшем по умолчанию, и могут быть созданы дополнительные именованные кэши.

Кажется, что могут быть преимущества изоляции кэширования результатов разных процессов в разных экземплярах. Например, результаты запросов к индексу могут кэшироваться в кеше "IndexQueryResult", а результаты запросов к базе данных - в "DatabaseQueryResult". кэш. Это довольно надумано, но объясняет принцип.

Влияет ли давление памяти на один кеш, что приводит к вытеснению, на другие кеши вообще? Существуют ли различия в том, как .Net управляет несколькими кэшами по сравнению с тем, как он управляет одним?

Я трачу впустую свое время, размышляя над идеей использования нескольких кэшей, или в этом есть реальная ценность?

Answer 1

Я не могу говорить на первые несколько вопросов, и мне интересно услышать ответы на них.Тем не менее, я могу сказать, что у нас был хороший опыт использования нескольких кешей в нашем продукте.Вот преимущества, которые я вижу:

• Снижение вероятности коллизии ключей : Вместо того, чтобы придумать какую-то схему, чтобы гарантировать, что никакие два отдельных значения не заканчиваются одним и тем же ключоммы можем просто создать кеш, специфичный для данного типа репозитория, и знать, что, пока этот класс репозитория использует ключи, уникальные для его объектов, у нас не будет коллизий.
• Лучшая точность свытеснение кеша : тип репозитория, который «владеет» конкретным экземпляром кеша, может подписываться на определенные типы событий в общесистемной шине событий, чтобы он знал, когда необходимо очистить некоторые части кеша.Если нам повезет, он может определить ключи записей для очистки исключительно на основе аргументов опубликованного события.Однако это часто не так, и мы должны либо очистить весь кеш, либо пройтись по всем кэшированным значениям, чтобы выяснить, на какие из них влияет опубликованное событие.Если бы мы использовали один экземпляр кэша для всех типов данных в нашей системе, мы бы закончили обход множества несвязанных записей.Используя отдельные кэши, мы можем ограничить наш поиск значениями, за которые этот конкретный репозиторий отвечал за заполнение.

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