Согласованность данных в распределенной системе
От: BillyBoy Россия  
Дата: 05.05.20 16:28
Оценка:
Добрый день!
Имеется мастер система, создающая DTOшки (упрощенные представления сущностей в мастер системе) и передающая их в интеграционную шину, которая в свою очередь передает данные в 1С и другие подсистемы.
В 1С для этих DTOшек создана staging area (по сути копия справочников интеграционной шины), из которой уже берутся необходимые данные и копируются в базу 1С.
Как видите, цепочка довольно длинная. Периодически возникают ошибки в каждом из звеньев этой цепочки.
Разработчики правят ошибки, но потом появляются новые.
Пока удалось выкрутиться с помощью костылей:
1) на стороне 1С раз в сутки запускается процесс, который ищет в staging area ссылки на несуществующие записи в связанных справочниках; после этого делаются запросы к интеграционной с uid'ами недостающих записей;
2) т.к. есть "корневые" справочники в иерархии справочников без указания на них ссылок, то для них придумана "витрина данных" на стороне мастер системы, отдающая uid записи и ее дату обновления; соответственно, на стороне 1С процесс, запускающийся раз в сутки, лезет в "витрину данных" и ищет расхождения, восстанавливая целостность данных.
Мне подобная схема не нравится (но реакция со стороны бухгалтерии и руководства мне не нравится еще больше ), хотелось бы каких-то внутренних механизмов проверки целостности без костылей. Разработчики ничего предложить не могут.
Поэтому обращаюсь к сообществу: как в указанной архитектуре снизить процент потери данных от мастер системы в подсистему и уменьшить время рассогласованности данных?
Примечание: для увеличения скорости обмена, он производится в асинхронном режиме, поэтому допускается небольшой интервал времени, в течение которого данные могут быть рассогласованы.
Никогда не спорь с дураком, а то люди могут не заметить между вами разницы.
интеграционная шина Servicebus
Re: Согласованность данных в распределенной системе
От: wildwind Россия  
Дата: 05.05.20 17:37
Оценка:
Здравствуйте, BillyBoy, Вы писали:

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


Одно из грубых решений — при передаче какого-либо объекта в шину, передавать также и все объекты, на которые он ссылается, что-то вроде deep copy. Передавать, разумеется, в обратном порядке. Получаем согласованность ценой избыточности данных.

Если же подходить более серьезно, то нужно исправлять те самые "ошибки", из-за которых зависимый объект попадает в выгрузку раньше, чем тот, на который он ссылается. И не допускать новых.
Например, добавить к нужным сущностям флаг "выгружен в 1С" и ориентироваться на него.
Re[2]: Согласованность данных в распределенной системе
От: RushDevion Россия  
Дата: 05.05.20 20:57
Оценка:
Как радикальный вариант — избавиться от всех промежуточных звеньев (шина и т.п.)
Сделать read (slave) реплику основной базы, а 1С дать "интерфейс" в виде хранимок/вьюшек над этой репликой и пусть сама вычитывает с нужной периодичностью.

Другой вариант — перейти на push модель, вместо publish/subscribe.
Т.е. пусть не 1С слушает изменения в основной системе, а основная система пушит в 1С при возникновении изменений (исправлении ошибок и т.п.)

И еще мысль.
Если считать, что данные в основной базе всегда согласованы,
то не очень понятно, в какой момент возникает возможность для рассогласовывания в 1С:
в момент зачитки данных для выгрузки в шину, при трансформации в DTO, при обработке/записи на стороне 1С?
В чем источник проблемы: временной лаг на propagation изменений по шине, необходимость параллельной обработки потока изменений на 1С или у нас просто неудачная DTO-модель?
Отредактировано 05.05.2020 21:22 RushDevion . Предыдущая версия . Еще …
Отредактировано 05.05.2020 21:08 RushDevion . Предыдущая версия .
Re[2]: Согласованность данных в распределенной системе
От: BillyBoy Россия  
Дата: 06.05.20 09:33
Оценка:
Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, BillyBoy, Вы писали:


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


W>Одно из грубых решений — при передаче какого-либо объекта в шину, передавать также и все объекты, на которые он ссылается, что-то вроде deep copy. Передавать, разумеется, в обратном порядке. Получаем согласованность ценой избыточности данных.


Так уже пробовали, получается очень медленно, особенно это сказывается при высоких нагрузках.
Никогда не спорь с дураком, а то люди могут не заметить между вами разницы.
Re[3]: Согласованность данных в распределенной системе
От: BillyBoy Россия  
Дата: 06.05.20 10:02
Оценка:
Здравствуйте, RushDevion, Вы писали:

RD>Как радикальный вариант — избавиться от всех промежуточных звеньев (шина и т.п.)

RD>Сделать read (slave) реплику основной базы, а 1С дать "интерфейс" в виде хранимок/вьюшек над этой репликой и пусть сама вычитывает с нужной периодичностью.

Это действительно радикально. Но помимо 1С есть и другие подсистемы. Плюс 1С сама пушит данные в мастер систему.

RD>Другой вариант — перейти на push модель, вместо publish/subscribe.

RD>Т.е. пусть не 1С слушает изменения в основной системе, а основная система пушит в 1С при возникновении изменений (исправлении ошибок и т.п.)
Сейчас именно пушит мастер система.

RD>И еще мысль.

RD>Если считать, что данные в основной базе всегда согласованы,
Да, в основной всегда согласованы
RD>то не очень понятно, в какой момент возникает возможность для рассогласовывания в 1С:
RD>в момент зачитки данных для выгрузки в шину, при трансформации в DTO, при обработке/записи на стороне 1С?
RD>В чем источник проблемы: временной лаг на propagation изменений по шине, необходимость параллельной обработки потока изменений на 1С или у нас просто неудачная DTO-модель?
ошибки были при формировании дтошек, при отправке шиной, при приеме 1С...
ИМХО сама интеграционная шина должна следить за согласованностью. Вопрос — как?
Шина отправила данные, получила подтверждение и забыла?
Шина периодически опрашивает подсистемы и например на основании чексуммы находит расхождения?
Никогда не спорь с дураком, а то люди могут не заметить между вами разницы.
Re[4]: Согласованность данных в распределенной системе
От: wildwind Россия  
Дата: 06.05.20 14:35
Оценка: +2
Здравствуйте, BillyBoy, Вы писали:

BB>ИМХО сама интеграционная шина должна следить за согласованностью. Вопрос — как?

Это невозможно. Шина не в состоянии определить, какие данных считаются согласованными.

BB>Шина отправила данные, получила подтверждение и забыла?

Да.

Проверять согласованность нужно в приемнике, в данном случае в 1С.
Только я бы сделал не "раз в сутки", а при записи каждого объекта. Если есть битые ссылки, не принимать, отправлять ошибку. Или, как вариант, ставить в очередь запрос на загрузку недостающих объектов. Но это будет маскировка ошибок. Лучше сигнализировать ошибки и напрягать ответственных, чтобы исправляли.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.