PrestaShop с несколькими магазинами: память, база и разделение доменов

У компании три витрины: на одном домене продают инструменты, на другом расходники для них, на третьем идёт оптовая распродажа. Снаружи это три независимых сайта с разным оформлением. Внутри всё может оказаться одним магазином, у которого просто несколько адресов и набор общих настроек. Именно эта разница между «несколькими сайтами» и «одним магазином с несколькими лицами» определяет, понадобится ли вам multistore, и сколько ресурсов сервера придётся под него отдавать.

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

Оговорка про версии: описание режимов совместного использования ниже опирается на документацию PrestaShop 8. Если у вас другая версия, названия опций и порядок действий в интерфейсе могут отличаться, и сверять их нужно со своей установкой.

Что витрины делят между собой на самом деле

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

Документация PrestaShop 8 о группах магазинов описывает три уровня контекста, в котором вы меняете настройки: все магазины, группа магазинов или один магазин. Это важная деталь интерфейса: любая правка делается в каком-то контексте, и от выбранного контекста зависит, на кого она распространится. Можно изменить параметр для всей системы, для одной группы или для единственной витрины. Администратор, который по привычке работает в режиме «все магазины», рискует задеть витрины, о которых в этот момент не думал.

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

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

Три вопроса к бизнесу вместо технических параметров

Прежде чем создавать второй магазин, полезно ответить на вопросы, которые вообще не про сервер:

• Должен ли один человек входить в аккаунт на обеих витринах под одним логином? Если да, нужны общие покупатели. Если юридически или по маркетингу это разные бренды, общая база клиентов может быть не плюсом, а проблемой.
• Должны ли остатки быть единым пулом? Если склад один и товар продаётся через несколько витрин, общие количества спасают от продажи одной и той же последней единицы дважды. Если у каждой витрины свой склад и свой ассортимент, общий пул только мешает.
• Хотите ли вы видеть заказы всех витрин одним списком? Это удобно владельцу, но заказы можно объединять лишь вместе с покупателями и остатками, так что вопрос о заказах на деле является вопросом обо всём пакете сразу.

Если на все три вопроса честный ответ «нет», то вы, скорее всего, имеете дело не с одним магазином на несколько лиц, а с несколькими независимыми бизнесами. Тогда multistore даёт вам не пользу, а лишнюю связанность.

Пара магазинов на конкретном примере

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

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

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

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

Как привязывается адрес к магазину

У каждого магазина в multistore есть собственный адрес, по которому система понимает, какую витрину показать посетителю. Запрос приходит на домен, PrestaShop сопоставляет его с магазином и подгружает настройки этого контекста: тему, цены, видимые товары. Для вас как для администратора сервера отсюда следует практическое правило: каждый домен должен вести на один и тот же код PrestaShop, а не на разные каталоги. Если вы разведёте домены по разным папкам, получится не multistore, а несколько самостоятельных установок, и общие настройки между ними работать перестанут.

Для веб-сервера это означает, что виртуальные хосты всех доменов указывают на один корневой каталог приложения, а сертификаты выпускаются на каждый домен отдельно. Конкретный синтаксис зависит от выбранного веб-сервера и порядка, описанного в документации PrestaShop для вашей версии, здесь мы его не фиксируем. Процесс первичной подготовки сервера под магазин разобран в статье про установку PrestaShop на VPS, и к multistore его стоит применять уже после того, как базовая установка работает.

Одна база, много витрин: где копится нагрузка

Теперь о том, ради чего многие вообще читают подобные статьи: сколько памяти нужно. Честный ответ начинается с признания, что формулы «столько-то мегабайт на домен» не существует. Два магазина с тремя сотнями товаров и редкими заказами могут уместиться на скромной конфигурации, а один магазин с огромным каталогом и активными акциями способен упереться в ресурсы быстрее, чем пять тихих витрин.

Что в действительности определяет потребление, если разложить его по причинам:

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

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

Почему единая база — это и достоинство, и узкое место

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

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

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

Фоновые задачи как скрытый потребитель

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

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

Какой размер VPS подходит и почему не стоит искать магическое число

Линейка VPS MAATRIX построена ступенями: от конфигурации с 1 vCPU, 2 ГБ памяти и 40 ГБ NVMe до варианта с 16 vCPU, 32 ГБ и 320 ГБ. Диски на NVMe, процессоры AMD EPYC, доступ root. Сопоставлять эти ступени с числом магазинов напрямую не получится, и обещать, что на какой-то из них «поместятся три витрины», было бы нечестно.

Но логику выбора выстроить можно. Начните с наименее затратного вопроса: хватает ли вам одной ступени для замеров? Для проверки гипотез и пробной установки может быть достаточно небольшой конфигурации, а решение о размере принимается уже по результатам наблюдений. Дальше смотрите на узкое место:

