Локальные против удаленных очередей в пабе/подзадачи сообщения

Question

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

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

Различные технологии, по -видимому, обеспечивают различные конфигурации - например, MSMQ требует, чтобы каждая машина имела свою собственную локальную очередь, в то время как TIBCO EMS, по -видимому, часто используется в кластерах, без локальных очередей на каждом потребителе.

Каковы недостатки, не имея локальной очереди, и какие факторы влияют на решение?

Answer 1

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

MSMQ также является хранящимся и напротив, но он не предоставляет никаких кластерных возможностей маршрутизации. Это означает, что приложение должно выполнять работу (или иметь слой, например, MassTransit или NServicebus, сделайте это для вас).

Когда я думаю о TIBCO, я думаю о централизованном кластере серверов EMS, с которыми общаются серверы приложений вместо того, чтобы запускать экземпляр брокера на местном уровне. Инструменты GUI, которые оборачиваются вокруг EMS и серверов приложений BusinessWorks, действительно заставляют модель в этом мире.

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

Answer 2

Я бы рискнул, что местная очередь будет необходима в большинстве сценариев.

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

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

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

Answer 3

Я не уверен, что согласен с комментариями к MSMQ, поскольку они кажутся устаревшими. Может, я что -то упускаю.

Оба сценария поддерживаются в MSMQ.

В сценарии 1 клиенты будут использовать транзакционные удаленные получения (MSMQ 4.0 и выше). Будучи транзакционным, получение является надежным, а сообщение долговечено (в отличие от более ранних версий MSMQ, когда прерванные получения оставляют сообщение на сервере).

В сценарии 2 исходящая очередь хранителя и передвижению будет отправляться в локальную транзакционную очередь на клиента (снова надежная и долговечная).

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