Многоадресная рассылка, обмен сообщениями, ActiveMQ против MSMQ? - PullRequest
22 голосов
/ 28 августа 2008

Я работаю над системой обмена сообщениями / уведомлений для наших продуктов. Основные требования:

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

Библиотеки будут написаны на C #. Spring.NET только что выпустила веху со множеством отличных абстракций обмена сообщениями, и это здорово - я планирую широко ее использовать. Мой основной вопрос сводится к вопросу о брокерах сообщений. Моя архитектура будет выглядеть примерно так: приложение -> очередь брокера сообщений -> серверное приложение, которое прослушивает, отправляет все сообщения туда, куда им нужно перейти, и обрабатывает жизненный цикл этих долгоживущих сообщений -> очередь или тема брокера сообщений -> прослушивание приложения.

Наконец, вопрос: какого брокера сообщений мне следует использовать? Я склонен к ActiveMQ - Мы использовали его в нашем последнем проекте и нам понравилось. Я не могу придумать ни единого удара по нему, за исключением того, что это Java, и для этого потребуется где-то установить java на сервере, а это может быть трудно продать некоторым людям, которые будут использовать этот сервис. Другой вариант, на который я смотрел, - это MSMQ. Я настроен против этого по какой-то неизвестной причине, и, похоже, он также не имеет большой поддержки многоадресной рассылки.

Кто-нибудь использовал MSMQ для чего-то подобного? Есть плюсы или минусы, вещи, которые могут повлиять на голосование так или иначе?

И, наконец, мы используем .NET 2.0.

Ответы [ 5 ]

22 голосов
/ 16 сентября 2008

Я немного пристрастен, работая над ActiveMQ , но почти все преимущества, перечисленные для MSMQ выше, действительно применимы и к ActiveMQ.

Некоторые другие преимущества ActiveMQ включают

Основным недостатком, который вы упомянули, является то, что брокер ActiveMQ написан на Java; но вы можете запустить его на IKVM как сборку .net, если вы действительно хотите - или запустить его как службу Windows, или скомпилировать его в DLL / EXE через GCJ. MSMQ может быть написан или не написан на .NET - но на самом деле не имеет большого значения, насколько правильно он реализован?

Независимо от того, выбираете ли вы MSMQ или ActiveMQ, я бы рекомендовал хотя бы рассмотреть возможность использования NMS API , который, как вы говорите, прекрасно интегрирован в Spring.NET. Существует реализация этого API в MSMQ, а также реализации для TibCo, ActiveMQ и STOMP, которые будут поддерживать любого другого провайдера JMS через StompConnect .

Таким образом, выбрав NMS в качестве своего API, вы избежите привязки к какой-либо запатентованной технологии - и тогда вы сможете легко переключаться между поставщиками сообщений в любой момент времени; вместо того, чтобы блокировать ваш код в проприетарном API

13 голосов
/ 28 августа 2008

Плюсы для MSMQ.

  • Он встроен в Windows
  • Он поддерживает транзакции, он также поддерживает очереди без транзакций
  • Это действительно легко настроить
  • Интеграция AD
  • Это быстро, но вам нужно сравнить ActiveMQ и MSMQ, чтобы узнать, какой из них быстрее.
  • .NET поддерживает это рождество
  • Поддерживает огонь и забывает
  • Вы можете заглянуть в очередь, если у вас есть читатели, которые просто смотрят. не уверен, что вы можете редактировать сообщение в очереди.

Минусы:

  • ограничение размера сообщения 4 МБ
  • 2 ГБ Размер очереди
  • Элементы очереди хранятся на диске
  • Не является основным продуктом MS, документы немного ненадежны, или прошло уже несколько лет с тех пор, как я его использовал.

Вот хороший блог для MSMQ

7 голосов
/ 23 октября 2008

Взгляните на zeromq . Это одна из самых быстрых очередей сообщений.

3 голосов
/ 23 октября 2008

На этой арене так много возможностей ...

Бесплатно: MantaRay одноранговая полностью JMS-совместимая система. Интересная часть Mantaray заключается в том, что вам нужно только определить, куда отправляется сообщение, и MantaRay в любом случае направляет его, чтобы ваше сообщение было определено, поэтому оно более устойчиво к сбоям отдельных узлов в вашей структуре обмена сообщениями.

Платно: на своей повседневной работе я администрирую систему обмена сообщениями IBM WebSphere MQ с несколькими сотнями узлов и считаю ее очень хорошей. Мы также недавно приобрели Tibco EMS, и, похоже, его будет очень приятно использовать.

Paul /

3 голосов
/ 04 октября 2008

Предлагаю вам взглянуть на TIBCO Enterprise Messaging Service - EMS, который является высокопроизводительным продуктом обмена сообщениями, который поддерживает многоадресную рассылку, маршрутизацию, поддерживает спецификации JMS и предоставляет широкие возможности предприятия, в том числе ваши требования, такие как игнорирование при пожаре и сохранение сообщений с помощью файла / база данных, использующая общее состояние.

В качестве справки, FEDEX работает на TIBCO EMS в качестве инфраструктуры обмена сообщениями.

http://www.tibco.com/software/messaging/enterprise_messaging_service/default.jsp

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

...