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

Question

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

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

Спасибо, Дон

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

Есть несколько причин:

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

Answer 7

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

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

1. просроченные плиты
2. Самая старая неиспользованная плита

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

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

Answer 8

Я бы сказал, что речь идет о различии между «Наименее недавно использованным» и «Больше не будет использоваться» ... если вы можете явно указать, какие объекты можно извлечь из кэша, это оставляет больше места для объектов это может все еще использоваться позже.