Пример PubSub в МассТранзит - PullRequest
5 голосов
/ 24 января 2012

После прочтения примера проекта pub / sub в MassTransit он почесал мне голову.

В этом примере клиентское приложение публикует запрос для приложения-подписчика на обновление пароля фиктивного пользователя.,Этот пример кода работает отлично, и легко следовать за прыгающим шаром этого проекта.

ОДНАКО -

В реальной среде цель pub / sub (в моем понимании)) иметь небольшое количество издателей, взаимодействующих с большим количеством подписчиков.Если подписчик выполняет какую-либо операцию CRUD, не должен ли шаблон связи помешать обработке сообщения более чем одному подписчику?Например, было бы менее желательным, чтобы двадцать подписчиков пытались обновить одну и ту же запись базы данных.

Это просто случай ошибочного примера проекта?

Если паб / саб может бытьиспользуется для операций CRUD, как настроить фреймворк так, чтобы он позволял выполнять операции только одному подписчику?

Я просто полностью пропустил некоторую базовую информацию о цели pub / sub?

Спасибодля любого уточнения предоставлено ...

Дэвид

Ответы [ 2 ]

4 голосов
/ 24 января 2012

Сценарий, на который вы ссылаетесь, обычно называют «конкурирующими потребителями» и довольно типичен для pub / sub.

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

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

2 голосов
/ 25 января 2012

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

Пример проекта может быть не лучшим, но мы считаем, что он показывает, что происходит.Однако в реальных случаях его можно использовать для поведений типа CRUD;однако это больше похоже на то, как многие внешние интерфейсы отправляют сообщения типа «загрузка данных» в промежуточное программное обеспечение (кэш), запрашивая ответ тех же данных.Если эти данные каким-либо образом обновляются во внешнем интерфейсе, он должен опубликовать какое-то сообщение, указывающее, что и несколько компонентов промежуточного программного обеспечения необходимо обновить (кеш, хранилище бэкенда и т. Д.).[см. CQRS ]

В целом обмен сообщениями больше относится к работе с отключенными системами.Ваш конкретный мир больше касается структуры потребителей и издателей.Я видел реализации MassTransit, где большинство маршрутов были статичными, и на самом деле это был не паб / суб, а лишь множество отправок по известной топографии систем.На самом деле, понимая концепции, лучшая книга, которую я знаю, это Enterprise Service Bus: теория на практике .

Надеюсь, это поможет!

Редактировать: Также смотрите наш документация , некоторые из концепций затронуты там.

...