срок действия memcached

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Плиты с истекшим сроком годности
2. Самая старая неиспользованная плита

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

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

Причин несколько:

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