Настройка Redis и Memcached для Битрикс: кеш в памяти и разгрузка диска

Вынести кеш Битрикс в Redis или Memcached звучит как пара строк в конфиге, и формально так и есть. Но разница между «кеш в памяти включили» и «кеш в памяти работает надёжно под нагрузкой» — огромная. Можно подключить движок и получить вытеснение данных, проседающий hit-rate, потерянные сессии и нестабильный отклик. А можно подобрать память под объём кеша, настроить политику вытеснения, persistence и мониторинг — и получить быстрый, предсказуемый кеш, который держит распродажи и пики трафика. Ниже разбираем, на что мы смотрим, какие ошибки встречаем чаще всего и как строим вынос кеша так, чтобы он работал годами.

Почему файловый кеш Битрикс тормозит под нагрузкой

По умолчанию Битрикс складывает кеш и сессии в файлы. На сайте с заметным трафиком это десятки и сотни тысяч мелких файлов, и каждое обращение к кешу — это операция с файловой системой: открыть, прочитать, закрыть. Под нагрузкой диск становится узким местом: очередь операций ввода-вывода растёт, отклик страниц увеличивается, а процессор при этом может простаивать. Отдельная боль — сессии. Файловые сессии блокируются при параллельных запросах одного пользователя, поэтому второй запрос ждёт, пока освободится первый. На сайтах с активными личными кабинетами и корзинами это превращается в заметные задержки.

Ещё одна скрытая проблема — очистка кеша. На крупном сайте сброс файлового кеша означает обход дерева каталогов и удаление множества файлов, что само по себе нагружает диск и идёт небыстро. В памяти инвалидация кеша по тегам и ключам происходит почти мгновенно. Поэтому вынос кеша в Redis или Memcached ускоряет не только чтение, но и сброс кеша при публикации контента.

Что меняется после выноса кеша в память

Когда managed cache и сессии переезжают в Redis или Memcached, повторяющиеся данные отдаются из оперативной памяти почти мгновенно. Диск перестаёт захлёбываться на мелких операциях, сессии больше не блокируют друг друга, а часть повторных запросов вообще не доходит до базы данных — ответ берётся из кеша. В результате разгружаются сразу диск и база, отклик на пиках выравнивается, а сайт начинает упираться в реальные ресурсы, а не в файловую систему. Если у вас несколько серверов, общий Redis даёт всем нодам единый кеш, и база перестаёт греться дублирующими запросами с каждой ноды по отдельности. Тонкости самого слоя кеширования — теги, время жизни, композитный кеш — мы разбираем в услуге настройка кеширования Битрикс, а здесь сосредоточены на том, чтобы этот кеш жил в памяти быстро и надёжно.

Главный риск — память и вытеснение

Самая частая ошибка при выносе кеша в память — недооценить нужный объём. Если памяти под кеш выделено мало, движок начинает вытеснять данные, чтобы освободить место под новые. Вытесненные записи приходится считать заново, hit-rate проседает, и часть выигрыша теряется. Поэтому мы всегда оцениваем фактический объём кеша, подбираем память с запасом и настраиваем политику вытеснения под сценарий: для летучего кеша допустимо агрессивное вытеснение старых записей, для сессий — нет. За вытеснением и занятой памятью следим в мониторинге, чтобы вовремя увидеть, что кешу стало тесно, и добавить память до того, как hit-rate начнёт падать.

Второй риск — смешать в одном хранилище то, что терять можно, и то, что нельзя. Летучий кеш данных при перезапуске просто прогреется заново, а вот сессии пользователей терять нежелательно — это разлогинит людей и очистит корзины. Поэтому для сессий мы либо используем persistence, либо выделяем их в отдельное хранилище с подходящими настройками, чтобы перезапуск сервера не выбрасывал пользователей.

Persistence: когда сохранять кеш на диск, а когда нет

Persistence — это сохранение данных Redis на диск, чтобы пережить перезапуск без холодного старта. Звучит как безусловное благо, но включать его везде не нужно. Для чисто летучего кеша данных persistence только добавляет нагрузку на диск без пользы: такой кеш и так быстро прогревается. А вот для сессий и для случаев, когда холодный старт кеша критичен (например, на сайте, который сразу после перезапуска получает большой трафик), persistence оправдан. Redis поддерживает два механизма — снимки RDB и журнал AOF, — и мы подбираем их комбинацию под ваш сценарий, балансируя между надёжностью и нагрузкой на диск. Memcached persistence не поддерживает в принципе, и это нормальное свойство летучего кеша, а не недостаток.

Кластеризация и отказоустойчивость

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

Мониторинг: кеш должен быть наблюдаемым

Кеш в памяти нельзя оставлять чёрным ящиком. Без мониторинга вы не узнаете, что hit-rate просел, память закончилась, а движок начал вытеснять нужные данные, — пока пользователи не начнут жаловаться на медленный сайт. Поэтому с первого дня мы ставим панель с ключевыми метриками: hit-rate (доля попаданий в кеш), занятая и свободная память, число вытеснений, число подключений и задержки ответа движка. По этим метрикам видно, хватает ли памяти, эффективно ли работает кеш и не пора ли его масштабировать. На метрики настраиваем алерты, чтобы реагировать на проблемы заранее, а не постфактум.

