Планы обмена. Квитировать или гарантировать?

22.12.16

Интеграция - Перенос данных 1C

Планы обмена предлагают использовать две стратегии удаления обработанных изменений: квитирование и гарантированная доставка сообщений. Как сделать правильный выбор?

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

Рассмотрим работу плана обмена на небольшом примере. Зарегистрируем изменение. Таблицы плана обмена и регистрации изменений будут выглядеть следующим образом:

Таблица плана обмена Таблица регистрации изменений
Узел Номер отправленного
Мой узел NULL
Узел Ссылка Номер сообщения
Мой узел Моя ссылка 1 NULL

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

Таблица плана обмена Таблица регистрации изменений
Узел Номер отправленного
Мой узел 1
Узел Ссылка Номер сообщения
Мой узел Моя ссылка 1 1

Номер сообщения изменился. Это означает, что наше изменение было успешно отправлено в сообщении номер 1. Теперь зарегистрируем изменение другого объекта того же типа.

Таблица плана обмена Таблица регистрации изменений
Узел Номер отправленного
Мой узел 1
Узел Ссылка Номер сообщения
Мой узел Моя ссылка 1 1
Мой узел Моя ссылка 2 NULL

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

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

Квитирование.

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

Запрос = Новый Запрос();
Запрос.Текст = "
|ВЫБРАТЬ
|	Т1.Ссылка КАК Узел,
|	СУММА(Т1.НомерОтправленного - Т2.НомерСообщения) КАК Количество
|ИЗ
|	ПланОбмена.Тестовый КАК Т1
|	ЛЕВОЕ СОЕДИНЕНИЕ
|		Справочник.Номенклатура.Изменения КАК Т2
|	ПО Т1.Ссылка = Т2.Узел
|	 И Т1.НомерОтправленного <= Т2.НомерСообщения
|	 И НЕ Т2.НомерСообщения ЕСТЬ NULL
|СГРУППИРОВАТЬ ПО
|	Т1.Ссылка
|";

Гарантированная доставка сообщений.

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

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

1-ая фаза помечает новые изменения для выгрузки при помощи метода ПланыОбмена.ВыбратьИзменения(), который записывает очередной номер сообщения для новых изменений. Блок № 4 на диаграмме ниже.

НомерСообщения > НомерОтправленного (мы находимся в открытой транзакции)

2-ая фаза фиксирует успешное завершение выгрузки при помощи метода ЗаписьСообщенияОбмена.ЗакончитьЗапись(), который записывает номер отправленного сообщения для узла плана обмена. Блок № 7 на диаграмме ниже.

НомерСообщения = НомерОтправленного (транзакция завершилась успешно)

Схематично весь этот процесс я постарался сделать наглядным при помощи следующей диаграммы:

На этой диаграмме состояние одного изменения показано при помощи блоков 2, 5 и 8. Блоки 3 - 7 являются одним сеансом обмена данными. Независимо от того какую стратегию удаления обработанных изменений мы используем, диаграмма будет одной и той же. Разница заключается только в методике удаления изменений.

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

Обратите внимание, что, в случае использования стратегии гарантированной доставки сообщений, в контексте очередного сеанса обмена данными, нас интересуют только новые изменения (блок 2) и изменения, которые возникли в результате сбоев прошлых сеансов обмена (блок 5). Это является существенным отличием от стратегии квитирования.

Заключение.

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

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

2. Для того, чтобы доставка была действительно гарантированной, не изобретайте велосипедов - используйте проверенные MQ-решения, например, MSMQ, ActiveMQ или RabbitMQ.

Основные конфликты (см. диаграмму выше) возникают между блоками 1 и 4 за изменение состояния блока 2. Отсюда следующая рекомендация:

3. Постарайтесь сделать транзакции блока 4 как можно короче. Помечайте на выгрузку не все изменения сразу. Разделите их на какие-то адекватные вашей ситуации порции. В качестве одной из идей реализации этой задачи можно посмотреть мою публикацию "Многопоточная выгрузка одного сообщения обмена".

В особо тяжёлых случаях вместо "ВыбратьИзменения" вполне можно использовать две отдельные команды.

Первая - код SQL вида (псевдокод, как идея)

UPDATE TOP 1000 SET _MessageNo = _SentNo + 1 WHERE _MessageNo IS NULL,

а вторая - выборка изменений кодом 1С с отбором вида

ГДЕ НомерСообщения > НомерОтправленного ИЛИ НомерСообщения ЕСТЬ NULL.

Почему код SQL? Дело в том, что "ВыбратьИзменения" помимо обновления номера сообщения возвращает выборку, которая может быть сразу и не нужна ... Ну и потом одна хорошая команда SQL никогда не помешает =)

