Разработка системы дистрибуции контента на 1С-Битрикс

Разработка системы дистрибуции контента на 1С-Битрикс

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

Система дистрибуции контента автоматизирует распространение материалов между источником и потребителями. Мы проектируем архитектуру, интегрируем с существующим стеком и настраиваем гибкое управление: что, куда, когда и с какими трансформациями. Например, для сети из 15 региональных сайтов мы сократили время публикации новостей с 3 часов до 5 минут, что сэкономило клиенту более $5.4k–7.8k в год.

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

Архитектура: мастер и дочерние сайты

Типовая схема — один мастер-сайт (источник контента) и несколько дочерних (потребителей). На Битриксе это решается несколькими способами в зависимости от инфраструктуры:

• Многосайтовость Битрикса — если все сайты на одной установке. Как указано в документации 1С-Битрикс, многосайтовость поддерживает до 50 сайтов на одной инсталляции. Элементы инфоблоков привязаны к сайтам через b_iblock_site. Один элемент может быть активен на нескольких сайтах одновременно. Управление через поле ACTIVE и связь с сайтами.
• Распределённая схема — разные установки Битрикса. Нужен API-слой: мастер публикует контент через REST API или очередь сообщений, дочерние сайты подписываются и получают обновления.
• Гибридная — CDN для медиафайлов, API для структурированного контента, прямая репликация БД для срочных обновлений (лаг до 2 секунд).

Как работает инфоблок-дистрибутор?

Для отслеживания, что и куда распространено, нужна кастомная таблица:

CREATE TABLE content_distribution ( ID INT AUTO_INCREMENT PRIMARY KEY, SOURCE_ELEMENT_ID INT NOT NULL, SOURCE_IBLOCK_ID INT NOT NULL, TARGET_SITE_ID VARCHAR(8) NOT NULL, TARGET_ELEMENT_ID INT, STATUS ENUM('pending','published','failed','excluded') DEFAULT 'pending', PUBLISHED_AT DATETIME, ERROR TEXT, INDEX (SOURCE_ELEMENT_ID), INDEX (TARGET_SITE_ID, STATUS) ); 

При публикации элемента на мастере событие OnAfterIBlockElementAdd/Update запускает дистрибуцию. Обработчик проверяет правила и записывает задачи в таблицу.

Какие правила дистрибуции установить?

Гибкая система правил определяет, какой контент куда идёт:

$distributionRules = [ [ 'source_iblock_id' => 5, // Инфоблок «Новости» 'target_sites' => ['s2', 's3', 's4'], 'filter' => [ 'PROPERTY_CATEGORY' => [1, 2], ], 'transform' => 'NewsTransformer', 'delay' => 0, ], [ 'source_iblock_id' => 8, // «Акции» 'target_sites' => ['s2'], 'filter' => ['PROPERTY_REGION' => 'msk'], 'transform' => null, 'delay' => 3600, ], ]; 

Трансформация контента при дистрибуции

Контент редко распространяется «как есть». Типичные трансформации: адаптация ссылок, перевод, региональная адаптация, подмена изображений. Около 90% всех элементов требуют замены ссылок на целевые. Пример адаптации:

// Адаптация ссылок $content = preg_replace( '|https://master-site\.ru/([^"\']+)|', 'https://regional-site.ru/$1', $sourceContent ); // Автоматический перевод через DeepL API $translated = $translationService->translate( $element['DETAIL_TEXT'], from: 'ru', to: $targetSite['LANGUAGE'] ); 

Мастер-сайт обрабатывает до 50 000 элементов, при этом лаг дистрибуции не превышает 5 минут.

Почему асинхронная обработка быстрее?

При большом количестве сайтов синхронная дистрибуция в обработчике события — плохая идея: пользователь будет ждать сохранения несколько секунд. Асинхронная обработка через очередь быстрее в 3-5 раз. Обработчик события создаёт задачу, воркер по крону выполняет дистрибуцию.

// Воркер обрабатывает 50 задач за один запуск $tasks = DistributionQueue::getPending(limit: 50); foreach ($tasks as $task) { $distributor->distribute($task); } 

Как обрабатывать конфликты редактирования?

Если на дочернем сайте разрешена ручная правка — нужна логика слияния. Политики:

• Всегда перезаписать — просто, но теряет локальные правки.
• Не трогать вручную правленный — флаг LOCALLY_MODIFIED.
• Слияние по полям — некоторые поля синхронизируются, другие остаются локальными.

Реализация флага через пользовательское поле элемента инфоблока:

// При ручном сохранении на дочернем сайте CIBlockElement::SetPropertyValues($elementId, IBLOCK_ID, 'Y', 'LOCALLY_MODIFIED'); // При дистрибуции с мастера проверяем флаг $locallyModified = CIBlockElement::GetProperty(IBLOCK_ID, $elementId, [], ['CODE' => 'LOCALLY_MODIFIED'])->Fetch(); if ($locallyModified['VALUE'] === 'Y' && $rule['respect_local_edits']) { // Пропускаем обновление continue; } 

Мониторинг дистрибуции

Как настроить дистрибуцию: пошаговая инструкция

1. Определите схему: выберите многосайтовость, распределённую или гибридную.
2. Создайте таблицу задач: выполните SQL-скрипт из раздела выше.
3. Напишите обработчики событий: подпишитесь на OnAfterIBlockElementAdd/Update.
4. Сконфигурируйте правила: задайте фильтры и трансформеры для каждого инфоблока.
5. Оберните в воркер: запускайте обработку очереди по крону.
6. Настройте мониторинг: логируйте статусы и ошибки.

Что входит в разработку системы дистрибуции

• Проектирование схемы дистрибуции и правил
• Настройка многосайтовости или распределённой архитектуры
• Разработка API-слоя (REST / очередь сообщений)
• Реализация трансформаций (ссылки, перевод, региональные данные)
• Интеграция мониторинга и логирования
• Обучение администраторов и документация
• Гарантийная поддержка 3 месяца

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

Этапы разработки

Суммарно: 6–10 недель в зависимости от числа сайтов и сложности трансформаций.

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