Розробка модуля кешування 1С-Бітрікс на Redis

Розробка модуля кешування 1С-Бітрікс на Redis — рішення для проєктів, де стандартний файловий кеш не справляється. Сайт гальмує, адміністратори чистоть папку /bitrix/cache/ вручну, а при пікових навантаженнях сервер лягає. Одного разу на проєкті з каталогом на 500 000 товарів файловий кеш розрісся до 40 ГБ, і операції читання блокували базу даних. Модуль кешування на Redis вирішив ці проблеми повністю: Redis-бекенд забезпечує hit rate 98%, знижує latency на 90% і підтримує атомарну інвалідацію тегів. Зв'яжіться з нами — ми безкоштовно проаналізуємо архітектуру вашого проєкту і запропонуємо оптимальне рішення під ключ.

Чому Redis швидший за файловий кеш?

Файловий кеш не масштабується на декілька серверів, операції читання/запису блокуються на рівні файлової системи, а інвалідація за тегом — блокуюча операція. Redis виконує запити в пам'яті, час відгуку на 90% менший. Атомарні операції (Sets, Lists) роблять інвалідацію миттєвою. На практиці hit rate модуля на Redis досягає 98%, тоді як на файлах він рідко перевищує 85%. Навантажувальне тестування показало: при 1000 одночасних запитах Redis-бекенд обробляє всі запити за 120 мс, а файловий — за 450 мс.

Архітектура CacheManager

Центральний клас CacheManager реалізує патерн стратегії. Бекенд вибирається в налаштуваннях модуля:

$cache = \Vendor\Cache\CacheManager::getInstance(); // Стандартний get-or-set $result = $cache->remember('catalog_section_12', 3600, function() { return CIBlockSection::GetList(/* ... */)->Fetch(); }, ['iblock_12', 'catalog']); // → Дані з кешу або результат callable, якщо промах // Явна інвалідація за тегом $cache->invalidateTag('iblock_12'); // → Скидаються всі ключі, позначені тегом iblock_12 

Redis-бекенд: інвалідація тегів на атомарному рівні

Теги в Redis реалізовані через Sets. Інвалідація за тегом — атомарна операція без блокувань файлової системи:

class RedisCacheBackend implements CacheBackendInterface { private \Redis $redis; public function get(string $key): mixed { $data = $this->redis->get($key); return $data !== false ? unserialize($data) : null; } public function set(string $key, mixed $value, int $ttl, array $tags = []): void { $serialized = serialize($value); $this->redis->setEx($key, $ttl, $serialized); // Теги зберігаються як Redis Sets foreach ($tags as $tag) { $this->redis->sAdd("tag:{$tag}", $key); $this->redis->expire("tag:{$tag}", $ttl + 3600); } } public function invalidateTag(string $tag): void { $keys = $this->redis->sMembers("tag:{$tag}"); if ($keys) { $this->redis->del(...$keys); } $this->redis->del("tag:{$tag}"); } } 

Чотири стратегії кешування

Ми використовуємо чотири стратегії залежно від типу даних:

• TTL-кеш — класичний час життя для рідко змінюваних даних: налаштування сайту, регіони, доставка
• Event-invalidation — скидання при подіях Бітрікс (OnAfterIBlockElementAdd, OnAfterIBlockElementUpdate і т.д.)
• Stale-while-revalidate — застарілий кеш віддається негайно, у фоні запускається перегенерація через агент. Усуває «натовп» при промасі
• Request-scoped — in-memory array на час одного HTTP-запиту, дозволяє уникнути повторних запитів до БД

Хочете підібрати оптимальну стратегію для вашого проєкту? Зв'яжіться з нами для консультації.

Прогрів кешу для запобігання spike

При скиданні кешу перший запит завжди повільний — іде в БД. При високому навантаженні це призводить до spike. Агент прогріву вирішує проблему:

// Зареєстровані warmup-завдання $cache->registerWarmup('catalog_menu', function() { return CIBlockElement::GetList(/* повний каталог */); }, ['iblock_main_catalog'], 7200); // Агент запускається раз на годину і оновлює кеш до закінчення TTL \Vendor\Cache\WarmupAgent::run(); 

Моніторинг та статистика

Таблиця b_vendor_cache_stat — для агрегованої статистики по ключах:

• key_prefix, hits, misses, avg_ttl, last_hit_at

В адміністративному інтерфейсі:

• Hit rate по категоріях ключів
• Топ «холодних» ключів (більше 20% промахів)
• Розмір кешу по бекендах
• Ручна інвалідація за тегом або ключем
• Лог останніх операцій інвалідації

Як інтегрувати модуль з існуючими компонентами?

Стандартні компоненти використовують $APPLICATION->IncludeComponent() з параметром CACHE_TYPE. Модуль перехоплює цей механізм і перенаправляє в Redis:

// В init.php після підключення модуля \Vendor\Cache\BitrixCacheBridge::install(); // → Перевизначає \Bitrix\Main\Data\Cache::createInstance() // повертаючи Redis-бекенд замість файлового 

Bridge робить заміну прозорою — компоненти продовжують працювати без змін коду.

Процес розробки: від аудиту до деплою

1. Аналітика — вивчаємо поточну архітектуру, вимірюємо продуктивність (XDebug, slow log MySQL), виявляємо вузькі місця.
2. Проєктування — проєктуємо схему модуля: вибираємо стратегії, проєктуємо структуру тегів, погоджуємо з вами.
3. Реалізація — пишемо код CacheManager, бекендів, агентів, bridge.
4. Тестування — навантажувальне тестування за допомогою JMeter (1000 віртуальних користувачів) і зняття метрик.
5. Деплой — встановлення на staging і production, моніторинг протягом тижня.

Що входить в роботу

Строки та вартість

Разом: 10–12 робочих днів. Гарантія на код — 1 рік. Вартість розробки розраховується індивідуально. Для проєктів з кластером PHP-серверів — додаткове налаштування Redis Cluster або Sentinel: +1–2 дні.

Детальніше про Redis та принципи кешування.

Оцініть поточну продуктивність вашого сайту: ми проведемо безкоштовний аудит кешування за 2 дні. Замовте розробку модуля кешування, щоб ваш сайт працював швидко та стабільно при будь-яких навантаженнях — зв'яжіться з нами для консультації!