Хранение сессий — критичный вопрос в веб-кластере: если сессия лежит локально на ноде, при балансировке пользователь теряет авторизацию и корзину. Разберём, куда выносить сессии в 1С-Битрикс и как это настроить.
Почему локальные сессии ломают кластер
По умолчанию PHP хранит сессии в файлах на диске веб-сервера (session.save_handler = files). В кластере запросы одного пользователя балансировщик может отправлять на разные ноды. Если сессия лежит только на первой ноде, вторая её не увидит — пользователь окажется разлогинен, а корзина опустеет.
Есть два пути решения: либо «приклеить» пользователя к одной ноде (sticky-сессии), либо вынести сессии в общее хранилище. Первый путь хрупок: падение ноды теряет все её сессии. Правильный путь — общее хранилище, тогда ноды остаются взаимозаменяемыми.
Варианты хранения сессий
1С-Битрикс поддерживает несколько бэкендов для сессий, выбор задаётся в настройках модуля кластера и в конфигурации:
| Бэкенд | Плюсы | Минусы |
|---|---|---|
| База данных (MySQL) | Надёжно, переживает перезапуск | Нагрузка на мастер БД |
| memcached | Быстро, разгружает БД | Данные теряются при рестарте |
| Redis | Быстро + персистентность | Требует отдельной настройки |
Для большинства кластеров разумен компромисс: сессии в memcached/Redis ради скорости, но с пониманием, что при полном сбросе кеша пользователи разлогинятся.
Сессии в базе данных
Хранение сессий в БД включается в разделе Настройки → Веб-кластер → Управление сессиями. Битрикс переносит сессии в таблицу и подменяет обработчик сессий на собственный. Все ноды пишут в общую БД, поэтому авторизация консистентна.
- Плюс — сессии переживают перезапуск memcached и самих нод.
- Минус — дополнительная нагрузка записи на мастер MySQL; на очень высоких RPS это узкое место.
- Таблицу сессий стоит держать на быстром хранилище и периодически чистить от протухших записей.
Этот вариант выбирают, когда надёжность сессии важнее пиковой производительности — например, в B2B-порталах с длинными пользовательскими сценариями.
Сессии в memcached
Для высоконагруженных проектов сессии чаще выносят в memcached — это снимает нагрузку записи с БД. Настройка на уровне PHP:
session.save_handler = memcached
session.save_path = "10.0.0.21:11211,10.0.0.22:11211"При пуле из нескольких memcached ключи сессий распределяются по серверам. Важно, чтобы все веб-ноды использовали один и тот же пул в одинаковом порядке, иначе хеширование даст разные узлы.
Redis как хранилище сессий
Redis — компромисс между скоростью memcached и надёжностью БД: он держит данные в памяти, но умеет сохранять их на диск (RDB/AOF). В BitrixVM Redis доступен «из коробки» и часто используется и под кеш, и под сессии.
session.save_handler = redis
session.save_path = "tcp://10.0.0.30:6379?database=1"Отдельная база (database=1) под сессии отделяет их от кеша, чтобы очистка кеша не затрагивала авторизацию. Для отказоустойчивости Redis разворачивают в режиме Sentinel или Cluster.
Проверка и типичные ошибки
После настройки нужно убедиться, что сессия действительно общая для всех нод. Практический тест — авторизоваться и целенаправленно «прыгать» по нодам, проверяя, что авторизация держится.
- Убедитесь, что
session.save_pathодинаков на всех нодах. - Проверьте, что часы нод синхронизированы (NTP) — рассинхрон времени ломает тайм-ауты сессий.
- Согласуйте
session.gc_maxlifetimeи настройки очистки, чтобы сессии не протухали раньше времени. - Не смешивайте бэкенды на разных нодах — иначе часть пользователей будет разлогиниваться.
Итог
В кластере сессии обязаны быть общими для всех веб-нод — только так узлы остаются взаимозаменяемыми. Выбор бэкенда — баланс надёжности и скорости: БД надёжнее, но грузит мастер; memcached быстрее, но без персистентности; Redis даёт разумный компромисс. Главное — единая конфигурация на всех нодах и синхронизация времени.
Мы настраиваем хранение сессий под конкретный профиль нагрузки: выбираем бэкенд, разносим сессии и кеш, обеспечиваем отказоустойчивость хранилища и проверяем консистентность авторизации по всем нодам кластера.
Частые вопросы
Почему нельзя оставить файловые сессии в кластере?
Файловая сессия лежит на диске одной ноды. При балансировке запрос уйдёт на другую ноду, которая её не увидит, и пользователь разлогинится. Нужно общее хранилище.
Что лучше — сессии в БД или в memcached?
БД надёжнее и переживает перезапуски, но грузит мастер. memcached быстрее и разгружает БД, но теряет данные при рестарте. Выбор зависит от требований к нагрузке и надёжности.
Теряются ли сессии при перезапуске memcached?
Да. memcached хранит данные только в оперативной памяти, поэтому его перезапуск или вытеснение по памяти сбросит сессии и пользователи разлогинятся.
Чем Redis лучше memcached для сессий?
Redis тоже работает в памяти, но умеет сохранять данные на диск (RDB/AOF) и поддерживает отказоустойчивые режимы Sentinel/Cluster, поэтому сессии переживают перезапуск.
Нужны ли sticky-сессии при общем хранилище?
Нет. Если сессии в общем хранилище, ноды взаимозаменяемы и липкость не нужна. Sticky-сессии — обходной путь, который хрупок при падении ноды.
Почему важно синхронизировать время на нодах?
Тайм-ауты и срок жизни сессий считаются по времени сервера. Рассинхрон часов между нодами приводит к преждевременному протуханию сессий.
Можно ли хранить кеш и сессии в одном Redis?
Можно, но лучше разнести их по разным базам (database). Тогда очистка кеша не затронет сессии и не разлогинит пользователей.
Поможем с настройкой и поддержкой Для разработчиков
Поможем с настройкой, доработкой и поддержкой Для разработчиков.