В 2022 году на долю маркетплейсов приходится более 65% рынка онлайн-продаж в секторе B2C. На сегодняшний день площадки занимают основную долю рынка электронной коммерции, и их популярность растет с каждым днём.

Тренд последних лет  — маркетплейсы. 70% россиян хотя бы раз в месяц приобретают товары на площадках.

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

В статье мы рассмотрим, какие преимущества есть у современного асинхронного обмена над типовым, какие могут быть сложности при реализации, какие есть риски.

Стандартный обмен данными

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

• нехватка оперативной памяти,

• длительная выгрузка,

• падение сервера БД,

• таймаут соединения.

 Итог: типовой обмен устарел, при использовании требует доработок.

Обмен на Маркетплейсах

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

Но даже на мощном сервере стандартный импорт миллиона товаров занимает несколько дней, что неприемлемо для бизнеса.
Типовой обмен выполняется синхронной передачей данных. Это происходит следующим образом:

• формирование XML файла с товарами,

• передача данного файла на сайт,

• сбор и систематизация всей информации сайтом,

• непосредственно выгрузка.

Весь цикл может занимать несколько дней, зависит от структуры файла и объема данных. И цикл не будет завершен до тех пор, пока сайт не прогрузит весь файл, а 1С не получит отчет сайта о завершении процесса.

Рассмотрим частый сценарий: сайт — маркетплейс для сотрудников компании.

Полный обмен происходит 1 раз в неделю, частичные выгрузки — несколько раз в сутки. Номенклатурная база — 1 миллион товаров, + столько же картинок; 8 миллионов предложений; 64 тысячи свойств товаров; 100 разделов каталога.

В итоге, при использовании типового обмена получаем:

• 7 дней на полный обмен, 

• технические сложности, ограничения MySQL,

• появление ошибки «недостаточно памяти», таймаут выполнения скрипта.

Наличие таких проблем требует современного решения. 

Быстрый обмен

В качестве альтернативы мы применили асинхронный обмен данными с использованием промежуточной базы данных. Это помогает распределить нагрузку и ускорить сам процесс выгрузки.
Схема процесса:

• появление новых товаров в 1С,

• формирование пакета данных,

• выгрузка этого пакета в отдельную от сайта базу данных,

• сбор сайтом данных из этой БД.

Для этого процесса необходима доработка как со стороны сайта, так и со стороны 1С.

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

Плюсы и минусы использования очередей:

Реализация

Для ускоренного обмена необходимы серверные службы – отдельные серверы баз данных и менеджеры очередей. Чаще всего используется PostgreSQL и ActiveMQ.
PostgreSQL — используем в качестве промежуточной базы, где будут храниться данные, выгруженные из 1С.
ActiveMQ — популярный сервер от Apache, представляет из себя воплощение технологии JMS для асинхронного обмена данными.
Для продуктивного обмена требуется правильная настройка PostgreSQL и ActiveMQ. После этого создаются механизмы для постановки и обработки очереди. В итоговом варианте обмен выглядит следующим образом:

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

На примере реальной задачи клиента предлагаем рассмотреть решение проблемы.
Дано:
Маркетплейс с большим количеством свойств и картинок.

Найти: как максимально быстро выгрузить картинки и свойства

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

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

Загрузка свойств и обход ограничений Под свойствами товара подразумеваются тип товара и название. Инфоблок каталога не предназначен для загрузки 64 тысяч свойств — проблема в ограничениях MySQL.

Самым простым решением будет определение свойств, необходимых для фильтрации, и сохранение их в инфоблоке.
Все остальные свойства мы сохраним в отдельную таблицу (HL-блок) в виде сериализованной строки, так как они нужны только для показа карточки товара.
Мы создадим отдельную очередь для загрузки свойств с первым приоритетом. Тогда при полном обмене у нас сначала загрузятся свойства, и уже потом — товары.

Гаджет для мониторинга

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

Мы предлагаем использовать систему мониторинга, которая проверяет работоспособность сервиса, выводит метрики, а также выполняет детальное изучение: какой пакет грузится, каков его объем, есть ли ошибки в процессе импорта.

Для самостоятельного отслеживания этих метрик можно использовать разработку гаджета или страницу в админке Битрикса.

В этом гаджете можно найти всю информацию по обмену, состоянию служб сервера очередей (MQ) и системы управления БД. Также мы видим информацию по каждой метрике.

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

Монитор очередей обращается в API ActiveMQ и выводит состояние очередей в таблице. В нашем мониторинге отображено две очереди — для товаров и свойств.

Монитор обработки пакетов показывает, какие таблицы выгрузились и сколько еще осталось выгрузить.

С помощью истории обмена мы можем оценить, как долго выгружались товары и в каком объеме.

Монитор необработанных данных — указывает на возникающие сбои сервера и чрезмерную нагрузку на него.

Реализация асинхронного обмена потребует ~ 100 часов работы или 2 рабочих недели.
Более точная оценка будет зависеть от особенностей проекта, объема данных, структуры каталога, поставленных ТЗ.

Отдельным пунктом идет мониторинг обмена — требует дополнительных ~20 часов работы. При ограниченных ресурсах можно обойтись админкой MQ — она покажет объем очередей и факт обработки.

Основные преимущества асинхронного обмена 

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

Плюс сокращение времени на выгрузку: 2 дня против 7 при стандартном обмене.

Современные способы для работы с Маркетплейсами

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

Какой способ обмена данными выбирать — решать только вам. Нужно сопоставить все риски и подойти к этому решению взвешенно.