Как мы ведём работу

Начинаем с аудита: смотрим, где сейчас лежит кеш и сессии, как загружен диск, какой hit-rate, упирается ли сайт в диск, базу или процессор. На основе этого выбираем движок — Redis или Memcached — и согласуем объём памяти, схему persistence и отказоустойчивости. Дальше ставим движок, настраиваем лимиты памяти, политику вытеснения и доступ, подключаем managed cache и сессии Битрикс к памяти. Проверяем работу тегированного кеша и блокировок сессий на копии, чтобы не задеть рабочий сайт. Затем прогоняем нагрузку, ловим вытеснение и просадки hit-rate, докручиваем память и настройки. В финале ставим мониторинг, описываем все настройки и передаём проект с документацией.

Такой порядок убирает риск: вынос кеша не делается вслепую и не ломает работающий сайт. Каждый шаг проверяем по метрикам, а переключение на кеш в памяти делаем тогда, когда уверены, что всё работает корректно. Эта услуга хорошо ложится в общий контур ускорения вместе с другими работами по разделу кеширование Битрикс, где собраны все решения по кешу.

Где Redis и Memcached проявляют себя по-разному

На практике разница между движками лучше всего видна на конкретных сценариях. Для интернет-магазина с распродажами, где главная боль — диск, захлёбывающийся на файловом кеше, часто достаточно Memcached: он быстро снимает нагрузку с диска и базы летучим кешем, а потеря кеша при перезапуске не критична, потому что он прогревается заново. Для B2B-портала с активными личными кабинетами на первый план выходят сессии, которые в файлах блокируют параллельные запросы, и здесь выигрывает Redis с persistence: сессии переживают перезапуск, а блокировки настроены корректно. Для маркетплейса на нескольких нодах решающим становится общий кеш на кластер, репликация и failover — а это уже только Redis.

Поэтому мы не отвечаем на вопрос о движке абстрактно. Сначала смотрим, во что именно упирается ваш проект: в диск, в базу, в блокировки сессий или в рассинхрон кеша между нодами. От узкого места и зависит выбор. Иногда правильный ответ — простой Memcached, который решит задачу без лишней сложности. Иногда — Redis с кластером и persistence, потому что задача того требует. Навязывать сложную схему там, где она не нужна, мы считаем плохой инженерной практикой: лишние узлы — это лишние точки отказа и лишняя стоимость поддержки.

Типичные ошибки в настройке кеша, которые мы исправляем

Когда нас зовут на уже работающий, но медленный проект, мы регулярно встречаем один и тот же набор проблем. Первая — кеш формально вынесен в Redis, но сессии так и остались в файлах и продолжают блокировать запросы; человек думает, что кеш настроен, а половина выигрыша не получена. Вторая — памяти выделено заметно меньше, чем нужно под фактический объём кеша, поэтому идёт постоянное вытеснение и hit-rate болтается далеко от нужных значений. Третья — persistence включён в режиме, который грузит диск, на чисто летучем кеше, где он не нужен вовсе. Четвёртая — нет никакого мониторинга, и о проблемах с кешем узнают только из жалоб на медленный сайт.

Каждую из этих ошибок мы устраняем системно. Сессии переносим в подходящее хранилище с корректными блокировками. Память подбираем под реальный объём кеша с запасом и проверяем по метрике вытеснения. Persistence настраиваем там, где он оправдан, и убираем там, где он только мешает. И обязательно ставим мониторинг, чтобы состояние кеша было видно в любой момент. После такой ревизии кеш начинает действительно разгружать диск и базу, а не создавать видимость работы.

Возражения, которые мы слышим чаще всего

«У нас и так стоит Redis, разве этого мало». Само наличие Redis ещё не значит, что кеш настроен правильно. Часто видим, что в Redis выведен только обычный кеш, а сессии остались в файлах и продолжают блокироваться; или памяти выделено мало и идёт постоянное вытеснение; или persistence включён там, где он только грузит диск. Мы проводим аудит существующего Redis и доводим настройку до состояния, в котором кеш реально разгружает диск и базу.

«Memcached проще, зачем нам Redis». Иногда Memcached действительно достаточно — и тогда мы ставим именно его. Но если вам нужны общий кеш на кластер, сессии с блокировками или устойчивость к перезапускам, Memcached этого не даст. Мы объясняем разницу на вашей нагрузке и выбираем движок под задачу, а не по привычке.

«Боимся, что при переключении что-то сломается». Поэтому мы и работаем поэтапно: настраиваем и проверяем кеш на копии, прогоняем нагрузку, и только потом переключаем рабочий сайт. Кеш в памяти при правильной настройке прозрачен для приложения — Битрикс продолжает работать так же, только быстрее.

С чего начать

Начните с бесплатного аудита кеша и диска. Мы посмотрим, где сейчас лежит кеш и сессии, насколько загружен диск, какой у сайта hit-rate, и честно скажем, что даст вынос кеша в память и какой движок подойдёт. По итогам пришлём план работ и смету в течение рабочего дня. Обсудим ваш проект — и переведём кеш Битрикс из файлов на диске в быструю оперативную память, разгрузив диск и базу данных без остановки сайта.