Перейти к содержанию

Параллелизм

DataHUB сознательно использует параллельную обработку и доставку сообщений на всех этапах: формирование на источнике, отправка в шину, доставка приёмнику, прикладная обработка на приёмнике. Это даёт пропускную способность, но создаёт коллизию порядка, которую приходится решать на стороне приёмника отложенной обработкой.

Где работает параллелизм

  • На источнике: формирование нескольких сообщений одновременно в разных потоках.
  • На источнике: несколько потоков отправки в API шины.
  • В шине: разные сообщения для разных приёмников движутся независимо.
  • На приёмнике: несколько потоков приёма из шины.
  • На приёмнике: несколько потоков прикладной обработки из локального пула.

Это норма, не оптимизация. Однопоточный последовательный режим не масштабируется и не используется.

Почему нельзя обрабатывать в один поток

Гипотетический «всё в один поток, строго по порядку» теоретически решил бы проблему упорядоченности (порядок никогда бы не сбился). Но:

  • Один поток упирается в скорость самого медленного сообщения. Длинная цепочка задерживает всё остальное.
  • Не масштабируется ни на стороне источника, ни на стороне приёмника.
  • Не использует доступные ядра и сетевые каналы.

Параллелизм — основная противоречащая причина, по которой однопоточная последовательная обработка неприемлема.

Ссылки между объектами и почему это важно

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

Ссылки не должны образовывать циклы. Если допустить циклы — передача и поиск ссылок превратятся в бесконечный цикл, каждый объект бесконечно будет ставиться на отложенную обработку. Поэтому в модели обмена DataHUB ссылочные циклы запрещены.

При отсутствии циклов все объекты выстраиваются в дерево (а не в граф). Теоретически дерево можно передать в правильном порядке (сначала корни, потом ветви), так что приёмник в момент применения каждого сообщения уже имеет все ссылки разрешимыми. В таком идеальном порядке отложенная обработка не нужна — каждое сообщение сразу применяется.

Где коллизия

Идеальный порядок ломается параллелизмом. Из-за параллельной отправки, параллельной маршрутизации и параллельного приёма последовательно сформированные на источнике объекты могут быть переданы и приняты в обратном порядке — сообщение-«дочь» доходит до приёмника раньше сообщения-«родителя», на которого «дочь» ссылается.

В момент применения «дочери» нужная ссылка ещё не присутствует в БД приёмника. Прямое применение не сработает.

Решение — отложенная обработка с паузой

Чтобы не блокировать обмен и не возвращать сообщение в шину (что раздувало бы её очереди), приёмник применяет паттерн «пауза-обработка»:

  1. Попытались обработать сообщение → не нашли требуемую ссылку.
  2. Поставили сообщение на паузу в локальном пуле с пометкой «отложено» и временем следующей попытки.
  3. К моменту следующей попытки нужное справочное сообщение, скорее всего, уже принято и обработано — обработка проходит успешно.

Если за заданное число попыток разрешение ссылки так и не удалось — сообщение переводится в статус ошибки обработки и требует ручного разбора администратором.

Конкретные параметры (интервалы между попытками, максимальное число попыток) — это настройки клиентского модуля, не платформы.

Приоритизация обработки

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

Связь с другими концепциями

Параллелизм + отложенная обработка — концептуальная основа двух соседних концепций:

Без параллелизма не нужны были бы локальный пул и отложенная обработка. Но и пропускной способности тоже не было бы. Двухфазная модель приёмника — прямое следствие выбора параллелизма.

Что дальше