Консультирование по масштабированию проекта 1С-Битрикс
Сайт начинает падать под нагрузкой — 500 одновременных пользователей, распродажа, «чёрная пятница». Один сервер упирается в CPU или I/O. Горизонтальное масштабирование Битрикс возможно, но требует специфических решений: сессии не должны привязываться к конкретной машине, кеш должен быть разделяемым, загружаемые файлы — доступны со всех узлов.
Архитектура кластера Битрикс
Битрикс поддерживает кластерную конфигурацию в редакции Business и выше («Масштабирование»). Компоненты типовой кластерной схемы:
[Балансировщик: nginx / HAProxy]
|
+---------+
| |
[Web-1] [Web-2] ... [Web-N] — PHP-FPM
| |
+---------+
|
[Shared storage: GlusterFS / NFS / S3] — /upload/, /bitrix/cache/
|
[Redis cluster] — сессии, управляемый кеш
|
[MySQL / PostgreSQL Master] → [Slave-1] [Slave-2]
Сессии и кеш
Сессии. Стандартный PHP хранит сессии в файлах на локальном диске — при нескольких серверах пользователь теряет авторизацию при попадании на другой узел. Решение: перевести сессии в Redis.
В /bitrix/.settings.php:
'session' => [
'value' => [
'mode' => 'default',
'handlers' => [
'general' => [
'type' => 'redis',
'host' => '127.0.0.1',
'port' => '6379',
],
],
],
],
Управляемый кеш Битрикс (ManagedCache) также переводится на Redis:
'cache' => [
'value' => [
'type' => 'redis',
'redis' => ['host' => 'redis-host', 'port' => 6379],
],
],
Разделяемое файловое хранилище
Директории /upload/ и /bitrix/cache/ (дисковый кеш) должны быть общими для всех web-узлов. Варианты:
| Решение | Когда использовать |
|---|---|
| NFS | Простые конфигурации, один NFS-сервер |
| GlusterFS | Отказоустойчивость, распределённое хранилище |
| S3-совместимое (MinIO, Ceph) | Облачный деплой, большой объём файлов |
| CDN + объектное хранилище | Глобальная доставка медиа |
Для Битрикс: модуль disk и загрузки (/upload/) монтируются на общую FS. Кеш лучше перевести на Redis и отключить дисковый кеш полностью.
Репликация базы данных
Битрикс поддерживает работу с несколькими хостами БД через DBConnectionPool в /bitrix/.settings.php. Записи идут на Master, чтения — на Slave. Конфигурация:
'connections' => [
'value' => [
'default' => [
'host' => 'db-master',
...
],
'slave' => [
'host' => 'db-slave-1',
...
],
],
],
Кастомный код должен явно указывать соединение для чтения через Application::getConnection('slave').
Узкие места при масштабировании
Агенты. Стандартные агенты Битрикс вызываются в web-потоке при каждом хите. На кластере это означает конкурентное выполнение одного агента на нескольких узлах. Решение: вынести агенты в отдельный cron-процесс на одном сервере, отключив web-вызов через BX_CRONTAB.
Генерация PDF и тяжёлые задачи. Генерация документов, отчётов, пакетные операции не должны выполняться в web-потоке. Нужна очередь задач — RabbitMQ или Redis Queue — с воркерами на отдельных серверах.
Обновление ядра в кластере. Rolling update без даунтайма: обновляем узлы по одному, при условии обратной совместимости обновления с текущей версией БД.
Нагрузочное тестирование
Перед масштабированием — нагрузочное тестирование на staging, идентичном продакшну. Инструменты: Apache JMeter, k6, Yandex.Tank. Тестируем:
- Страница каталога с фильтром
- Оформление заказа (транзакции в БД)
- AJAX-запросы (корзина, фильтр)
Результат: кривая деградации производительности по мере роста нагрузки, bottleneck — CPU, RAM, I/O или БД.
Что входит в консультирование по масштабированию
- Анализ текущих узких мест под нагрузкой (профилирование, мониторинг)
- Проектирование целевой кластерной архитектуры
- Рекомендации по конфигурации Redis, балансировщика, репликации БД
- Настройка разделяемого файлового хранилища
- Перевод сессий и кеша Битрикс на Redis
- Вынос агентов и тяжёлых задач из web-потока
- Методология нагрузочного тестирования и оценка результата