Redis и Memcached для кэша 1С-Битрикс

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

Ниже — практический разбор: чем Redis отличается от Memcached, как подключить внешний кэш к Битриксу через штатный модуль, как вынести туда сессии, настроить память, вытеснение и отказоустойчивость и не потерять данные при перезапуске. Это выжимка из наших проектов по ускорению сайтов на 1С-Битрикс — без общих слов, с конкретикой по модулям и конфигам.

Зачем Битриксу внешний кэш и хранилище сессий

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

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

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

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

Уровни кэширования в 1С-Битрикс

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

• Кэш компонентов. Готовый HTML и данные компонентов (меню, каталог, новости). Самый объёмный по количеству записей слой — именно он обычно и переезжает во внешнее хранилище.
• Управляемый кэш (managed cache). Кэш выборок ядра с тегированием: при изменении данных сбрасываются только связанные теги. Тоже кандидат на вынос во внешний кэш.
• Кэш ядра приложения. Служебные структуры: настройки модулей, таблицы соответствий, метаданные инфоблоков. Хранится в том же внешнем хранилище, что и managed cache.
• Композитный кэш. Статическая часть страницы, отдаваемая мгновенно ещё до старта PHP. Может складываться и в файлы, и во внешнее хранилище.
• Хранилище сессий. Формально не «кэш», но технически часто живёт в том же Redis/Memcached — об этом отдельный раздел.

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

Где файловый кэш становится узким местом

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

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

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

Третье, и решающее, — несколько серверов. Как только сайт живёт на двух и более узлах за балансировщиком, файловый кэш перестаёт быть общим. Либо вы синхронизируете файлы между серверами (медленно и хрупко), либо у каждого узла свой кэш, который прогревается независимо и может расходиться. Сессии в файлах ведут к тому, что пользователь, попавший на другой сервер, оказывается разлогинен. Ровно эту проблему внешнее хранилище решает по определению — оно одно на всех.

Redis против Memcached: сравнение

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

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

Архитектура подключения внешнего кэша

Важно понимать, что Битрикс не «ходит в Redis» напрямую из компонентов. Между кодом и хранилищем стоит слой абстракции кэша ядра — единый интерфейс, за которым скрывается конкретный движок: файлы, Memcached или Redis. Компонент просит ядро «дай данные по такому ключу», а какое хранилище отвечает — определяется настройкой, а не кодом. Это и есть причина, по которой смена движка кэша не требует переписывать компоненты.

Запрос за данными проходит по цепочке: компонент обращается к менеджеру кэша ядра, тот сериализует ключ и идёт во внешнее хранилище по TCP или через сокет. Если ключ найден (hit) — данные мгновенно возвращаются, PHP не делает тяжёлой работы. Если ключа нет (miss) — компонент честно пересчитывает данные (обращается к базе, рендерит) и кладёт результат в хранилище с временем жизни (TTL) и тегами. Следующий такой же запрос уже попадёт в кэш.

Хранилище при этом живёт как отдельный сервис — на том же сервере (обмен через локальный сокет, минимальная латентность) или на выделенной машине (обмен по сети, зато хранилище общее для кластера). Обе схемы валидны: на одиночном сервере Redis обычно ставят рядом с PHP и соединяют через Unix-сокет, а в кластере выносят на отдельный узел, к которому подключаются все веб-серверы.

Отдельно стоит понимать судьбу инвалидации. Тегированный кэш ядра хранит связи «тег → ключи» в том же внешнем хранилище. Когда меняется товар, ядро помечает соответствующие теги как устаревшие, и связанные ключи перестают отдаваться. Поэтому переезд управляемого кэша в Redis ускоряет не только чтение, но и сброс: то, что на файловой системе было обходом каталогов, в памяти становится операцией с множествами.

Хранилище сессий: почему это отдельная задача

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

Из этого различия вытекает главное правило: к хранилищу сессий требования по надёжности выше, чем к кэшу. Если для кэша вытеснение при нехватке памяти — норма, то для сессий вытеснение недопустимо: человек не должен разлогиниваться из-за того, что хранилищу не хватило места под очередной кэш каталога. Поэтому кэш и сессии либо разносят по разным базам одного Redis (разные номера db), либо по разным инстансам.

В 1С-Битрикс перенос сессий во внешнее хранилище настраивается через модуль «Веб-кластер», раздел управления сессиями. Там выбирается движок (Redis рекомендуется), адрес хранилища и режим. После включения PHP-сессии перестают писаться в файлы или базу и уходят в память Redis, общую для всех узлов. Это и есть тот механизм, который в кластере не даёт пользователю «слетать» при переключении между серверами.

Реализация в 1С-Битрикс: модули и файлы

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

