Как указывает Хью, вам нужна только одна очередь MSMQ для отправки сообщений в одном направлении от источника к месту назначения. Источник и пункт назначения могут находиться на одном сервере, в одной сети или через Интернет, однако на источнике и пункте назначения должна быть запущена служба MSMQ.
Если вам нужно выполнить маршрутизацию «сообщения» (например, коммутатор, который обрабатывает сообщения из нескольких очередей источника или назначения, или маршрутизацию сообщения одному или нескольким абонентам в зависимости от типа сообщения и т. Д.), Вам потребуется больше, чем просто MSMQ очередь.
Хотя вы, безусловно, можете использовать BizTalk для маршрутизации сообщений, это будет дорого / излишне, если вам не понадобятся другие функции BizTalk. Рекомендую вам взглянуть на открытый исходный код или создать что-то собственное.
Но под «Маршрутизацией» вы можете ссылаться на возможность перенаправления очереди при использовании HTTP в качестве транспорта, например, через Интернет (например, здесь и здесь ).
Re: Сбой доставки и повтор
Я думаю, что у вас есть большинство концепций - обычно в MSMQ должна быть неявная функциональность повторной отправки сообщения. Если MSMQ не может доставить сообщение до истечения установленного срока, то оно будет возвращено в очередь недоставленных сообщений, а затем источник может обработать сообщения из DLQ и затем «компенсировать» их (например, отменить действия «send», указать сбой пользователю и т. д.).
Однако тип «обработка» Повторные попытки в месте назначения должны выполняться приложением / слушателем назначения (например, если система назначения не работает, взаимоблокировки и т. Д.)
Обычные способы сделать это включают:
- Использование двухфазной фиксации - в распределенной единице работы извлеките сообщение из MSMQ и обработайте его (например, вставьте данные в базу данных, измените состояние некоторых записей и т. Д.), И, если возникнет какая-либо ошибка, оставьте сообщение возвращается в очередь, и изменения в БД будут отменены.
- Прикладной уровень повторяется - то есть в системе назначения, в случае ошибок типа «повторная попытка» (тайм-аут из-за нагрузки, взаимоблокировки и т. Д.), Затем на несколько секунд переходит в спящий режим, а затем повторяет ту же транзакцию.
Однако в большинстве случаев повторные попытки обработки на неопределенный срок нежелательны, и вам, в конечном счете, потребуется признать поражение и реализовать механизм для регистрации сообщения и ошибки и удаления его из очереди.
Но я бы не стал «повторять» сбои в работе (например, бизнес-правила, проверка и т. Д.), И в ваших требованиях о том, как их обрабатывать, должно быть определено поведение (например, учетная запись перезаписана, сообщение имеет неправильный формат или нет). действительный и т. д.), например возвращая сообщение типа «NACK» обратно источнику.
НТН