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

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

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

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

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

Ответ 1

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

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

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