• Модуль «Веб-кластер» (cluster). Даёт интерфейс в админке для управления кэшем компонентов, memcache/redis-серверами и хранилищем сессий. Через него же настраивается репликация базы и балансировка — но нас интересует именно раздел кэша и сессий.
• Файл bitrix/.settings.php. Основной конфиг ядра D7. В секции cache задаётся тип кэша (redis, memcache) и параметры подключения к хранилищу. Именно правка этой секции переводит кэш ядра на внешний движок.
• Файл bitrix/php_interface/dbconn.php. Историческое место для настроек кэша старого ядра и, в ряде конфигураций, сессий. На современных проектах основной точкой остаётся .settings.php, но dbconn.php всё ещё встречается.

Схематично секция кэша в .settings.php для Redis выглядит так: указывается тип redis, хост и порт (или путь к Unix-сокету), номер базы под кэш и, при необходимости, пароль. После сохранения ядро начинает складывать управляемый кэш и кэш компонентов в Redis. Проверить, что переезд состоялся, можно в разделе «Настройки → Производительность → Панель производительности»: там отображается текущий движок кэша.

Настройка Redis пошагово

Разберём подключение Redis в виде последовательности шагов — от установки сервиса до проверки эффекта. Порядок универсален и для одиночного сервера, и для выделенного узла кэша.

1. Установите и запустите Redis. Поставьте сервис из репозитория дистрибутива и убедитесь, что PHP-расширение для работы с Redis (phpredis) установлено и подключено — Битрикс работает через него.
2. Настройте доступ и безопасность. Если Redis на том же сервере — привяжите его к локальному адресу или Unix-сокету и не открывайте наружу. Если на выделенном узле — ограничьте доступ файрволом до веб-серверов и задайте пароль (requirepass).
3. Задайте лимит памяти и политику вытеснения. Для базы под кэш установите maxmemory и политику allkeys-lru: при нехватке памяти Redis сам вытеснит наименее используемые записи кэша.
4. Разведите кэш и сессии. Выделите под кэш одну базу (например, db0), под сессии — другую (db1) с политикой noeviction, либо поднимите два инстанса.
5. Пропишите кэш в .settings.php. В секции cache укажите тип redis, адрес, порт или сокет, номер базы и пароль. Сохраните и проверьте, что сайт открывается.
6. Переключите сессии. В модуле «Веб-кластер» включите хранение сессий в Redis, указав вторую базу или инстанс.
7. Прогрейте и проверьте. Пройдитесь по ключевым страницам, затем в панели производительности убедитесь, что движок кэша — Redis, hit rate растёт, а число обращений к базе упало.

Настройка Memcached пошагово

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

1. Установите Memcached и расширение PHP. Поднимите сервис и подключите PHP-расширение (memcached или memcache) — через него Битрикс общается с хранилищем.
2. Ограничьте доступ. Привяжите Memcached к локальному адресу или закройте файрволом. По умолчанию у него нет аутентификации, поэтому наружу его выставлять нельзя.
3. Задайте объём памяти. Установите лимит (-m) с запасом под пиковый объём кэша, чтобы вытеснение не выбрасывало горячие записи слишком рано.
4. Пропишите сервер в настройках кэша. В .settings.php или через модуль «Веб-кластер» укажите тип memcache и адрес сервера.
5. Проверьте эффект. Прогрейте кэш и убедитесь по панели производительности, что записи уходят в Memcached и hit rate высокий.

Память и политики вытеснения

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

Логика проста. Для кэша вытеснение — это благо: если памяти не хватает, пусть уйдут редко используемые записи, ведь их всегда можно пересчитать. Поэтому базе под кэш ставят allkeys-lru (или allkeys-lfu, если хочется удерживать именно частые обращения). Для сессий вытеснение — катастрофа: удалённая сессия означает разлогин или потерю корзины. Поэтому базе под сессии ставят noeviction и выделяют памяти с запасом, а рост объёма отслеживают мониторингом.

Отдельно про объём памяти. Считать его нужно от пикового рабочего набора: сколько уникальных страниц и выборок реально держится в кэше в час пик, плюс объём активных сессий. Слишком маленький лимит приведёт к постоянному вытеснению и падению hit rate — кэш будет «протухать» быстрее, чем приносить пользу. Слишком большой — просто съест RAM, которую можно было отдать базе или PHP. Здоровый ориентир — чтобы hit rate держался выше 90–95% без агрессивного вытеснения.

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

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

Персистентность. Первый уровень защиты — сохранение на диск. Redis умеет делать периодические снимки (RDB) и вести журнал операций (AOF). Для сессий это позволяет пережить плановый перезапуск сервиса без потери авторизаций. Для чистого кэша персистентность обычно не нужна — потеря кэша не страшна, а запись на диск лишь тратит ресурсы.

Репликация. Второй уровень — реплика (replica): второй Redis, который в реальном времени копирует данные с основного. Если основной падает, реплику можно повысить до основного. Автоматизирует переключение Redis Sentinel — он следит за здоровьем узлов и сам переводит нагрузку на реплику при отказе.

Кластер. Третий уровень — Redis Cluster, который шардирует данные по нескольким узлам и обеспечивает и масштабирование, и отказоустойчивость. Это уже история для крупных highload-проектов; большинству магазинов достаточно связки «основной + реплика + Sentinel».

