Шина сообщений: отправитель должен ждать подтверждения от нескольких получателей

Question

В нашем приложении издатель создает сообщение и отправляет его в тему.

Тогда ему нужно подождать, когда все подписчики темы ответят на сообщение.

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

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

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

Мы используем RabbitMQ, если это имеет значение. Благодаря!

Answer 1

Функциональность, которую вы ищете, звучит как решение для обмена сообщениями, которое может выполнять транзакции между издателями и подписчиками сообщения. В Java-мире JMS определяет такие транзакции. Одним из примеров реализации JMS является HornetQ.

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

С RabbitMQ, одним из способов гарантировать, что сообщение было успешно использовано, действительно должно публиковать ответное сообщение на стороне потребителя, которое затем потребляется оригинальным издателем. Это может быть достигнуто с помощью RabbitMQ's RPC procedure calls, что может помочь вам получить чистое решение для настройки вашей проблемы.

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

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

Преимущества этого решения:

1. происхождения издатель может закончить свою задачу независимо от потребительского успеха
2. происхождения издатель не зависит от наличия потребителей и скоростей
3. реализации издателя происхождения гораздо меньше комплекс
4. в сценарии сбоя, потребитель ответа может возобновить с обработкой ответов

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

Если вы добавляете вызовы в стиле RPC для своих клиентов, ваши компоненты, скорее всего, будут тесно связаны друг с другом, что означает, что компонент публикации не работает, если один из компонентов-потребителей терпит неудачу/недоступен/слишком медленный. Это именно то, чего вы хотите избежать. В противном случае, почему вы разделили компоненты?

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