← На главную

Рассмотрим ситуацию, близкую к критической: имеется переписанная база 1С:Розница с более чем 200 узлами распределенной информационной базы (РИБ). Узлы разделены на два центра (примерно по 100 магазинов в каждом). Проблема заключается в том, что штатный обмен между двумя центрами идет нестабильно и крайне долго — от 10 до 12 часов. При этом каждый центр обменивается со своими периферийными узлами достаточно быстро. Проанализируем причины такого поведения и разберем по шагам эффективные методы решения этой сложной инфраструктурной задачи.

Анализ причин медленного обмена в крупных РИБ

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

1. Отсутствие миграции движений: Как часто бывает в переписанных конфигурациях, в настройках плана обмена может быть отключена передача движений документов. В результате переносятся только сами документы, которые при загрузке во второй центр начинают заново перепроводиться. Проведение тысяч документов за период вызывает колоссальные задержки и блокировки.
2. Транзакционные блокировки на уровне СУБД: Загрузка огромного файла обмена (XML) в одну транзакцию приводит к блокировке ключевых таблиц базы данных.
3. Переполнение таблиц регистрации изменений: Накапливается «мусор», битые ссылки и изменения технических регистров, которые не нужны во втором узле, но система тратит время на их выгрузку.
4. Избыточность исторических данных: Передача каждого пробитого чека ККМ (особенно в рознице) лавинообразно увеличивает объем пакетов обмена.

Решение 1: Многопоточность и разделение планов обмена

Разберем идею с разделением потоков данных. Создание нескольких независимых планов обмена (например, группировка магазинов по 5-10 штук в отдельные пулы) — это полностью рабочая практика для высоконагруженных систем.

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

Важное условие: пулы обмена не должны пересекаться по общим изменяемым данным (например, централизованным справочникам, которые часто редактируются), иначе при параллельной загрузке возникнут взаимные блокировки (Deadlocks) на уровне СУБД. Рекомендуется один поток выделить под нормативно-справочную информацию (НСИ), а остальные — строго под документы конкретных магазинов.

Решение 2: Создание выделенной центральной базы (ЦБ) только для обменов

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

1. Создаем новую чистую базу, которая станет Главным узлом (ЦБ) для всей сети.
2. В этой базе создаем планы обмена для всех 200+ узлов (включая бывшие центры).
3. Пользователи в этой базе не работают вообще.
4. Особенность выделенной ЦБ заключается в том, что она круглосуточно занимается только обменами. Отсутствие пользовательских сеансов означает полное отсутствие блокировок при записи документов оперативного учета.

Перевод на такую схему можно осуществлять плавно: переносить актуальную НСИ и текущие остатки по одному узлу, постепенно отключая их от старых центров и подключая к новой ЦБ.

Решение 3: Порционная запись и управление транзакциями

Частая проблема при чтении объемных XML-файлов обмена — нехватка оперативной памяти и длительные удержания транзакций. Обязательно посмотрим на настройки узлов обмена.

Ключевая настройка для таких объемов — параметр КоличествоЭлементовВТранзакции. Если база пытается записать весь пакет обмена (десятки тысяч объектов) за одну транзакцию, это блокирует таблицы SQL. Дробление транзакций (например, по 500–1000 элементов) позволяет регулярно фиксировать изменения в БД, снижая нагрузку на систему и позволяя параллельным процессам получать доступ к таблицам.

Решение 4: Ревизия таблиц регистрации изменений и оптимизация СУБД

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

1. Проведем аудит авторегистрации в свойствах Плана обмена. Отключим автоматическую регистрацию для объектов, которые физически не нужны во втором центре (например, логи, технические регистры сведений, промежуточные статусы).
2. Очистим таблицы регистрации от «битых» ссылок. Из-за сбоев обмен часто пытается раз за разом передать объекты, которые уже удалены.
3. Около 75% времени ожидания при длительных обменах связано с ожиданием на блокировках в SQL. Индексы на таблицах регистрации мгновенно фрагментируются. Настройте регламентные операции на уровне SQL-сервера (MS SQL или PostgreSQL) перед началом тяжелого ночного обмена: принудительное обновление статистики и реиндексацию таблиц обмена.

Решение 5: Изменение архитектуры работы с чеками ККМ

Исторически в 1С:Розница чеки ККМ обязательно передавались в центр для аналитики и оформления возвратов. Сегодня, при наличии онлайн-касс и ОФД, хранить каждый чек в центральной тяжелой базе нецелесообразно.

Рассмотрим современный подход:

Чеки и данные продаж занимают львиную долю трафика. Создайте отдельное легковесное хранилище (например, базу на базе 1С с доступом через HTTP-сервисы или внешнюю SQL-таблицу) исключительно для чеков. Периферийные узлы будут отправлять туда данные о продажах напрямую с помощью легковесных JSON или XML пакетов через REST API, минуя тяжелый механизм РИБ.

В самой РИБ на точках должны мигрировать только актуальные цены, остатки, дисконтные системы (лучше вынести на отдельный сервер лояльности) и документы движения за текущий период. Это радикально сократит объем передаваемых данных и время обмена между двумя центральными узлами упадет с 10-12 часов до 20-30 минут.