Вторым по значимости конфликтом (см. диаграмму выше) является конфликт между блоками 1 и 9 за изменение состояния блоков 8. Здесь рекомендация такая же, как и в пункте 3. Короткие транзакции - хорошие транзакции.

планы обмена обмен данными интеграция

См. также

SALE! 10%

Перенос данных 1C Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

50722 45650 руб.

04.08.2015    165037    383    275    

369

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

26280 руб.

12.06.2017    140089    781    295    

408

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.234.x) и БП 3.0 (3.0.161.x). Правила подходят для версии ПРОФ и КОРП.

28000 руб.

15.12.2021    23077    157    47    

116

Зарплата Внешние источники данных Бюджетный учет Перенос данных 1C Системный администратор Программист Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 8 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

84000 руб.

19.08.2020    24337    23    1    

25

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос данных из ERP в БП 3 | из КА 2 в БП 3 | из УТ 11 в БП 3 | из ЕРП в БП 3 | Сэкономьте время - используйте готовое решение для перехода! | Перенос разработан в формате КД 2 (правила конвертации данных) | Переносятся все возможные виды документов, начальных остатков и нормативно-справочная информация| Можно опционально выгружать каждую пару "номенклатура+характеристика" как отдельную номенклатуру | Есть выгрузка настроек счетов учета и зарплатных данных из ERP / КА 2 | Можно проверить на вашем сервере перед покупкой

50722 45650 руб.

15.04.2019    71477    180    148    

120

SALE! 10%

Перенос данных 1C Взаиморасчеты Оптовая торговля Логистика, склад и ТМЦ Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Управленческий учет Платные (руб)

Можно проверить до покупки, оставьте заявку! Воспользовались более 268 компаний! Перенос данных из УТ 10.3 в УТ 11 | из УТ 10.3 в КА 2 | из УТ 10.3 в ERP. Предлагаем качественное и проверенное временем решение для перехода с УТ 10.3. Можно перенести начальные остатки, нормативно-справочную информацию и все возможные документы. При выгрузке можно установить отбор по периоду, организациям и складам. При выходе новых релизов конфигураций 1C оперативно выпускаем обновление переноса данных.

50722 45650 руб.

24.04.2015    194115    148    242    

279

SALE! 10%

Перенос данных 1C Системный администратор Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Правила переноса данных из БП 3.0 в УТ 11 | из БП 3.0 в КА 2 | из БП 3.0 в ERP | Сэкономьте свое время - используйте готовое решение для перехода! | Постоянно работаем над развитием переноса данных | Обновляем на новые релизы 1С | Есть фильтр выгрузки по организациям | Переносятся начальные остатки на выбранную дату, документы за период времени и вся возможная справочная информация | Перенос сделан на технологии КД 2 (правила конвертации данных) Воспользовались более 122 предприятий! |

50722 45650 руб.

31.10.2014    235978    99    333    

304

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

48278 43450 руб.

03.12.2020    35990    90    62    

86
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. herfis 513 12.12.16 11:07 Сейчас в теме
ИМХО, гораздо интереснее была бы статья, описывающая "живой" опыт построения РИБ с гарантированной доставкой на сервисах очередей и описанием проблем, с которыми пришлось столкнуться.
А так, 90% статьи - невнятное описание стандартных механизмов и потрясающее заключение: лучше быть богатым и здоровым, оказывается.
Merkalov; MarinaLed; zakiap; user712426; Anthon; Irwin; ineshyk; +7 Ответить
2. charushkin 108 13.12.16 10:53 Сейчас в теме
Обычно вместо использования сторонних сервисов (RabbitMQ, MSMQ и т.д.) изобретаю свой велосипед решаю задачу средствами самой же 1С: делаю очередь сообщений, например, в виде регистра сведений: туда пишу сообщение обмена и сразу удаляю регистрацию изменений.
user712426; WellMaster; +2 Ответить
7. zhichkin 1518 22.12.16 13:02 Сейчас в теме
(2) Приведу пример из своей практики.
Для одного очень тяжёлого обмена, тестовый пакет XML которого "весил" 100 Мб, мы делали так :
1. Своя регистрация изменений в регистре сведений в хронологическом порядке (по сути очередь).
2. Свой компактный формат XML, имеющий только те данные, которые изменились (гранулярность регистрации изменений - поле таблицы, реквизит объекта).
3. Использование для доставки SQL Server Service Broker (транспорт).
4. Загрузка пакетов XML в 1С средствами C# с генерацией T-SQL кода (для работы с XML на уровне SQL Server писались свои CLR хранимые процедуры).
Целевым временем загрузки XML пакета "весом" 1 Гб считалось 10 минут. Это без учёта выгрузки и транспорта. Мы укладывались в это время. Даже с запасом.
В результате была полностью решена проблема блокировок при регистрации и выгрузке изменений. Загрузка в общем-то тоже не доставляла каких-то особенных проблем. Удаление регистрации изменений никому не мешало, так как удалялись уже обработанные сообщения из очереди (регистра сведений) по дате последней выгрузки. Все традиционные проблемы РИБ были полностью решены.
Проблемы, с которыми столкнулись: сложность программирования всего этого. Три человека в течение одного-полутора месяцев всё это делали: программист 1С, программист C# и программист SQL. В процессе эксплуатации проблем не было вообще. Мы даже иногда забывали, что обмен работает =) Вспоминали только когда сеть "ложилась" и какие-то данные не долетали до нужных баз - пользователи напоминали. Админы "шевелили" сеть и всё снова работало.
В обмене участвовало 4 базы: оперативная (торговля), web-портал B2B, база для отчётов и диспетчерская база для маршрутизации пакетов при помощи Service Broker. Как-то так.
dsdred; eeeio; user712426; ipoloskov; +4 Ответить
3. bulpi 217 15.12.16 15:08 Сейчас в теме
"ГДЕ НомерСообщения > НомерОтправленного И НомерСообщения ЕСТЬ NULL"

