Настройка кэша под нагрузку

Кэш — это самый дешёвый способ выдержать нагрузку на Битрикс: он снимает работу с PHP и БД до того, как она вообще начнётся. Но под тысячи RPS важно не только «включить кэш», а правильно выбрать хранилище, стратегию сброса и защититься от типовых ловушек.

Уровни кэша в Битрикс

В Битрикс кэш многослойный, и каждый слой решает свою задачу. Понимание их взаимодействия — основа настройки:

• Кэш компонентов — результат работы компонента (HTML + данные) сохраняется и отдаётся без обращения к БД;
• Управляемый кэш (managed cache) — кэш выборок ядра с автоматическим сбросом при изменении данных;
• Тегированный кэш (tagged cache) — точечный сброс по меткам вроде iblock_id_5;
• Композит — статическая часть страницы, отдаваемая до старта ядра;
• opcache — кэш скомпилированного PHP-байткода.

Где хранить кэш: файлы, Memcached, Redis

По умолчанию Битрикс кэширует на диск. На одной ноде это терпимо, но под нагрузкой и в кластере файловый кэш становится узким местом из-за I/O и не разделяется между нодами. Выбор хранилища задаётся в /bitrix/.settings.php и /bitrix/php_interface/dbconn.php.

Для highload рекомендуется Redis: он единый для всех веб-нод, переживает перезапуск, поддерживает тегированный кэш и одновременно хранит сессии. Настраивается через секцию cache в .settings.php с типом redis.

Тегированный кэш: точечный сброс

Главная ошибка новичков — сбрасывать весь кэш при любом изменении. Под нагрузкой это катастрофа: после сброса все запросы разом идут в БД. Решение — тегированный кэш.

В коде это выглядит так:

$cache = \Bitrix\Main\Data\Cache::createInstance();
if ($cache->initCache($ttl, $id)) { $data = $cache->getVars(); }
elseif ($cache->startDataCache()) { $tc = \Bitrix\Main\Application::getInstance()->getTaggedCache(); $tc->startTagCache($path); $tc->registerTag('iblock_id_5'); ... }

При изменении элемента инфоблока Битрикс сам сбрасывает кэш по тегу iblock_id_5, а всё остальное остаётся тёплым. Обязательно включите управляемый кэш ('value' => 'Y' для cache_managed), иначе теги не будут инвалидироваться.

Композитный сайт: отдача до старта ядра

Композит — ключевая технология Битрикс для highload. Страница делится на статическую (шапка, меню, каталог) и динамическую части. Статика кэшируется целиком и отдаётся до инициализации ядра, а динамика (корзина, авторизация) подгружается AJAX-запросом.

• включается в Настройки → Композитный сайт;
• хранилище композита выносите в Memcached или Redis, не в файлы;
• динамические блоки оборачивайте в $APPLICATION->IncludeComponent с параметром 'COMPOSITE_FRAME_MODE' => 'Y'.

Прогрев и защита от dog-pile

Опасный момент — истечение кэша под нагрузкой. Когда TTL популярной страницы кончается, десятки параллельных запросов одновременно обнаруживают пустой кэш и все разом лезут в БД пересчитывать одно и то же. Это эффект dog-pile (cache stampede).

Способы борьбы:

1. Прогрев кэша после деплоя — обход ключевых URL ботом-краулером, чтобы кэш наполнился до прихода посетителей;
2. разнесение TTL, чтобы кэш ключевых страниц не истекал синхронно;
3. для критичных участков — блокировка на пересчёт (только один процесс пересчитывает, остальные отдают старое значение).

После релиза кэш и opcache сбрасываются, и первый трафик приходит на «холодный» проект. Автоматический прогрев в пайплайне деплоя снимает пиковую просадку в первые минуты.

Что нельзя кэшировать надолго

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

Остатки и цены — самая частая причина жалоб «купил, а товара нет». Их кэш должен инвалидироваться событиями обмена, а не жить сутками по общему TTL.

Итог

Кэш под нагрузку — это система из нескольких слоёв: opcache и композит снимают старт ядра, кэш компонентов и тегированный кэш убирают работу с БД, Redis делает всё это общим для кластера. Ключевые решения — вынести хранилище из файлов в Redis, сбрасывать точечно по тегам, прогревать кэш после деплоя и не кэшировать волатильные данные надолго.

Мы в B2Bsite настраиваем многоуровневое кэширование на highload-проектах: подбираем хранилище, выстраиваем теги и композит, добавляем прогрев в пайплайн и защищаем от dog-pile. Если проект проседает под нагрузкой — поможем выжать из кэша максимум без риска для бизнес-данных.