Azure Service Bus vs RabbitMQ для корпоративных приложений

Мне нужно решить между Azure Service Bus и RabbitMQ (Deployed on Azure) для приложения уровня предприятия, и мое основное использование будет состоять из тем (с долговременным хранением). Я вижу, что служебная шина имеет больше возможностей по сравнению с RabbitMQ, такими как счетчик повторов, TTL, сеансы и транзакции и т.д. Но я не уверен, какой из них лучше всего подходит для высокой доступности, масштабируемости, хранения и пропускной способности. Шина обслуживания имеет некоторые ограничения на размер магазина (макс. 5 ГБ для несезонной очереди и 80 ГБ для секционированной очереди) и пропускная способность 2000 мс/с/очередь. Что делать, если мне нужно больше этих ограничений в случае служебной шины?

Пределы RabbitMQ не ясны, так как это зависит от кластера. Если кто-то может помочь мне в решении, какой из них будет лучшим в моем случае?

ОТВЕТЫ

Ответ 1

Однако ваш вопрос был задан давно, я вижу, что люди все еще посещают. Я нашел два полезных источника:

(1) Вот исчерпывающая (хотя и старая) статья, сравнивающая Service Bus с RabbitMQ:

http://geekswithblogs.net/michaelstephenson/archive/2012/08/12/150399.aspx

Резюме из вышеупомянутого():

enter image description here

(2) Просмотр этого ответа также может немного помочь:

https://dba.stackexchange.com/info/196770/sql-server-service-broker-vs-rabbitmq

Я думаю, что он высказал мнение, основываясь на своем собственном опыте здесь, когда он говорит:

  • Происходит ли обработка данных после постановки в очередь в база данных или внешний процесс? (а) внешний процесс → RMQ. (б) другая база данных → SSB. Тем не менее, из-за его особенностей, я мог бы     вместо этого посмотрите на создание сборки pub-sub SQLCLR. Эта сборка     будет считывать данные из таблицы (ов) в асинхронном режиме и отправлять их другим     база данных для обработки (мы сделали это и там, где я работаю).

  • Нужны ли вам дуплексные возможности SSB? Не забывайте SSB не совсем предназначен для того, чтобы быть брокером сообщений, но построен для дуплекса разговоры, которые потенциально долговечны. Если вам нужны дуплексные возможности, тогда SSB - это (почти) данность.

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