Важно трезво оценивать, что вам действительно нужно. Для одиночного сайта средней нагрузки отказоустойчивость кэша часто избыточна: при падении Redis сайт переживёт на файловом кэше как fallback, если это предусмотреть. А вот если в Redis лежат сессии и разлогин пользователей недопустим — репликация становится обязательной. Тему масштабирования и резервирования инфраструктуры мы подробно разбираем в статье про веб-кластер и масштабирование 1С-Битрикс.

Кэш в веб-кластере

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

Внешнее хранилище снимает это по определению. Один Redis (или связка «основной + реплика») обслуживает все узлы: кэш общий, сессии общие. Балансировщик может распределять запросы как угодно — хоть round-robin, хоть по нагрузке, — и пользователь этого не заметит, потому что его сессия и прогретый кэш доступны с любого сервера. Это развязывает руки при масштабировании: чтобы добавить мощности, достаточно поднять ещё один веб-узел, а хранилище кэша и сессий остаётся единой точкой согласованности.

Здесь важно не создать новое узкое место. Раз хранилище общее и критичное, оно должно быть быстрым (низкая сетевая латентность до веб-узлов) и отказоустойчивым (реплика на случай падения). На практике Redis под кластер выносят на отдельную машину в той же локальной сети, что и веб-серверы, с гигабитным соединением, а для сессий обязательно поднимают реплику. Композитный кэш при этом тоже удобно держать во внешнем хранилище, чтобы статическая часть страниц была общей для узлов — про сам композит есть отдельный разбор в статье про композитный сайт на 1С-Битрикс.

Смежный вопрос — общая логика кэширования на уровне приложения: какие компоненты кэшировать, с какими тегами и TTL. Внешнее хранилище ускоряет доступ, но не заменяет грамотную стратегию кэша. Как выстроить эту стратегию в Битриксе, мы разбираем в материале про кэширование в 1С-Битрикс.

Мониторинг и метрики

«Подключили Redis» — это не результат, а начало. Чтобы понимать, работает ли кэш эффективно и не превратился ли он в узкое место, нужно смотреть на метрики. Вот ключевые ориентиры.

Порядок диагностики такой. Сначала смотрите hit rate: если он низкий (скажем, 60–70%), кэш работает плохо — либо мал объём памяти и идёт вытеснение, либо TTL слишком короткие, либо кэш часто сбрасывается тегами. Затем смотрите evictions: рост вытеснений при низком hit rate — прямой сигнал, что памяти не хватает. Параллельно сверяйте нагрузку на базу: если после подключения кэша число SQL-запросов на страницу не упало, значит горячие данные почему-то не кэшируются — стоит проверить, что кэш компонентов вообще включён.

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

Частые ошибки

• Хранят кэш и сессии в одной базе Redis с политикой allkeys-lru — под нагрузкой хранилище вытесняет сессии, и пользователи молча разлогиниваются.
• Выставляют политику noeviction базе под кэш — при заполнении памяти новые записи кэша перестают приниматься, и сайт замедляется вместо ускорения.
• Выбирают Memcached там, где нужны сессии, — при перезапуске сервиса весь кэш и сессии теряются, а сайт получает «холодный» старт под трафиком.
• Выставляют Redis или Memcached наружу без пароля и файрвола — открытое в интернет хранилище без аутентификации становится дырой в безопасности.
• Занижают лимит памяти — постоянное вытеснение роняет hit rate, и кэш «протухает» быстрее, чем приносит пользу.
• Не настраивают отказоустойчивость для сессий в кластере — падение единственного Redis выбрасывает всех пользователей из аккаунтов.
• Считают, что внешний кэш ускорит некэшируемый код — если компонент выключил кэш или каждый запрос сбрасывает теги, переезд в Redis не поможет.
• Подключили Redis, но забыли проверить по метрикам — движок кэша остался файловым, а «ускорения нет», потому что переезд фактически не состоялся.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность внешнего кэша перед выкладкой на бой.

1. Движок выбран осознанно. Redis — если нужны сессии, репликация и переживание рестарта; Memcached — если хватает лёгкого кэша без надёжности.
2. Кэш и сессии разделены. Разные базы Redis или разные инстансы: кэшу — allkeys-lru, сессиям — noeviction.
3. Память рассчитана. Лимит maxmemory задан от пикового рабочего набора, с запасом под сессии; вытеснения не агрессивны.
4. Безопасность закрыта. Хранилище привязано к локальному адресу или закрыто файрволом, задан пароль, наружу ничего не торчит.
5. Кэш прописан в .settings.php. Тип redis/memcache, адрес, база; переезд подтверждён в панели производительности.
6. Сессии переключены. В модуле «Веб-кластер» сессии переведены во внешнее хранилище, проверено, что авторизация держится.
7. Отказоустойчивость под сессии. Для кластера и критичных сессий поднята реплика (и Sentinel), при необходимости включена персистентность.
8. Метрики на контроле. Hit rate выше 90–95%, evictions низкие, нагрузка на базу упала; настроены алерты на память и hit rate.

Вывод

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