Масштабирование и веб-кластер
Горизонтальное масштабирование веб-нод требует выноса пользовательских сессий и кеша в распределенный Redis, а также синхронизации файлов каталога /upload. Репликация базы данных master-slave опирается на модуль веб-кластера (редакция «Энтерпрайз»), автоматически направляя операции чтения на slave-реплики, а операции модификации данных — строго на master.
Прогресс хранится в этом браузере. Войдите, чтобы сохранить его в аккаунте.
Что нужно понимать
-
1
Шардинг
-
2
Репликация (Master-Slave)
-
3
Кластеризация
Материалы
Официальная документация
-
Шардинг Новая дока
-
HandlerSocket Новая дока
Проверь себя
Заказчик на редакции «Малый бизнес» хочет slave-базу. Что ему сказать?
Без модуля cluster ConnectionPool::getSlaveConnection() возвращает null, балансировки не будет. Модуль есть только в Энтерпрайзе; на других редакциях сначала разносить базу и PHP по разным серверам.
После записи заказа код прочитал старые данные. Как это возможно при репликации?
Пул держит на master только таблицы, изменённые в этом хите; в следующем хите чтение уйдёт на slave, который может отставать. Для чтения сразу после записи — useMasterOnly(true) или StartUsingMasterOnly().
Подняли вторую веб-ноду, пользователей разлогинивает. Где причина?
Сессии и кеш в файлах на локальном диске каждой ноды. Нужен общий Redis для секций session и cache, плюс синхронизация /upload и html_pages.
Поможет ли шардинг из коробки разгрузить таблицы каталога?
Нет: доступен только вертикальный шардинг для модулей веб-аналитики и поиска. Каталог и заказы остаются в основной базе.
Не сходится?
Спросите ассистента BXMax: он знает документацию и материалы сайта по этой теме.
Знаете материал лучше?
Предложите ссылку: после проверки она появится в этом разделе.
Войти, чтобы предложить