время истечения срока действия memcached
Создайте объект Timer и дайте ему TimerTask, который выполняет код, который вы хотите выполнить.
Timer timer = new Timer ();
TimerTask hourlyTask = new TimerTask () {
@Override
public void run () {
// your code here...
}
};
// schedule the task to run starting now and then every hour...
timer.schedule (hourlyTask, 0l, 1000*60*60); // 1000*10*60 every 10 minut
Преимущество использования объекта Timer заключается в том, что он может обрабатывать несколько Объекты TimerTask, каждый со своим временем, задержкой и т. Д. Вы также можете запускать и останавливать таймеры, пока вы держите объект Timer, объявляя его как переменную класса или что-то в этом роде.
6 ответов
Срок действия полезен, когда вам не нужна точная информация, вы просто хотите, чтобы она была точной с точностью до определенного времени. Итак, вы кэшируете свои данные (скажем) на пять минут. Когда данные понадобятся, проверьте кеш. Если он есть, используйте его. Если нет (поскольку срок его действия истек), тогда перейдите и вычислите значение заново.
Некоторые кешированные значения основаны на большом наборе данных, и аннулирование кеша или запись в него новых значений нецелесообразно. Это часто относится к сводным данным или данным, вычисленным из большого набора исходных данных.
Мне самому это было любопытно, когда я впервые начал работать с memcached. Мы спросили друзей, которые работали в hi5 и facebook (оба активно использовали memcached).
Они оба сказали, что обычно используют что-то вроде 3-часового срока действия по умолчанию как своего рода «на всякий случай».
- Для большинства объекты, не так уж дорого перестраивать их каждые 3 часа
- Если у вас есть какая-то ошибка, из-за которой вещи остаются кешированными, чего не должно быть иначе, это может уберечь вас от слишком больших проблем
Итак, я предполагаю ответ на вопрос «Почему?» действительно, «Почему бы и нет?». Наличие истечения срока действия не будет стоить вам больших затрат, и это, вероятно, только поможет убедиться, что вы не храните устаревшие данные в кеше.
В одном случае значение действительно только в течение определенного периода времени.
Я бы сказал, что речь идет о различии между «Наименее недавно использованными» и «Больше не будут использоваться» ... если вы можете явно указать, какие объекты могут быть извлечены из кеша, что оставляет больше места для объектов, которые можно использовать позже.
Некоторые данные в кеше создавать дорого, но они маленькие (должны храниться долгое время), а некоторые большие, но относительно дешевые (должны храниться меньше времени)
Кроме того, для большинства приложений это Трудно заставить memcached работать как запись через кеш. Трудно правильно сделать недействительными все кеши, особенно кеши отображаемых страниц. Большинство пользователей пропустят пару.
Если ваш дизайн предусматривает сквозной кэш для записи, у вас все еще есть проблема, связанная с ограничением памяти, выделенной для memcached, и здесь в игру вступает LRU.
LRU имеет два правила при определении того, что нужно выкинуть, и делает это в следующем порядке:
- Просроченные слэбы
- Самый старый неиспользуемый слэб
Предоставление разных сроков истечения для разных групп объектов может помочь сохранить в памяти данные, к которым реже обращаются, но которые дороже кэшировать, в то время как более часто используемые слэбы, которые все еще могут оказаться в конце очереди, но которые легко воссоздать, могут истечь.
Кроме того, многие ключи кэша становятся совокупностями других объектов, и если вы не используете хэш для поиска этих объектов, гораздо проще просто позволить объектам истечь через несколько часов, чем проактивно обновлять все связанные с ними ключи, и это также сохраняет соотношение попаданий/промахов, за которое вы фактически боретесь, используя memcached в первую очередь.