Почему 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 раза. Свяжитесь с нами для оценки вашего проекта — мы подберём конфигурацию под нагрузку.