• Если упирается память — растёт число одновременных процессов PHP или буферы базы не помещаются. Помогает более крупная ступень по RAM или более аккуратная настройка пулов.
• Если упирается процессор — тяжёлые выборки, генерация страниц без кэша, фоновые пересчёты. Помогает увеличение числа ядер, но сначала стоит проверить кэширование.
• Если упирается диск — большой каталог с изображениями и интенсивная работа базы. Объём и скорость NVMe здесь играют роль, но его размер надо сверять с объёмом каталога и ростом базы.

Отдельное замечание о том, что «один сервер» не равно «одно окружение». На VPS можно развернуть несколько независимых установок PrestaShop рядом друг с другом, каждую со своей базой, своим пользователем и своим каталогом. Это и есть главная альтернатива multistore, и она возвращает нас к следующему разделу.

Общая админка против независимости: цена удобства

Главный аргумент за multistore — единая точка управления. Один вход в панель, один каталог, один набор модулей, общие отчёты. Для команды, которая управляет несколькими витринами одного бизнеса, это реальная экономия времени. Не нужно трижды заводить один и тот же товар, трижды обновлять модули, трижды поддерживать три копии одной и той же системы.

Но у этого удобства есть цена, и платится она независимостью. Когда у вас одна установка, версия PrestaShop у всех витрин одна. Обновление ядра — это обновление для всех магазинов сразу. Установка модуля делает его доступным в системе, и хотя включать его можно по контексту, сам код общий. Если модуль некорректно ведёт себя после обновления, страдает не одна витрина, а все, кто его используют.

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

Когда отдельные установки удобнее

Раздельные окружения выигрывают в нескольких ситуациях, которые легко распознать по вопросам к бизнесу:

• Витрины принадлежат разным юридическим лицам или разным владельцам. Multistore не обеспечивает жёсткую изоляцию компаний: администраторы работают в одной системе, данные лежат в одной базе. Если разным людям нельзя видеть данные друг друга по договору или по соображениям конфиденциальности, общей установки лучше избегать.
• Витринам нужны разные темпы обновлений. Одна готова перейти на новую версию, другая зависит от модуля, который ещё не совместим.
• Ассортимент, покупатели и склады у витрин не пересекаются. В этом случае общая админка почти ничего не даёт, а связанность остаётся.
• Нужны разные наборы модулей и разные настройки сервера, например разные версии PHP или параметры кэширования.

Общая установка выигрывает, когда бизнес один, ассортимент пересекается, склад общий, а управляет витринами одна команда. Здесь multistore экономит и время, и ресурсы: нет дублирования каталога, остатки не расходятся, а покупатели не заводят два аккаунта.

Что происходит, когда меняется общий компонент

Самое трудное в multistore — не первоначальная настройка, а жизнь после. Общий компонент, который меняют ради одной витрины, меняется для всех. Разберём несколько типичных случаев, чтобы понять механику.

Обновление версии PrestaShop. Оно затрагивает код, а код у всех магазинов один. Если одна витрина использует специфичный модуль, который после обновления перестал работать, придётся либо откладывать обновление для всех, либо чинить модуль, либо отказываться от него. Планировать обновление нужно сразу с учётом самой требовательной витрины, а проверять его — на копии, где видно поведение каждого домена.

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

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

Решение о совместном использовании. Как уже говорилось, часть опций нельзя отключить после появления клиентов или заказов. Это изменение общего компонента, которое нельзя откатить кнопкой. Его стоит рассматривать как архитектурное решение уровня «выбор фундамента», а не как настройку.

Как снизить риск, не отказываясь от общей установки

Если вы выбрали multistore, часть опасностей можно смягчить дисциплиной:

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

Как выбрать окружение под свою ситуацию

Если свести сказанное к рабочему алгоритму, он выглядит так. Сначала определите, что у витрин общее по смыслу бизнеса: покупатели, склад, каталог, команда. Если общее почти всё — берите multistore и тратьте силы на дисциплину работы с контекстами. Если общего мало — берите отдельные установки, даже на одном VPS, и учитывайте, что ресурсы сервера они всё равно делят.

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

Под такие задачи подходит VPS с root-доступом: на нём вы сами выбираете веб-сервер, версию PHP, параметры СУБД и схему размещения установок. Серверы MAATRIX доступны в локациях UK, US, RU и FR, оплата возможна картой РФ или через СБП, а VPS создаётся автоматически через пару минут после оплаты. Наличие нужного образа и операционной системы в конкретной локации лучше проверить в форме заказа до оплаты.

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