Cache tags

30/04/2020, by maria

Cache tags = зависимости данных

Cache tags описывают зависимости от данных, управляемых Drupal

Почему?

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

Это важно для Системы управления контентом/Framework, такой как Drupal, потому что один и тот же контент может быть повторно использован разными способами. Другими словами: невозможно заранее знать, где будет использоваться какой-либо контент. В любом месте, где используется контент, он может кэшироваться. Это означает, что один и тот же контент может быть кэширован в десятках мест. Что приводит нас к известной цитате. В информатике есть только две серьезные проблемы: аннулирование кэша и присвоение имен. - то есть, как вы собираетесь аннулировать все элементы кэша, где используется контент?

Примечание: Drupal 7 предлагает 3 способа аннулирования элементов кэша: сделать недействительным определенный CID, сделать недействительным использование префикса CID или сделать недействительным все в корзине кеша. Ни один из этих трех методов не позволяет нам аннулировать элементы кэша, которые содержат измененную сущность, потому что это было невозможно узнать!

Какая?

Тег кеша - это строка.

Кэшированные теги передаются в наборах (порядок не имеет значения) строк, поэтому они печатаются в string[]. Это наборы, потому что один элемент кэша может зависеть от многих тегов кэша.

Syntax

По соглашению, они имеют форму thing:identifier - и когда нет понятия нескольких экземпляров вещи, она имеет форму thing. Единственное правило заключается в том, что он не может содержать пробелы.

Там нет строгого синтаксиса.

Примеры:

node:5 - тег кеша для Node узла 5 (аннулируется всякий раз, когда он изменяется)
user:3 - тег кеша для объекта User 3 (становится недействительным при каждом его изменении)
node_list - список тегов кэша для объектов Node (аннулируется всякий раз, когда любой объект Node обновляется, удаляется или создается, т. е. когда может потребоваться изменить список узлов). Применимо к любому типу сущности в следующем формате: {entity_type} _list.
config:system.performance - тег кеша для конфигурации system.performance
library_info - тег кеша для библиотек активов

Общие теги кеша

Данные, которыми управляет Drupal, делятся на 3 категории:

entities - у них есть теги кэша вида <entity type ID>:<entity ID>, а также <entity type ID>_list и <entity type ID>_list:<bundle> для аннулирования списков сущностей. Типы объектов конфигурации используют тег кеша базового объекта конфигурации.
configuration - они имеют теги кеша в форме config:<configuration name>
пользовательский "custom" (например, library_info)

Drupal предоставляет кеш-теги для сущностей и конфигурации автоматически - см. Базовый класс Entity и базовый класс ConfigBase. (Все конкретные типы сущностей и объекты конфигурации наследуются от них.)

Хотя многие типы объектов следуют за предсказуемым форматом тега кэша <entity type ID>:<entity ID>, сторонний код не должен полагаться на это. Вместо этого он должен получить теги кеша для аннулирования для единственного объекта, используя метод : :getCacheTags(), например, $node->getCacheTags(), $user->getCacheTags(), $view->getCacheTags() и т. д.

Кроме того, может потребоваться аннулировать кэши на основе списков, которые зависят от данных от рассматриваемой сущности (например, обновлять визуализированный HTML для листинга при создании новой сущности для него): это можно сделать с помощью EntityTypeInterface::getListCacheTags(), затем делает недействительными любые возвращенные этим методом вместе с собственными тегами объекта. Начиная с Drupal 8.9 (уведомление об изменении), сущности с пакетами также автоматически имеют более конкретный тег кеша, который включает их пакет, чтобы обеспечить более целенаправленное аннулирование списков.

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

function yourmodule_node_presave(NodeInterface $node) {
  $tags = [];
  if ($node->hasField('field_category')) {
    foreach ( $node->get('field_category') as $item) {
     $tags[] = 'mysite:node:category:' . $item->target_id;
    }
  }
  if ($tags) {
      Cache::invalidateTags($tags);
  }
}

Эти теги можно использовать в коде и в представлениях, используя предоставленный модуль Views Custom Cache Tag.

Примечание. В настоящее время не существует API для получения отдельных пакетов и более конкретных тегов кэша от объекта или другого объекта. Это связано с тем, что не тот объект, который решил, какие теги кэша списка являются релевантными для определенного списка / запроса, зависит от самого запроса. Будущие версии ядра Drupal, вероятно, улучшат встроенную поддержку кеш-тегов для каждого пакета и, например, интегрируют их в построитель запросов сущностей и представления.

Как

Настройка

