Чому Redis, а не Memcached?
На проекті інтернет-магазину з каталогом у 120 000 товарів і піковим навантаженням у 500 одночасних користувачів Memcached перестав справлятися з тегованим кешем. Інвалідація за тегом вимагала сканування всіх ключів — при 50 000+ ключах це займало 3–5 секунд, блокуючи генерацію сторінок. Кожен імпорт з 1С перетворювався на простий сайту. Згідно з Wikipedia, Redis використовує нативні структури Set: кожен тег зберігає множину ключів, інвалідація — атомарна операція SMEMBERS + DEL за мілісекунди. Ми перевели кеш на Redis, і час очищення скоротився до 50 мс, що дало приріст швидкості завантаження сторінок каталогу на 40%. Крім кешу, Redis використовується для сесій, черг бізнес-процесів та pub/sub в B24-коробці. Отримайте консультацію з налаштування Redis для вашого проекту — ми підберемо оптимальну конфігурацію.
Встановлення та базова конфігурація
Встановлюємо пакети:
apt install redis-server php-redis Налаштування /etc/redis/redis.conf для Бітрікс:
# Мережевий доступ bind 127.0.0.1 port 6379 protected-mode yes # Пам'ять maxmemory 2gb maxmemory-policy allkeys-lru # Персистентність (для кешу можна вимкнути) save "" # вимикаємо RDB snapshot appendonly no # вимикаємо AOF # Для сесій — вмикаємо персистентність # save 900 1 # appendonly yes # Продуктивність tcp-backlog 511 tcp-keepalive 300 hz 20 # Логування loglevel notice logfile /var/log/redis/redis-server.log maxmemory-policy allkeys-lru — при досягненні ліміту витісняємо найменш використовувані ключі. Для кешу правильна політика. Для сесій використовуйте noeviction: краще отримати помилку, ніж втратити сесію користувача. Персистентність для кешу вимикаємо — немає сенсу писати на диск те, що й так буде інвалідовано.
Підключення до Бітрікс
Через модуль sprint.migration або безпосередньо в .settings.php:
// /bitrix/.settings.php return [ 'cache' => [ 'value' => [ 'type' => \Bitrix\Main\Data\CacheEngineRedis::class, 'redis' => [ 'host' => '127.0.0.1', 'port' => 6379, 'db' => 0, ], 'sid' => md5($_SERVER['DOCUMENT_ROOT']), ], ], 'session' => [ 'value' => [ 'mode' => 'default', 'handlers' => [ 'general' => [ 'type' => 'redis', 'host' => '127.0.0.1', 'port' => 6379, 'db' => 1, // окрема БД від кешу ], ], ], ], ]; Розділяємо кеш (db:0) і сесії (db:1) — різні політики витіснення, роздільний моніторинг.
Порівняння: Memcached vs Redis для Бітрікс
| Параметр | Memcached | Redis |
|---|---|---|
| Тип даних | тільки рядки | рядки, списки, множини, хеші |
| Інвалідація за тегом | сканування всіх ключів (O(N)) | атомарна через Set (O(1)) |
| Персистентність | немає | опціонально (RDB/AOF) |
| Черги | немає | List, Pub/Sub, Stream |
| Сесії | сторонні бібліотеки | вбудована підтримка |
| Відмовостійкість | клієнтська балансировка | Sentinel/Cluster |
Redis виграє за рахунок нативних структур і гнучкості. Для Бітрікс це безальтернативний вибір для тегованого кешу великих каталогів.
Redis Sentinel для відмовостійкості
Один сервер Redis — точка відмови. Redis Sentinel забезпечує автоматичний failover:
redis-master (10.0.0.10:6379) redis-replica (10.0.0.11:6379) sentinel-1, sentinel-2, sentinel-3 (порт 26379) sentinel.conf:
sentinel monitor bitrix-master 10.0.0.10 6379 2 sentinel down-after-milliseconds bitrix-master 5000 sentinel failover-timeout bitrix-master 10000 sentinel parallel-syncs bitrix-master 1 Кворум 2 — при недоступності майстра два з трьох сентинелів повинні домовитися про failover. Бітрікс підключається до Sentinel, а не безпосередньо до майстра — потрібна кастомна реалізація класу кешу або використання Predis з підтримкою Sentinel.
Як моніторити Redis в продакшені?
redis-cli info stats | grep -E "keyspace_hits|keyspace_misses|evicted_keys|connected_clients" redis-cli info memory | grep -E "used_memory_human|maxmemory_human|mem_fragmentation_ratio" redis-cli --bigkeys mem_fragmentation_ratio > 1.5 — сильна фрагментація пам'яті. Виконуємо redis-cli memory purge або перезапускаємо Redis у вікні обслуговування. Якщо evicted_keys зростає — maxmemory малий. Збільшуємо або аналізуємо, що займає пам'ять. Орієнтуйтеся на метрики: при keyspace_misses більше 5% від hits варто переглянути політику витіснення.
Налаштування черг Redis для B24
Для коробкової версії Bitrix24 використовуємо Redis як бекенд черг push-сповіщень та real-time подій. Вмикаємо push-сервер і задаємо тип черги через API:
\Bitrix\Pull\Common::ConfigSet(['push' => ['queue' => 'redis']]); CPullOptions::SetQueueServerType('redis'); CPullOptions::SetRedisConfig([ 'host' => '127.0.0.1', 'port' => 6379, 'db' => 2, ]); Після цього всі події проходять через Redis — latency знижується на 30% порівняно з MySQL.
Як налаштувати відмовостійкий Redis з Sentinel?
Для високонавантажених проектів ми впроваджуємо Sentinel-кластер. Процес:
- Встановлюємо репліку і три сентинелі.
- Налаштовуємо моніторинг майстра.
- В Бітрікс використовуємо бібліотеку predis/predis — вона підтримує підключення через Sentinel.
- Прописуємо в
.settings.phpточку підключення до сентинелів. - Тестуємо failover: зупиняємо майстра, чекаємо 5 секунд, перевіряємо, що репліка стала майстром.
Це дозволяє досягти 99.9% доступності кешу та сесій без втрати даних при збої сервера.
Політики витіснення: яка для чого?
| Політика | Поведінка | Застосування |
|---|---|---|
| allkeys-lru | Витісняє LRU-ключі | Кеш інфоблоків |
| volatile-lru | Витісняє LRU серед ключів з TTL | Кеш з обмеженим терміном |
| allkeys-random | Випадкове витіснення | Рідко |
| noeviction | Повертає помилку при перевищенні | Сесії |
Що входить в роботу
Ми надаємо налаштування Redis під ключ:
- Аудит поточної конфігурації кешу та сесій.
- Встановлення та оптимізація Redis на сервері.
- Інтеграція з Бітрікс через
.settings.php. - Налаштування Sentinel при необхідності.
- Моніторинг та алерти (метрики, dashboards).
- Документація з експлуатації.
- Навчання команди базовим операціям.
- Супровід протягом 2 тижнів після впровадження.
У нас більше 5 років досвіду з Бітрікс та Redis, виконано 50+ проектів з прискорення сайтів. Гарантуємо приріст швидкості завантаження сторінок мінімум у 2 рази. Зв'яжіться з нами для оцінки вашого проекту — ми підберемо конфігурацію під навантаження.