Время истечения срока действия memcached

Memcached предоставляет параметр времени истечения срока действия кеша, который указывает, как долго сохраняются объекты в кеше. Предполагая, что все записи проходят через кеш, я не понимаю, почему когда-либо захочется удалить объект из кеша. Другими словами, если все операции записи обновляют кеш перед БД, тогда кеш никогда не может содержать устаревший объект, поэтому зачем его удалять?

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

Спасибо, Дон

Ответ 1

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

Некоторые кешированные значения основаны на большом наборе данных, а недействительность кеша или запись новых значений непрактична. Это часто справедливо для сводных данных или данных, вычисленных из большого набора исходных данных.

Ответ 2

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

Они оба сказали, что они обычно используют что-то вроде 3-х часового времени истечения по умолчанию как своего рода "на всякий случай".

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

Итак, я думаю, ответ на вопрос "Почему?" действительно, "Почему бы и нет?". Это не будет стоить вам многого, чтобы истечь там, и это, вероятно, только поможет гарантировать, что вы не сохраняете устаревшие данные в кеше.

Ответ 3

В одном случае значение будет действительным только в течение определенного периода времени.

Ответ 4

Некоторые данные в кеше дороги для создания, но небольшие (должны длиться долгое время), а некоторые большие, но относительно дешевые (должны длиться более короткое время)

Кроме того, для большинства приложений трудно сделать memcached работать как кеш записи. Трудно правильно аннулировать все кеши, особенно тех, которые были сделаны на страницах. Большинство пользователей пропустят пару.

Ответ 5

Мы думали об одном и том же, и это то, что находится на memcached wiki "Даже если вы активно удаляете или перезаписываете кэшированные данные, вы все равно хотите, чтобы кэш истек изредка. Если ваше приложение имеет ошибку, сбой, сетевая ошибка или какая-либо другая проблема, при которой кеш может перестать синхронизироваться".

Это имеет смысл, поскольку мы не можем планировать сетевые ошибки, и становится важным, если мы выпускаем код каждый день или 2 или неделю. мы думаем, что мы должны перезапустить сервер memcached на каждом выпуске, но это станет очень болезненным, если есть 10 или более серверов memcached. Самое простое, что я считаю, это установить срок действия на объекты.

Ответ 6

Я бы сказал, что речь идет о различии между "Least Recent Used" и "Not Gonna Be Used Anymore"... если вы можете явно указать, какие объекты можно извлечь из кеша, что оставляет больше места для объектов которые могут быть использованы позднее.

Ответ 7

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

LRU имеет два правила при определении того, что нужно выкинуть, и делает это в следующем порядке:

Истекшие плиты
Старая неиспользуемая плита

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

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

Ответ 8

Существует несколько причин:

Хранилище данных не сохраняется между перезапусками сервера. После перезагрузки или перезагрузки кэширующего сервера вам придется регенерировать большие данные кеша.
Бывают случаи, когда вы не уведомлены, когда объект обновлен. например. Сведения о пользователе, возвращаемые API.
Поиск объекта. SQL предоставляет одни и те же данные для генерации разных результатов в зависимости от требований, таких как недавние и наиболее голосованные и т.д. Вам придется использовать разные ключи кеша для хранения данных для таких разных результатов (дублирование данных, головная боль для обновления всех соответствующих ключей, даже если общие общие данные). Также с сервером баз данных вы получаете большую гибкость при просмотре данных (пользовательские настройки и т.д.).