Как настроить тегированный кеш в 1С-Битрикс через RegisterTag?

Цена в админке обновилась, а на витрине - вчерашняя. Кнопка "Очистить весь кеш" помогает, но после каждой правки сайт тормозит - это типичная проблема кастомного компонента без тегов. Тегированный кеш (Cache Dependencies) помечает файл кеша меткой iblock_id_5, и ядро сбрасывает только связанные записи при Update. Здесь включите управляемый кеш, обернёте D7-выборку в registerTag и проверите витрину без полной очистки.

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

Речь про 1С-Битрикс: Управление сайтом (коробочная CMS), а не про облачный Bitrix24. На практике теги вешают через D7-класс \Bitrix\Main\Data\TaggedCache и вкладку "Управляемый кеш" в админке. Аналогия: обычный кеш живёт по таймеру, тегированный - по бирке "Каталог №5": при правке товара выбрасываются только ящики с этой меткой.

Сравните три стратегии кеша: TTL, полная очистка и RegisterTag

Три подхода решают разные задачи. Смешивать их без понимания - частая причина "залипшей" цены.

Делайте: для витрины с ценами и остатками выбирайте RegisterTag. Не делайте: не ставьте CACHE_TIME = 86400 и не жмите "Очистить всё" после каждой правки - это маскирует ошибку в коде, а не лечит её.

Включите управляемый кеш в админке и проверьте BX_COMP_MANAGED_CACHE

Теги работают только при включённом управляемом кеше. Без него registerTag и clearByTag не связывают файлы с метками в /bitrix/managed_cache/.

1. Откройте админку: Настройки → Настройки продукта → Производительность.
2. На вкладке Кеширование включите Управляемый кеш (Managed cache).
3. Проверьте bitrix/php_interface/dbconn.php: должна быть строка define("BX_COMP_MANAGED_CACHE", true);. Без неё ядро не активирует механизм тегов.
4. Убедитесь, что каталог /bitrix/managed_cache/ доступен на запись веб-серверу.
5. После включения сделайте одну тестовую правку элемента и проверьте, обновился ли штатный компонент каталога без ручной очистки.
6. Если managed cache был выключен давно, очистите старые файлы в /bitrix/cache/ один раз после включения - иначе витрина может показывать устаревшие данные из неуправляемого слоя.

Делайте: включайте управляемый кеш на staging до переноса на production. Не делайте: не копируйте только код registerTag, оставив managed cache выключенным - симптом будет тот же: "теги не работают".

Настройте D7 TaggedCache: initCache, startTagCache и registerTag с одним путём

Кеш - класс \Bitrix\Main\Data\Cache, теги - \Bitrix\Main\Data\TaggedCache через Application::getInstance()->getTaggedCache(). Главное правило: путь в startTagCache = путь в initCache. Иначе clearByTag не затронет вашу выборку. В реальном проекте, например, путь /catalog/top в initCache и /catalog/top/ со слэшем - типичная ошибка: теги вешаются, но сброс не работает.

Минимальный шаблон для списка элементов инфоблока:

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

$iblockId = 5;
$cacheTtl = 3600;
$cacheId = 'catalog_top_' . $iblockId;
$cachePath = '/my/catalog/top';

$cache = Cache::createInstance();

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

    $items = []; // ваша выборка через GetList или D7 ORM

    if (empty($items)) {
        $taggedCache->abortTagCache();
        $cache->abortDataCache();
    } else {
        $taggedCache->endTagCache();
        $cache->endDataCache($items);
    }
}

Цепочка: initCache → startDataCache → startTagCache → registerTag → endTagCache → endDataCache. При пустой выборке - abortTagCache + abortDataCache. Выборку данных разберите в гайде по GetList и D7 ORM.

Делайте: копируйте $cachePath в обе функции буквально, без лишних слэшей. Не делайте: не вызывайте endTagCache без пары startTagCache - стек тегов в ядре нарушится.

Добавьте registerTag в свой компонент через StartResultCache

В своём компоненте кешируйте через $this->startResultCache() в class.php. Кастомные теги для нестандартных данных вешайте вручную внутри блока кеша.

if ($this->startResultCache(false, $cacheId, $componentPath)) {
    global $CACHE_MANAGER;
    $CACHE_MANAGER->StartTagCache($componentPath);
    $CACHE_MANAGER->RegisterTag('iblock_id_' . (int)$this->arParams['IBLOCK_ID']);
    // сбор $arResult
    $CACHE_MANAGER->EndTagCache();
    $this->setResultCacheKeys(['ITEMS', 'PRICES']);
} else {
    $this->abortResultCache();
}

Делайте: указывайте setResultCacheKeys. Не делайте: не кешируйте через "голый" CPHPCache без тегов - ядро о файле не узнает при Update.

Используйте штатные теги iblock_id_N и вызывайте clearByTag вручную при необходимости

Ядро автоматически сбрасывает кеш по тегам при стандартных операциях с инфоблоками. Основные метки:

• iblock_id_N - любое изменение в инфоблоке N
• iblock_element_id_N - конкретный элемент
• iblock_section_id_N - раздел каталога

При прямом SQL или SetPropertyValues в обход Update автосброс не сработает. Вызовите clearByTag в OnAfterIBlockElementUpdate:

use Bitrix\Main\Application;

Application::getInstance()
    ->getTaggedCache()
    ->clearByTag('iblock_id_5');

Для нескольких источников придумайте свой тег (до 100 символов) и используйте одинаковую строку в registerTag и clearByTag. Не делайте: не вешайте теги на данные, которые меняются каждую секунду - механизм рассчитан на редкие правки контента.

Проверьте чек-лист, если кеш не сбросился после Update

Когда цена на витрине "залипла", пройдите диагностику за пять минут:

1. Управляемый кеш включён? Админка + BX_COMP_MANAGED_CACHE в dbconn.php.
2. Путь совпадает? Сравните строку в initCache и startTagCache посимвольно.
3. Пара start/end закрыта? Нет пропущенного endTagCache или abortTagCache при ошибке.
4. Тег тот же? При записи и в clearByTag - одна строка, включая префикс iblock_id_.
5. Композитный слой? HTML-кеш страницы - отдельный уровень; после сброса managed cache проверьте витрину с ?ncc=1 или по гайду композитного сайта на Битрикс.
6. Update реально прошёл через API инфоблока? Прямой SQL не триггерит штатные теги.

Схема сброса: Update элемента → ядро clearByTag('iblock_id_5') → удаляются каталоги кеша с этим тегом → следующий хит пересобирает выборку → витрина показывает новую цену

Делайте: логируйте $cachePath и тег на staging. Не делайте: не сносите весь /bitrix/cache вместо поиска ошибки в коде.

После настройки измените цену в каталоге, проверьте витрину без ручной очистки и добавьте registerTag в свой компонент. Нужна помощь на боевом проекте - обсудим задачу.

Автор: Максим Мольков, Senior-разработчик 1С-Битрикс.
Источники: официальный урок Cache Dependencies, D7 API TaggedCache, управляемое кеширование.

Частые вопросы