В результате такого условия выберется ровно НИЧЕГО.

Эта статья в целом написана неряшливо и непонятно.
5. zhichkin 1518 22.12.16 12:19 Сейчас в теме
(3) Спасибо. Логическую ошибку в условии отбора исправил.
4. WellMaster 104 22.12.16 11:17 Сейчас в теме
Вопрос к знатокам, берем модификацию имеющегося примера:

"Номер сообщения изменился. Это означает, что наше изменение было успешно отправлено в сообщении номер 1. Теперь зарегистрируем изменение другого объекта того же типа.
Если теперь снова попытаться выполнить выгрузку, то в выборку изменений попадут оба изменения. Это означает, что изменение, отправленное ранее в сообщении номер 1, будет отправлено ещё раз."

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

Как я полагаю, когда квитанция вернется, регистрация к обмену снимется, и объект останется в этом узле измененный, а в новый контур обмена не полетит, и в другой базе он останется в старой версии.

Поправьте меня, если я не прав.
6. zhichkin 1518 22.12.16 12:26 Сейчас в теме
(4) Если Вы измените тот же самый объект после его выгрузки в пакет, то получите новую регистрацию того же самого объекта со значением реквизита "НомерСообщения" равным NULL. Когда квитанция "прилетит" она будет искать кого бы снять с регистрации по номеру, а он будет равен NULL, то есть квитанция никого не найдёт и новые изменения попадут в следующий пакет обмена.
Подробнее здесь: http://infostart.ru/public/561460/
8. WellMaster 104 22.12.16 15:11 Сейчас в теме
(6)
Да, статью по ссылке я читал, причем еще тогда, когда она впервые вышла. Довольно познавательно.
Но нужен был именно ответ на такой вопрос, за что спасибо.
В той статье этот момент не очевиден (или я плохо читал?), хотя читал ее неоднократно.
10. M.Nikitin 2 16.12.20 20:41 Сейчас в теме
(6)
Когда квитанция "прилетит" она будет искать кого бы снять с регистрации по номеру, а он будет равен NULL, то есть квитанция никого не найдёт и новые изменения попадут в следующий пакет обмена.


А если используем снятие с регистрации не по номеру сообщения, а по ссылке - в таком случае объект будет снят с регистрации и новое состояние объекта другая база так и не увидит.
zhichkin; +1 Ответить
11. alexander-lubich 29 14.07.22 15:27 Сейчас в теме
(6) Дмитрий , интересно Ваше мнение по вопросу "Когда заканчивается Enterprise Data и начинается RabbitMQ ?"

http://forum.infostart.ru/forum15/topic284494/message2848287/#message284828

парни из 1с мне ответили
- Пропускная способность ED ими не тестирована .
- достоинство шины - сама определяет получателя и доставку сообщение ему те задача источника только выплюнуть сообщение в шину и тут резко снижается риск блокировок таблиц изменений. потому что узел обмена у центральной базы будет только один - шина.

да книжка классная , сейчас читаю.
Прикрепленные файлы:
PROGRAMMING_Shablony_integratsii_korporativnykh_prilozhenii_774.pdf
9. kuzyara 2077 12.02.18 10:25 Сейчас в теме
За одну только картинку схемы +.
Оставьте свое сообщение