Кеш данных в Bitrix D7: Data\Cache и сброс по тегам

Зачем связка Data\Cache и тегов

В D7 для произвольных PHP-структур чаще всего используют \Bitrix\Main\Data\Cache. Он знаком по духу старому CPHPCache, но API приведено к современному стилю. Отдельно подключается \Bitrix\Main\Application::getInstance()->getTaggedCache(): именно он позволяет пометить запись наборами тегов и позже удалить все куски данных, связанные с конкретной бизнес-сущностью, одним вызовом.

Базовая схема

• Cache::createInstance() — рабочий объект кеша.
• initCache($ttl, $cacheId, $basePath) — если файл ещё жив, можно сразу взять getVars().
• Ветка startDataCache() открывает запись.
• Внутри к тегированному кешу вызывают startTagCache($basePath), registerTag(...), затем endTagCache(), после чего endDataCache($payload) фиксирует массив в файловый кеш.

Путь $basePath должен быть согласован между чтением и регистрацией тегов: ядро ориентируется на один и тот же логический «каталог» внутри кеша для связи тег ↔ файлы.

Пример: чтение и запись с двумя тегами

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

$cacheHandle = Cache::createInstance();
$tagRegistrar = Application::getInstance()->getTaggedCache();

$ttlSeconds = 86400;
$payloadKey = 'promo_sidebar_blocks_v3';
$storageRelativePath = SITE_ID . '/custom/promo_sidebar';

if ($cacheHandle->initCache($ttlSeconds, $payloadKey, $storageRelativePath)) {
    $sidebarBlocks = $cacheHandle->getVars();
} elseif ($cacheHandle->startDataCache()) {
    $tagRegistrar->startTagCache($storageRelativePath);
    $tagRegistrar->registerTag('promo_offer_feed');
    $tagRegistrar->registerTag('static_pages_layout');

    // $cacheHandle->abortDataCache(); // если позже поняли, что собирать нельзя

    $sidebarBlocks = [
        'cta' => ['label' => 'Акции недели', 'href' => '/sales/'],
        'tiles' => [['title' => 'Доставка', 'days' => 2]],
    ];

    $tagRegistrar->endTagCache();
    $cacheHandle->endDataCache($sidebarBlocks);
}

В ключе $payloadKey полезно прошить версию схемы данных (_v3), чтобы после деплоя со сменой структуры старый файл автоматически перестал подходить. Для мультисайтовости и языков добавляйте суффиксы с SITE_ID и языком, где это нужно для изоляции.

Отмена записи при ошибке

Если при сборке блока случилась ошибка или данных нет осознанно, не оставляйте «полусобранную» заготовку на диске. Внутри активной записи можно вызвать $cacheHandle->abortDataCache() и аккуратно выйти из ветки. Тегированный блок в этом случае тоже не должен зависнуть незакрытым — проще обернуть сборку во вложенный try/finally или раннюю проверку входных параметров до startDataCache().

Сброс по одному тегу

Самый типичный сценарий — обновился инфоблок или справочник, и нужно удалить связанный кеш по имени метки без знания конкретного $payloadKey:

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

При сохранении элементов можно дополнительно дергать CIBlock::registerWithTagCache($iblockId) или другие помощники домена — тогда сброс синхронизируется со стандартными событиями ядра. Для пользовательских тегов важно договориться об именовании префиксами модулей, чтобы не затереть чужие данные случайным совпадением строки.

На что смотреть в продакшене

• Не сериализуйте объекты с внешними ресурсами — только массивы примитивов и простые структуры.
• Следите за TTL: длинное удержание экономит запросы, но удорожает согласование актуальности с тегами.
• Держите ключи человекочитаемыми в логах и отложенной отладке; хэши добавляйте только когда действительно не хватает длины ключа.

Итог

Data\Cache закрывает хранение снимка данных, а TaggedCache даёт простой контур инвалидации. Связка подходит для тяжёлых кусков логики вне компонентного кеша: от агрегатов главной страницы до подборок меню после первичной нормализации каталогов.