Несколько недель назад Amazon объявила, что они снизили срок действия контента:
Amazon CloudFront понижает минимальный срок действия контента
Так много, что вы действительно можете установить TTL в CloudFront на 0. Так что мой вопрос в том, почему было бы полезно иметь дистрибутив CloudFront с TTL, установленным в 0. Мне это не означает никакого кэширования вообще, поэтому каждый запрос, который попадает в CloudFront, попадает в начало координат.
Что мне не хватает?
Эта новая функция Amazon CloudFront на самом деле чрезвычайно полезна для многих случаев использования, потому что поражение начала работает немного иначе, чем кажется на первый взгляд и не обязательно является проблемой, наоборот; в то время как эта функция была выпущена ранее, все это происходит вместе с недавним выпуском Amazon CloudFront - поддержка динамического содержимого, например. для рассматриваемого вопроса:
Переменная время жизни (TTL). Во многих случаях динамический контент является либо не кэшируемым или кэшируемым в течение очень короткого периода времени, возможно всего несколько секунд. В прошлом минимальный TTL CloudFront составлял 60 минут, поскольку все содержимое считалось статичным. Новый минимальный TTL значение - 0 секунд. Если вы установили TTL для определенного источника в 0, CloudFront будет кэшировать содержимое из этого источника. Тогда сделать запрос GET с заголовком If-Modified-Since, тем самым источник имеет шанс сигнализировать, что CloudFront может продолжать использовать кешированный контент, если он не изменился в начале. [акцент мой]
Другими словами, использование TTL 0 в первую очередь означает, что CloudFront делегирует полномочия для управления кешем в начало координат, то есть сервер происхождения решает, будет ли или нет, и если надолго CloudFront кэширует объекты; обратите внимание, что запрос GET с заголовком If-Modified-Since не обязательно означает, что сам объект извлекается из источника, а источник может (и должен) возвращать код статуса HTTP 304 - не изменен, где применимо:
Указывает, что ресурс не был изменен с момента последнего запроса. [...] Используя это, экономия полосы пропускания и переработка на сервере и клиент, так как только данные заголовка должны быть отправлены и получены в сравнение со всей страницей, перерабатываемой сервер, а затем снова отправляется с использованием большей пропускной способности сервера и клиента. [акцент мой]
Внимательно ознакомьтесь с Марк Ноттингем Учебное пособие по кэшированию для получения подробной информации о механизме и преимуществах управления кешем HTTP, действительно важной и эффективной частью архитектуры HTTP.
Понимание того, как все эти части работают вместе, может быть немного трудным, соответственно, в таблице в разделе "Указание минимального времени, когда CloudFront кэширует объекты для загружаемых распределений в Указание Как длинные объекты остаются в кеше CloudFront Edge Cache (Object Expiration) пытается суммировать эффекты при применении в контексте CloudFront с или без TTL = 0.
Обратите внимание, что Amazon не говорит, что "TTL равно 0", он говорит: "Минимальное TTL равно 0". и это совсем другое. Описание, приведенное выше, очень желательно, но нет гарантии, что Cloudfront действительно это сделает.
В моих опытах прямо сейчас, я вижу, что кешированное изображение осталось на несколько минут в краю, пока мое происхождение уже изменилось.
Итак, я думаю, что "Минимальное TTL равно 0", вероятно, больше похоже на "Amazon не имеет строгого намерения сохранить это в кеше" и, возможно, "и он будет часто обновляться".
Для таких приложений, как CMS, где веб-пользователь публикует новый контент, я думаю, что TTL-0 все еще недостаточно. Вам все равно придется либо вызывать недействительности с CMS, либо использовать разные пути для разных номеров версий.