Как спроектировать систему pub-sub, в которой может быть несколько издателей для одной и той же сущности? - PullRequest
Новая
       37

Как спроектировать систему pub-sub, в которой может быть несколько издателей для одной и той же сущности?

1 голос
/ 25 апреля 2019

Рассмотрим следующую ситуацию:

  1. Существует таблица User с полями, такими как имя, адрес электронной почты, contact_no и т. Д.
  2. У нас есть несколько продуктов / систем (с их собственной базой данных)которые используют информацию о пользователях для различных целей.
  3. Эти системы остаются синхронизированными по шаблону pub-sub, например: Имя изменения системы 1 используется системой 2 и вносит изменения в систему 2.
  4. Для простотыдавайте предположим, что есть 3 системы:
    • S1, имеющие пользовательский интерфейс для пользователя.Здесь пользователь может сам изменить свою информацию.
    • Система S2, предоставленная продавцу.Здесь пользователь может позвонить продавцу и обновить его информацию.
    • S3 другой продукт, который использует информацию из S1 и S2 для различных вычислений.

Таким образом, информация может бытьопубликовано с S1 и S2.

Предположим, что пользователь изначально имеет имя N1.

  • В момент времени t1 пользователь обновляет имя с N1 до N2.

  • В момент времени t1 продавец меняет имя с N1 на N3.

  • Теперь S1 получает событие из S3 и обновляет имя до N3.S2 получает событие от S1 и обновляет имя до N2.

  • В S3 имя может быть любым N2 ИЛИ N3 в зависимости от того, какое событие используется первым.

Это вызвало большую непротиворечивость данных между различными системами.

В идеальной системе есть только один издатель, но из-за требования нам пришлось добавить события публикации с панели «Продажи».Что можно сделать, чтобы минимизировать несоответствие данных?

Ответы [ 3 ]

2 голосов
/ 25 апреля 2019

Кажется, проблема в том, чтобы решить, кто является хозяином пользовательских данных, потому что сейчас S3 пытается обслуживать двух мастеров. 

S1 --> S3
S2 --> S3

Давайте сделаем S1 мастером пользовательских данных, чтобы любая другая система, которая принимает эти данные (например, S2), отвечала только за обновление мастера. Таким образом, S3 получает пользовательские данные из одного источника (мастер пользовательских данных). 

       S1 --> S3
S2 --> S1 --> S3

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

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

1 голос
/ 25 апреля 2019

Позвольте мне перефразировать это еще раз ..

  1. у вас есть несколько систем, к которым прикреплена независимая БД.
  2. Пользователь может изменять данные из любой системы
  3. Пользователь должен увидеть данные, измененные из любой системы.

В этом сценарии я бы использовал Master DB / System, которая будет единой точкой источника данных для каждой системы.

Если какая-либо система хочет изменить данные, данные 1-го необходимо обновить в Master Db / system, а затем распространить в другую систему, чтобы отразить изменения.

для Pub-Sub я буду следовать методам Fan-IN и Fan-out.

  1. Каждая система будет выступать в качестве издателя, а также потребителя для различных тем / каналов.
  2. Издатели (которые находятся на S1-SN) помещают изменения в одну тему / канал для аналогичного изменения данных
  3. Система Master DB будет прослушивать темы / канал, чтобы получить запрос на изменение от другой системы. Он также будет выступать в качестве издателя для другой системы, где после обработки будет отправлять одно и то же сообщение в другую тему / канал.
  4. Потребители (которые находятся на S1-SN) будут прослушивать темы / каналы для аналогичного изменения данных, которое вносит основная система БД. Эти данные будут использованы для обновления их собственной системной базы данных для изменений данных.

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

Надеюсь, я отвечу на ваш запрос.

0 голосов
/ 26 апреля 2019

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

Все системы должны связаться с этим основным источником перед обновлением записи (для таких полей, как имя, адрес электронной почты и контактный номер)

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

  • Если нет записи, вы можете легко обновить данные с новыми данных и вставьте одну запись в эти первичные исходные таблицы.

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

...