Управляемый кеш в Битрикс: теги, файлы и сброс

В 1С-Битрикс изменение одного элемента инфоблока может сделать устаревшими десятки страниц, блоков и результатов ORM-запросов. Управляемый кеш решает эту задачу через теги: кешированная выборка связывается с сущностью, а после изменения сущности связанные записи помечаются устаревшими. Ниже — разбор для ветки «1С-Битрикс: Управление сайтом 24.x»: где лежат данные, как проходит чтение, почему очистка кеша иногда не помогает и что измерять перед изменениями.

Что именно управляет кешем в Битрикс

В Битрикс обычно пересекаются три разных механизма:

• обычный кеш хранит результат по идентификатору и времени жизни;
• управляемый кеш добавляет к записи связи с тегами и умеет сбрасывать её по событию;
• композитный кеш сохраняет уже собранный HTML страницы и работает на другом уровне.

Управляемый кеш не заменяет все остальные виды кеширования. Он отвечает за данные и фрагменты, которые приложение получает во время выполнения PHP: списки товаров, меню, свойства элемента, результат ORM-запроса. HTML, сохранённый композитным режимом, может оставаться старым даже после сброса управляемого кеша.

Главная особенность управляемого кеша — он знает не только «когда запись протухнет», но и «какое изменение делает её недействительной».

Как проходит чтение кешированной записи

1. Формируется идентификатор

Компонент или ваш код собирает строку из параметров запроса: идентификатора инфоблока, раздела, языка, страницы и других условий. Если параметр не попал в идентификатор, разные варианты результата могут записаться в один кеш.

Затем Битрикс проверяет запись в выбранном хранилище. В файловом режиме это обычно каталоги кеша внутри проекта; точный путь зависит от типа кеша, настроек и редакции продукта. Нельзя считать любой файл в /bitrix/cache управляемым: рядом могут находиться обычные записи компонентов.

2. Проверяется срок жизни

Запись с истёкшим TTL считается недействительной, даже если её файл физически ещё существует. При промахе код получает данные заново, регистрирует связи с тегами и записывает результат.

TTL^[1] — время, в течение которого запись считается действительной.

3. Запись связывается с тегами

Тег — это строковый идентификатор изменяемой сущности или группы сущностей. Для инфоблоков часто используются теги вида iblock_id_..., но точные теги и момент их регистрации зависят от компонента и способа выборки.

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

4. Изменение данных запускает сброс

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

Если запись создаётся вручную, а изменение выполняется прямым SQL или внешним импортом, штатное событие может не сработать. Это одна из частых причин, по которой администратор видит обновлённые данные в административной части, но старые значения на сайте.

Как регистрируется тег в собственном кеше

Для собственного D7-кеша в 1С-Битрикс 24.x можно использовать Bitrix\Main\Data\Cache и tagged cache. Ниже фрагмент без конкретного запроса к базе: он показывает порядок вызовов, а не готовый компонент.

<?php
use Bitrix\Main\Application;
use Bitrix\Main\Data\Cache;

$cache = Cache::createInstance();
$cacheId = 'catalog_' . $iblockId . '_' . $sectionId;
$cacheDirectory = '/catalog';
$cacheTtl = 3600;

if ($cache->initCache($cacheTtl, $cacheId, $cacheDirectory)) {
    $items = $cache->getVars();
} elseif ($cache->startDataCache()) {
    $taggedCache = Application::getInstance()->getTaggedCache();
    $taggedCache->startTagCache($cacheDirectory);
    $taggedCache->registerTag('iblock_id_' . $iblockId);
    $taggedCache->endTagCache();

    // Здесь должен быть ваш запрос и подготовка результата.
    $items = loadCatalogItems($iblockId, $sectionId);

    $cache->endDataCache($items);
}

В рабочем проекте перед таким фрагментом нужно проверить, что переменные определены, а функция загрузки действительно существует. После обновления данных через нестандартный импорт отдельно проверьте, вызывается ли событие, которое сбрасывает соответствующий тег.

Что ломается первым

Неполный ключ кеша

Кеш каталога может зависеть от города, группы пользователя, валюты и наличия товара. Если в идентификаторе оставить только ID раздела, первый сформированный вариант начнёт показываться всем. Это не проблема TTL и не лечится сокращением времени жизни.

Тег зарегистрирован не там

Тег нужно связать именно с той записью, которую требуется сбрасывать. Если тег создаётся после завершения кеширования или для другого пути, приложение продолжит читать старый результат. Проверяйте порядок startTagCache(), registerTag(), endTagCache() и финальной записи данных.

Данные меняются в обход Битрикс

Прямой SQL, импорт через отдельный скрипт или обновление таблиц сторонним модулем могут не запустить штатный сброс. Такой подход иногда быстрее на больших объёмах, но цену нужно считать вместе с ручной инвалидизацией кеша.

Смешаны уровни кеша

После изменения инфоблока управляемый кеш может быть сброшен, но пользователь всё ещё получает старую страницу из композитного кеша или из кеша reverse proxy. Диагностируйте путь ответа целиком: PHP, внутренний кеш Битрикс, композит и внешний прокси.

Управляемый кеш и полная очистка

Полная очистка — не универсальное лечение. После неё первый поток запросов одновременно начнёт строить результаты заново. На загруженном сайте это превращается в всплеск CPU, дисковых операций и запросов к базе. Если проблема относится к одному инфоблоку, сбрасывайте узкий набор тегов, а не весь кеш.

Как проверять поведение под нагрузкой

Готовых универсальных цифр для Битрикс нет: результат зависит от PHP-FPM, файловой системы, базы, объёма каталога и выбранного кеш-бэкенда. Сравнивайте один и тот же сценарий до и после изменения.

1. Зафиксируйте URL, размер выборки, авторизацию, PHP-версию, редакцию Битрикс и тип хранения кеша.
2. Измерьте время ответа, количество SQL-запросов, пиковую память PHP и долю ответов с попаданием в кеш.
3. Измените один элемент штатным способом и проверьте, исчез ли старый результат в затронутых блоках.
4. Повторите запрос после сброса и отдельно зафиксируйте стоимость «холодного» построения.
5. Запустите несколько параллельных запросов после очистки. Смотрите, не строят ли все процессы один и тот же результат одновременно.

Особенно важен последний тест. Управляемый кеш сокращает повторные вычисления после прогрева, но сам по себе не гарантирует отсутствие гонки при одновременном первом чтении.

Где управляемый кеш не подходит

Не кешируйте одним ключом результат, который меняется для каждого пользователя, если персональные параметры не входят в ключ. Не привязывайте огромный список товаров к одному тегу, если частое изменение одного товара будет сбрасывать весь список. И не используйте прямое удаление файлов как основной механизм инвалидизации.

Инвалидация композитного HTML — отдельная тема; здесь рассматривается только кеш данных и его связи с тегами.

Что сделать дальше

Начните с карты кешей конкретной страницы: какой компонент создаёт запись, из чего складывается ключ, где регистрируются теги и каким событием выполняется сброс. Затем добавьте измерения холодного и прогретого запроса. Если после изменения элемента старый результат сохраняется, проверяйте не TTL, а весь путь: способ обновления данных, тег, компонентный кеш и композитный слой.

^[1] TTL — time to live, срок жизни записи в кеше. По его окончании данные обычно пересобираются при следующем обращении, но физическое удаление файла может произойти позже.