Предыдущие части:
- Часть 1: Краткий обзор и назначение диспетчера
- Часть 2: Установка рабочей среды
- Часть 3: Настройки рабочей среды для включения кэширования
Многие из нас скорее всего сталкивались с ситуацией, когда диспетчер использует старую версию кода (CSS, HTML, JS). В этой статье я расскажу о правильной конфигурации инвалидации страниц на диспетчере чтобы таких проблем не возникало.
Инвалидация - это механизм для указания устаревших кэшированных ресурсов. Существуют несколько инструментов для автоматической инвалидации и инвалидации вручную. Но сперва давайте установим начальные настройки в секции инвалидации конфигурационного файла диспетчера, затем изучим, как инвалидация происходит на низком уровне, а уже после этого наконец-то вернемся к изучению инструментов для инвалидации.
Начальные настройки секции инвалидации
Внутри секции /cache находится блок /invalidate, который устанавливает кэшированные файлы, доступные для автоматической инвалидации при обновлении контента. Например, следующие настройки устанавливают инвалидацию всех HTML страниц:
/cache
{
/invalidate
{
/0000 { /glob "*" /type "deny" }
/0001 { /glob "*.html" /type "allow" }
}
}
При автоматической инвалидации диспетчер не удаляет кэшированные файлы сразу после обновления контента, а проверяет их валидность при ближайшем запросе. Кэшированные документы, которые не инвалидируются автоматически, останутся в кэше до тех пор, пока в процессе обновления контента не будут удалены явно. В демонстрационных целях давайте позволим автоматическую инвалидацию для всего кэша:
/cache
{
/invalidate
{
/0000 { /glob "*" /type "allow" }
}
}
Перезапустите httpd-сервер после обновления секции /invalidate для применения новых изменений.
Инвалидация в подробностях
На низком уровне диспетчер использует специальные пустые стат-файлы с именем по умолчанию ".stat". По умолчанию установлен параметр /statfileslevel "0", что подразумевает использование только одного стат-файла, располагающегося в корне папки htdocs. Если время изменения стат-файла более позднее, чем время изменения ресурса, тогда диспетчер расценивает такой ресурс устаревшим или невалидным.
Например, пусть у нас есть следующие кэшированные ресурсы после запроса страницы http://localhost/content/geometrixx/en/products.html :
Давайте инвалидируем их, применяя низкоуровневый механизм стат-файлов. Создайте пустой файл с именем ".stat" в корне вашей папки htdocs:
Обратите внимание, что время изменения стат-файла более позднее, чем кэшированных ресурсов. Для диспетчера это означает, что все ресурсы устаревшие. Это и есть низкоуровневый механизм инвалидации. Если мы после создания такого стат-файла снова посетим страницу http://localhost/content/geometrixx/en/products.html, то запрашиваемые кэшированные ресурсы будут обновлены:
Этот пример иллюстрирует схему инвалидации с параметром по умолчанию /statfileslevel "0". Давайте разберёмся, как мы можем настроить инвалидацию более тонко и детально при помощи параметра /statfileslevel.
Настройка параметра /statfileslevel
Вы можете пользоваться свойством /statfileslevel в конфигурационном файле диспетчера для выборочной инвалидации кэшированных файлов соответственно их путям. У механизма работы свойства /statfileslevel есть несколько правил:
- Диспетчер создаёт .stat файлы в каждой папке начиная от docroot и до уровня, который вы указываете. Уровень папки docroot равен 0.
- При обновлении файла диспетчер по пути файла находит папку, лежащую на уровне statfileslevel и инвалидирует все файлы этой папки и все файлы, лежащие ниже внутри этой папки.
- Если уровень обновлённого файла меньше уровня statfileslevel, тогда инвалидируются только файлы папки, содержащей обновлённый файл, но файлы, лежащие ниже внутри этой папки остаются валидными.
- При обновления файла все файлы соответствующей папки и выше вплоть до корневого уровня включительно станут невалидными.
Для лучшего понимания правил свойства /statfileslevel давайте рассмотрим парочку примеров. Наш демонстрационный случай по умолчанию, в котором /statfileslevel "0", выглядит следующим образом:
Есть только один стат-файл в корневой папке docroot. А область ответственности или зона охвата этого стат-файла будет целиком всё файловое дерево нашего docroot. Если у какого-то файла дерева дата изменения старше даты изменения стат-файла, тогда диспетчер расценивает такой файл невалидным.
Если мы установим /statfileslevel "4", тогда инвалидация работает уже вот так:
Стат-файлы есть на всех уровнях начиная от 0 (корень) до 4 включительно.
Стат-файл на уровне меньше 4 обладает областью ответственности или зоной охвата только содержащей его папки. Это означает, что если стат-файл внутри папки content/geometrixx/en новее, чем какой-то файл из этой папки, то такой файл является невалидным, но валидация всех файлов из остальных папок определяется другими стат-файлами.
Только стат-файлы, лежащие на уровне со значением statfileslevel (в нашем случае уровень равен 4), обладают областью ответственности или зоной охвата всего нижележащего дерева, начинающего от папки, содержащей такой стат-файл и простирающегося вниз до более низких уровней файлового дерева. Это означает, что если у стат-файла внутри папки content/geometrixx/en/products время изменения новее, чем у какого-то файла из нижележащего файлового дерева, включающего папку products, тогда диспетчер считает такой файл невалидным. Валидация всех файлов, которые не находятся в этом дереве, определяется другими стат-файлами.
Автоматическая инвалидация и flush-агенты
В целях автоматизации инвалидации вы можете включить авторские или публичные flush-агенты. Рекомендуется пользоваться публичным flush-агентом для более надёжной автоматической инвалидации, потому что использование авторского flush-агента может вызывать следующие проблемы:
- Диспетчер должен быть доступен для авторского AEM-сервера. Если ваша сеть (например, из-за файрвола) настроена так, что доступ между обоими закрыт, тогда автоматическая инвалидация работать не будет.
- Публикация и инвалидация кэша происходит одновременно. Пользователь может запросить страницу сразу после того, как она была удалена из кэша, но ещё до того, как страница была опубликована. В такой ситуации AEM возвращает старую страницу, а диспетчер эту старую страницу кэширует снова и считает её теперь валидной. Эта проблема больше касается крупных сайтов.
Публичный flush-агент находится по адресу http://localhost:4503/etc/replication/agents.publish/flush.html
Для включения публичного flush-агента нажмите кнопку "Edit" и установите галочку в чекбоксе "Enabled":
Также обновите URI порт на вкладке Transport и установите его значение равным 80:
Сохраните ваши изменения, и вы увидите, что публичный flush-агент активировался:
Запросы для инвалидации вручную
Вы можете отправлять следующие запросы для того, чтобы вручную инвалидировать ваши кэшированные ресурсы:
- для удаления кэшированных файлов
POST /dispatcher/invalidate.cache HTTP/1.1 CQ-Action: Activate CQ-Handle: path-pattern Content-Length: 0 - для удаления и перекэширования файлов
POST /dispatcher/invalidate.cache HTTP/1.1 CQ-Action: Activate Content-Type: text/plain CQ-Handle: path-pattern Content-Length: numchars in bodypage_path0 Page_path1 … Page_pathn
Резюме
В итоге мы узнали, как работают механизм инвалидации на низком уровне, flush-агенты для автоматической инвалидации после публикации страниц и запросы для инвалидации вручную.
Подробная и полезная документация доступна на следующих страницах:
- http://docs.adobe.com/docs/en/dispatcher/disp-config.html
- http://docs.adobe.com/docs/en/dispatcher/page-invalidate.html
Автор: Виталий Киселев, AEM Разработчик
