Розробка системи дистрибуції контенту на 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 тижнів залежно від кількості сайтів та складності трансформацій.

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