Руководящее аннулирование кэша

Я попробовал почти каждый obfuscator на рынке, и SmartAssembly является лучшим, по-моему.

16
задан super9 14 November 2009 в 12:37
поделиться

6 ответов

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

Для этого у вас есть два решения:

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

Первое встречается довольно редко, но довольно с этим легко справиться: просто обновляйте кеш на регулярной основе.

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

  • Добавьте новый объект в кэш сразу после того, как вы успешно добавили его в свою базу данных.
  • Обновите объект в кэше сразу после того, как вы успешно обновили его в своей базе данных.
  • Удалите объект из кеша сразу после того, как вы успешно удалили его в своей базе данных.

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

12
ответ дан 30 November 2019 в 17:52
поделиться

См. Эту статью и связанный с ней вопрос о переполнении стека .

В целом аннулирование кеша может быть довольно сложным, особенно при обновлении кэшированных объектов.

2
ответ дан 30 November 2019 в 17:52
поделиться

Общие решения вы можете найти по ссылке, предоставленной Джухой.

Но, отвечая на ваш вопрос, я хотел бы описать, как это делается в нашем проекте.
Мы не используем никаких общих решений для кешей. Наш кеш со временем увеличился. Изначально у нас вообще не было намерения использовать кеш. Но позже родился тайник. Поскольку кеш был добавлен в систему недавно, он не знает ни «базы данных», ни других «умных вещей». Вместо этого мы тщательно проверяем, не изменяет ли кто-нибудь кеш. Итак, я бы назвал наш кеш «управляемым алгоритмом».

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

Я знаю, чтобы описать такое базовое функциональность может показаться глупой. Можно сказать, что «в первую очередь пришлось использовать нормальный кеш». Но знаете, на самом деле иногда некоторые вещи просто выходят из-под вашего контроля, и вам просто нужно делать все, что в ваших силах.

Итак, подведем итог: нам не нужно общее решение. Наши алгоритмы управляют кешем. Это сохраняет кеш маленьким (как в коде, так и в памяти во время выполнения). Это наш подход.

0
ответ дан 30 November 2019 в 17:52
поделиться

Как вы, наверное, уже поняли, это не так просто, как, например, обновление кеша новостной статьи, когда обновления новостей. Есть и другие отношения, например, списки последних новостей, которые вам необходимо обновить.

Самый простой способ сделать это - связать все связанные объекты. Ранее я использовал концепцию групп кэша . Продолжая мой пример новостей, в группе кэша 'news' будет; новости, различные списки новостей и все остальное, что содержит новости.

Когда я редактирую новость, система распознает, что ей необходимо обновить группу кэша 'новости', и переходит через следующий процесс ...

  1. получить каждый объект перед сохранением обновлений
  2. save
  3. получить объект снова, если это другое обновление, различные кеши

Это, конечно, очень простой пример. Гораздо более аккуратный способ сделать это - написать код, чтобы всегда поддерживать объект в том виде, в каком он был бы в кеше.

Если вы добавите тег к новостной статье, ваш код может просто записать эти изменения в базу данных, но если вместо этого вы обновляете объект новостной статьи и соответствующий объект тега, оба эти два объекта могут «знать»

10
ответ дан 30 November 2019 в 17:52
поделиться

Если вы используете SQL Server 2005 или новее и .NET, вы можете изучить использование класса SQLDependency . Этот класс использует SQL Server Service Broker, чтобы уведомить вас о внесении определенных изменений в ваши данные. Вы можете использовать это как триггер для аннулирования вашего кеша. Опять же, это применимо, только если вы используете эти технологии.

3
ответ дан 30 November 2019 в 17:52
поделиться

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

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

Можно ли каким-то образом ссылаться на отношения из таблицы в базе данных и каким-то образом обеспечивать их соблюдение?

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

Потерпите меня, я никогда раньше не занимался кэшированием.

В зависимости от сложности ваших потребностей, это может оказаться непростой задачей. Возможно, вам стоит использовать или посмотреть существующие решения. В мире Java EHCache , OSCache , SwarmCache , JBoss Cache 2 делают кеши недействительными (или поддерживают Это). Это всего лишь предложение, поскольку вы не упомянули ни одного языка.

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

Потерпите меня, я никогда раньше не занимался кэшированием.

В зависимости от сложности ваших потребностей, это может оказаться непростой задачей. Возможно, вам стоит использовать или посмотреть существующие решения. В мире Java EHCache , OSCache , SwarmCache , JBoss Cache 2 делают кеши недействительными (или поддерживают Это). Это всего лишь предложение, поскольку вы не упомянули ни одного языка.

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

Потерпите меня, я никогда раньше не занимался кэшированием.

В зависимости от сложности ваших потребностей это может оказаться непростой задачей. Возможно, вам стоит использовать или посмотреть существующие решения. В мире Java EHCache , OSCache , SwarmCache , JBoss Cache 2 делают кеши недействительными (или поддерживают Это). Это всего лишь предложение, поскольку вы не упомянули ни одного языка.

В зависимости от сложности ваших потребностей это может оказаться непростой задачей. Возможно, вам стоит использовать или посмотреть существующие решения. В мире Java EHCache , OSCache , SwarmCache , JBoss Cache 2 делают кеши недействительными (или поддерживают Это). Это всего лишь предложение, поскольку вы не упомянули ни одного языка.

В зависимости от сложности ваших потребностей это может оказаться непростой задачей. Возможно, вам стоит использовать или посмотреть существующие решения. В мире Java EHCache , OSCache , SwarmCache , JBoss Cache 2 делают кеши недействительными (или поддерживают Это). Это всего лишь предложение, поскольку вы не упомянули ни одного языка.

0
ответ дан 30 November 2019 в 17:52
поделиться
Другие вопросы по тегам:

Похожие вопросы: