Вопрос: Какой кэш является хорошим?
Кэш, который решает проблему, — хороший кеш. Это предложение просто ерунда, эквивалентно белому коту, черному коту, а тот, кто ловит мышей, — хороший кот.
Итак, исходя из решения проблемы, какой кеш является лучшим? Мой ответ на этот вопрос: кеш с высокой частотой попаданий в кеш — хороший кеш.
В предположении решения проблемы кэш с высокой частотой попаданий может потребовать меньших инвестиций в оборудование, чем кэш с низкой частотой попаданий. В то же время количество кешей может быть меньше, чем количество кешей с низкой частотой попаданий. Таким образом, скорость адресации определенно будет выше. Таким образом, кеш с высокой частотой попаданий — хороший кеш.
Скорость попадания в кэш
После того, как кэшированный объект был добавлен в кеш, если он ни разу не использовался внешним миром, пока объект кэшируется (в течение жизненного цикла кэшируемого объекта), коэффициент попадания кэшированного объекта равен 0. Чем больше раз запрашивается этот объект, тем выше вероятность попадания в его кэш.
Выше упоминается частота попадания объекта в кеш. Для кеша в целом его частота попаданий представляет собой диаграмму распределения частоты попаданий для каждого кэшированного индивидуума, указанного выше.
По кэшированию: обычно наиболее часто используемые особи составляют очень небольшую часть от общего числа. Наименее часто используемые составляют значительную часть общего числа.
Поэтому мы часто видим такие данные:
Из 10 000 кэшированных элементов 100 используются часто, почти каждую минуту. 2000 фрагментов данных, запрашиваемых раз в час. Раз в сутки запрашивается 3000 фрагментов данных, а остальные данные не использовались ни разу после заброса в кэш.
В настоящее время аппаратное обеспечение быстро развивается. Если нам нужно кэшировать только 10 000 данных, мы можем полностью закинуть в кеш все 10 000 данных независимо от того, используются ли они. Таким образом, пока мы ищем данные, они у нас обязательно будут. данные в кэше. Нет необходимости выполнять дополнительные операции или делать запросы к базе данных.
Однако: аппаратное обеспечение быстро развивается, как и объем данных. Для небольшого веб-сайта, если кэшируется 10 000 фрагментов данных, все они будут кэшированы. Однако на крупных веб-сайтах хранятся как минимум миллионы данных или данных Т-уровня. Очевидно, что все эти данные нельзя забросить в кеш. В настоящее время очень важно разработать разумное решение для кэширования и повысить частоту попадания в кэш. И это необходимо.
Некоторые распространенные методы повышения скорости попадания в кеш
С чисто технической точки зрения мы записываем только количество пользовательских запросов в единицу времени и на основе этой информации кэшируем наиболее часто используемые данные.
Но чаще всего мы улучшаем скорость попадания в кеш на основе бизнес-логики. Например: в прошлом году и в блоге, опубликованном в позапрошлом году, запросы на просмотр статей этого типа обычно поступали как минимум несколько раз в день. Обычно не следует кэшировать в памяти.
Другой пример: сообщение с большим количеством ответов обычно будет просматривать больше людей, чем сообщение с меньшим количеством ответов.
Мы должны использовать приведенную выше логику и предоставить алгоритм кэширования, основанный на нашей реальной бизнес-логике, чтобы улучшить скорость попадания в кеш. Давайте кэшировать соответствующие данные, а не все данные, как позволяет наше оборудование.
Отрицательный пример: несмотря ни на что, на большом блоге, когда пользователь запрашивает статью, обнаруживается, что ее нет в кеше памяти, поэтому она считывается из базы данных, а затем бросается в кеш.
Знаете, краулеров сейчас очень много. Кроме того, на дружественных поисковым системам сайтах, таких как блоги, большая часть давления доступа исходит от поисковых систем. Эти посещения обычно длятся один час или один день, с несколькими или даже одним запросом определенной статьи, а затем никогда больше. Вероятность попадания при использовании вышеуказанного метода кэширования будет очень низкой.
Кто-то может спросить здесь, Го Хунцзюнь, поскольку вы не предлагаете мне кэшировать содержимое этих блогов, но как я могу улучшить производительность своего сайта, я должен хотя бы гарантировать, что мой блог не будет слишком медленно отвечать? на запросы пользователей.
Существует множество решений этой проблемы. Один из самых простых способов — превратить эти блоги в статические HTML-страницы, которые представляют собой кэш файловой системы. Благодаря жесткому диску файловую систему можно рассматривать как бесконечно расширяемую. так что большая часть контента с низкой частотой попаданий кэшируется.
Если ваша страница требует некоторой динамической логической оценки, вы можете кэшировать данные в файлы XML, а затем сегмент сервера интегрирует эти файлы XML или включает файлы. Это тоже хороший подход.
Сказав так много вопросов о скорости попадания в кеш, давайте кратко суммируем взгляды на скорость попадания в кеш:
Небольшие веб-сайты могут кэшировать все данные, и, как правило, нагрузка не будет большой, поэтому проблемы с частотой попадания в кэш можно игнорировать.
Большие сервисы не могут кэшировать все данные, а только часть данных. На данный момент архитектору необходимо разработать метод кэширования, подходящий для бизнес-логики, чтобы максимально повысить скорость попадания в кэш.
Большинство методов повышения результативности завязаны на бизнес-логике и требуют детального анализа конкретных проблем. Для данных, которые невозможно кэшировать в памяти, самый простой способ повысить производительность — использовать файловое кэширование.
Кэширование файлов может кэшировать весь контент в статический файл; оно также может кэшировать область всей страницы в файл, а затем включать ее в сериализацию объекта в XML-файл для кэширования;
Давайте посмотрим на несколько других, менее важных аспектов кэширования:
Действия жизненного цикла кэша
Контент, срок действия которого никогда не истекает или изменяется навсегда, не следует помещать в кеш. Кэш — это временное хранилище, а не постоянное, поэтому жизненный цикл кэша ограничен.
В свою очередь, он может осуществлять следующие действия:
Введите кэш. (При входе в кэш вам может потребоваться указать его будущую политику истечения срока действия. Если не указано, вам необходимо использовать системную политику истечения срока действия по умолчанию)
Получите его из кэша. Обратите внимание, что на данный момент необходимо решить проблемы безопасности потоков.
При обновлении кеша обратите внимание, что вам также необходимо учитывать проблемы безопасности потоков при выходе из кеша. Это может быть внешний запрос, или кеш может очистить его в соответствии с политикой истечения срока действия.
Политика истечения срока действия кэша
Обычно я хотел бы спросить, с какими стратегиями истечения срока действия кэша вы сталкивались в кэшах, с которыми вы контактировали?
Наиболее распространенными стратегиями экспирации являются следующие:
Если он не запрашивался в течение длительного времени, срок его действия истечет. Наиболее типичным является функция раздела, предоставляемая ASP и ASP.net. По сути, это кэш.
Кэш, основанный на изменениях файлов, истечет после изменения файла (обычно Web.config веб-сайта). После изменения файла не только кэш будет перезапущен, но и процесс IIS также выполнит выпуск.
На основании этого вы можете увидеть политики истечения срока действия кэша для многих зависимостей. Например, политика истечения срока действия кэша, основанная на базе данных.
Конечно, в бизнес-логике могут быть более сложные стратегии истечения срока действия. В новой версии форума системы баллов CSDN кэш списка сообщений очистит его до 550 фрагментов данных, когда кэш данных списка достигнет 600.
Другой пример: срок действия кэша новых сообщений на форуме, основанных на баллах, истекает, когда ни один список не ссылается на это сообщение, и срок действия сообщения истекает.
Проблема с синхронизацией кэша
Использование кэша означает, что могут сосуществовать несколько копий одних и тех же данных. Если ваш код не учитывает определенную ситуацию, эти два данных будут противоречивыми. Вот тогда и возникнут проблемы.
Решение простое. Тщательно продумайте свою бизнес-логику и ситуации срабатывания кода и не оставляйте незавершенных областей.
Простые методы могут сделать логику вашего кода очень сложной.
Вот почему некоторые люди рекомендуют не использовать кеширование, когда в этом нет необходимости. Как только вы начнете использовать кэширование, вы должны быть готовы добавить много кода для синхронизации данных.
Инициализация и заполнение данных кэша
Иногда после инициализации кэша некоторые данные необходимо предварительно заполнить в кэше. Это операция инициализации кэшированных данных.
Во время операции инициализации кэшированных данных необходимо учитывать следующие проблемы:
Сколько времени занимает инициализация? Обычно, если это сайт, мы можем выполнить эту работу по инициализации в Application_OnStart Global.asa. Инициализация обычно не может занимать слишком много времени. В настоящее время тестируется наша способность оптимизации кода.
Во время инициализации данные обычно импортируются пакетами, а не обрабатываются по одному при обычном использовании.
Подведите итог:
В этой статье представлены некоторые мои взгляды на кэширование, не вдаваясь в подробности конкретных технологий кэширования. Я надеюсь, что благодаря описанию этой статьи люди, которые знают только об использовании кэширования, но не понимают саму идею кэширования, смогут получить предварительное понимание.
http://blog.csdn.net/ghj1976/archive/2007/09/01/1768676.aspx