AXAMIT logo
Домашняя Страница Блог 2016 AEM Dispatcher. Часть 4: Инвалидация кэша

AEM Dispatcher. Часть 4: Инвалидация кэша

AEM Dispatcher. Часть 4: Инвалидация кэша

Предыдущие части:


Многие из нас скорее всего сталкивались с ситуацией, когда диспетчер использует старую версию кода (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-агенты для автоматической инвалидации после публикации страниц и запросы для инвалидации вручную.

Подробная и полезная документация доступна на следующих страницах:

Автор: Виталий Киселев, AEM Разработчик

Автор

Виталий Киселев
  • Виталий Киселев
  • Certified AEM Developer