Любой кеш-сервер должен реализовывать CacheBackendInterface, поэтому при установке элемента кеша с помощью метода ::set() укажите третий и четвертый аргументы, например:

$cache_backend->set(
  $cid, $data, Cache::PERMANENT, ['node:5', 'user:7']
);

Это хранит элемент кэша с идентификатором $cid постоянно (то есть хранится неопределенно долго), но делает его подверженным аннулированию через теги кеша node:5 или user:7

Утратившие силу

Теговые элементы кэша становятся недействительными через их теги, используя cache_tags.invalidator:invalidateTags() (или, когда вы не можете внедрить cache_tags.invalidator службы: Cache::invalidateTags()), которая принимает набор тегов кэша (string[]) ,

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

Отладка

Все вышеперечисленное является полезной информацией при отладке чего-либо, что кэшируется. Но есть еще одна вещь: скажем, что-то кэшируется с помощью тегов кеша ['foo', 'bar']. Тогда соответствующий элемент кэша будет иметь столбец тегов (если на мгновение предположить, что кэш базы данных) со следующим значением:

bar foo

Другими словами:

теги кеша разделены пробелом
теги кеша сортируются по алфавиту

Это должно облегчить анализ и отладку кешей!

Заголовки (отладка)

Наконец: легко увидеть, от каких тегов кеша зависит определенный ответ (и, следовательно, он становится недействительным): достаточно взглянуть только на заголовок X-Drupal-Cache-Tags!

(Именно поэтому пробелы запрещены: потому что заголовок X-Drupal-Cache-Tags, как и многие HTTP-заголовки, использует пробелы для разделения значений.)

Примечание. Если вы не видите эти заголовки, вам нужно настроить экземпляр Drupal для разработки.

Интеграция с обратными прокси

Вместо того, чтобы кэшировать ответы в Drupal и делать их недействительными с помощью тегов кэша, вы также можете кэшировать ответы в обратных прокси (Varnish, CDN ...) и затем делать недействительными ответы, которые они кэшировали, используя теги кэша, связанные с этими ответами. Чтобы эти обратные прокси-серверы знали, какие теги кэша связаны с каждым ответом, вы можете отправить теги кэша вместе с заголовком.

Так же, как Drupal 8 может отправлять заголовок X-Drupal-Cache-Tags для отладки, он также может отправлять заголовок Surrogate-Keys со значениями, разделенными пробелами, как ожидается некоторыми CDN, или заголовок Cache-Tag со значениями, разделенными запятыми, как и ожидалось другими CDN. И это также может быть обратный прокси-сервер, который вы запускаете самостоятельно, а не коммерческий сервис CDN.

Как правило, рекомендуется, чтобы и ваш веб-сервер, и ваш обратный прокси-сервер поддерживали заголовки ответов со значениями до 16 КБ.

1. HTTP является текстовым. Кэшированные теги поэтому также основаны на тексте. Обратные прокси могут свободно представлять теги кеша внутри другой структуры данных. Предел значения заголовка ответа в 16 КБ был выбран на основе 2 факторов: A), чтобы убедиться, что он работает в 99% случае, B) что практически достижимо. Типичные веб-серверы (Apache) и типичные CDN (быстро) поддерживают значения заголовка ответа 16 КБ. Это означает примерно 1000 тегов кеша, что достаточно для 99% случаев.
2. Количество тегов кеша сильно варьируется в зависимости от сайта и конкретного ответа. Если это ответ, который зависит от многих других вещей, будет много тегов кеша. Более 1000 кеш-тегов в ответе будут редкими.
3. Но, конечно, это руководство (достаточно ~ 1000 тегов / ответ) может и будет развиваться с течением времени, так как мы A) видим, как его используют все больше реальных приложений, B) видят, что системы специально используют / строят поверх этой возможности.

Наконец, все, что находится за 1000 тегов кеша, вероятно, указывает на более глубокую проблему: что ответ слишком сложен, что его следует разделить. Ничто не мешает вам выйти за пределы этого числа в Drupal, но это может потребовать ручной настройки. Что приемлемо для таких чрезвычайно сложных случаев использования. Возможно, это имеет место даже для гораздо менее 1000 тегов кеша.

Прочитайте документацию по использованию Varnish с тегами кеша.

Известно, что CDN поддерживают аннулирование/очистку на основе тегов:

CloudFlare
Fastly
KeyCDN
Akamai

Внутренний кэш страницы

Комплексное использование тегов кеша в Drupal 8 позволяет поставлять Drupal 8 с включенным по умолчанию внутренним кэшем страниц. Это не что иное, как встроенный обратный прокси.

Смотрите также

Source URL: