Тегированный кеш и кеш компонентов в Bitrix

Два слоя, которые часто смешивают

Публичная страница в Битрикс обычно тянет данные через компоненты. Файловый результат кладётся под /bitrix/cache, а привязка «этот файл устарел, когда изменилась сущность X» живёт отдельно: ядро пишет соответствия тег ↔ пути в базе (таблица вида b_cache_tag). То есть видимый выигрыш по скорости даёт файл на диске, а управляемая инвалидация — связка через \Bitrix\Main\Application::getInstance()->getTaggedCache().

Смысл параметров CACHE_* у компонента

Типичный набор параметров вызова: CACHE_TIME (срок в секундах), CACHE_TYPE (A — автосброс по зависимостям платформы, Y — кеш включается, но инвалидация на вас или по TTL, N — без кеша), CACHE_GROUPS учитывает или игнорирует различие групп пользователя при формировании идентификатора. Режим A имеет смысл, когда внутри компонента реально выполняются стандартные выборки, которые платформа умеет помечать тегами автоматически (классический пример — API инфоблоков через Fetch()/GetNext() после выборки элементов).

Где включается кеш простого компонента

Для простых компонентов логика сходится на startResultCache() наследника CBitrixComponent. Закешировать пытается всё содержательное между началом кешируемого участка и includeComponentTemplate(): отфильтрованное подмножество $arResult после setResultCacheKeys(), HTML шаблона, подключённые в нём ресурсы, эпилоги. Если кеш уже есть и актуален, тело if ($this->startResultCache(...)) { … } не выполняется — поэтому туда не стоит класть код, который обязан пройти на каждом хите (глобальный SEO-заголовок из внешнего сервиса и подобное лучше оставить снаружи или в некешируемой зоне шаблона).

Откуда берутся теги без вашего кода

При последовательном чтении элементов инфоблока платформа помечает кеш результатом выборки тегами вроде iblock_id_{ид}. После сохранения элемента в админке срабатывают очистки, и связанный компонентный файл пересоздаётся без ручного поиска путей. Если же вы дергаете альтернативные источники (простые SQL-без событий, внешний HTTP, свой JSON), автоматической метки нет — тогда нужен осознанный контракт имен тегов и вызов clearByTag() из собственных событий.

Связка пути: зачем совпадает каталог для Data\Cache и TagCache

В собственном коде вне типового компонента вы используете Bitrix\Main\Data\Cache и рядом startTagCache($relativeDir) с тем же относительным путём, что и во initCache()/startDataCache(). Если путь расходится, тег есть, файл другой — сброс по тегу не попадёт в ожидаемый каталог.

use Bitrix\Main\Application;
use Bitrix\Main\Data\Cache;

$svc = Cache::createInstance();
$tags = Application::getInstance()->getTaggedCache();

$relativeDir = 'custom/warranty_blocks';
$slotKey = 'region_' . htmlspecialcharsbx($regionCode);
$ttlSeconds = 7200;

if ($svc->initCache($ttlSeconds, $slotKey, $relativeDir)) {
    $blockPayload = $svc->getVars();
} elseif ($svc->startDataCache()) {
    $tags->startTagCache($relativeDir);
    $tags->registerTag('warranty_offer_matrix');

    $tiles = []; // тяжёлая сборка гарантийных плиток под регион
    $blockPayload = ['region' => $regionCode, 'tiles' => $tiles];

    $tags->endTagCache();
    $svc->endDataCache($blockPayload);
}

Свои теги в теле компонента

Платформа уже поднимает службу TagCache около результатов компонента. Если автоматической привязки мало (смешали инфоблок и кастомную таблицу, или нужно срезать сразу витрину и футер по одному событию), регистрируйте строковый тег после успешного startResultCache() и до includeComponentTemplate() — именно здесь живёт понятное место расширения без ломания стартовых проверок. В шаблоне то же возможно (включая возможность вызова AbortResultCache(), если поняли, что выдавать сохранять нельзя), но любую отмену держите парой с симметричными вызовами у TagCache.

if ($this->startResultCache($this->arParams['CACHE_TIME'])) {
    $tagRegistrar = \Bitrix\Main\Application::getInstance()->getTaggedCache();
    $tagRegistrar->registerTag('storefront_sidebar_vouchers');

    /* CIBlockElement::GetList(...) + GetNext() → iblock-тег уже есть */
    $this->setResultCacheKeys(['ITEMS', 'FACET_NOTE']);
    $this->includeComponentTemplate();
}

Комплексные компоненты и границы ответственности

Комплексные компоненты сами выступают маршрутизатором между страницами: тяжёлый автокеш держат «дочерние» простые компоненты. На уровне шаблонов полезно помнить, что внутри кешируемого шаблонного участка любой лишний внешний запрос делает сохранённые HTML-снимки зависимыми от недетерминизма или таймаутов удалённых сервисов.

Явная очистка по бизнес-событию

Обработчик сохранения сущности вне типового контура может завершиться вызовом $tagRegistrar->clearByTag('storefront_sidebar_vouchers') — платформа удалит связанный набор записей без знания конкретного ключа файла. Держите имена короткими, с префиксом вашего решения; не полагайтесь на «случайно уникальное» значение строки без протокола в команде разработчиков.

$tagRegistrar = \Bitrix\Main\Application::getInstance()->getTaggedCache();
$tagRegistrar->clearByTag('warranty_offer_matrix');

На что опереться в проекте

Выровняйте стратегию: для списков и детальных карточек инфоблоков чаще хватает CACHE_TYPE = A и аккуратного набора параметров фильтров в расчёт ключа результата.
Для сборок без ORM-событий проектируйте конечный список тегов как контракт API вашего блока данных.
Не смешивайте в одном сохранении гигантские HTML и огромный сериализованный массив без необходимости — проще поддерживать кеш переменных в Data\Cache, а верстку оставить компоненту.

Итог

Компонентный кеш в Битрикс — это упакованный снимок HTML и ограниченного arResult, который получает связи через теги; инфоблок на этапе выборки зачастую закрывает вопрос инвалидации сам. Когда источников несколько или поток данных вне контроля платформы, осознанное именование и registerTag()/clearByTag() вокруг одинакового относительного пути сохраняют предсказуемое поведение при правках контента без «сносить всё через админку».

Тегированный кеш и кеш компонентов в 1С‑Битрикс: связка пути, инфоблок и ручная инвалидация