Должен ли я использовать MSMQ или SQL Service Broker для транзакций?

Question

Руководитель моей команды попросил меня изучить MSMQ в качестве опции для новой версии нашего продукта.Мы используем SQL Service Broker в нашей текущей версии.Я изрядно поэкспериментировал и погуглил, чтобы найти, какой продукт лучше подходит для моих нужд, но я подумал, что за ответами по программированию стоит обратиться к лучшему известному мне сайту.

Некоторые детали:

• Нашим клиентом является .NET 1.1 и 2.0 code;именно отсюда будет отправлено сообщение.
• Целевой объект в экземпляре SQL Server 2005.Все сообщения в конечном итоге являются обновлениями базы данных или вставками.
• Мы отправим несколько обновлений, которые должны рассматриваться как транзакция.
• У нас должна быть идеальная возможность восстановления сообщений;никакие сообщения не могут быть потеряны.
• Мы должны быть асинхронными и способны принимать сообщения, даже когда целевой SQL-сервер не работает.
• Разработка нашего собственного решения для организации очередей - это не вариант;мы - маленькая команда.

То, что я обнаружил до сих пор:

• Эту работу могут выполнить как MSMQ, так и SQL Service Broker.
• Похоже, что service broker работает быстрее с транзакционными сообщениями.
• Service Broker требует, чтобы где-то был запущен SQL server, тогда как MSMQ нужен любой настроенный компьютер Windows, работающий где-то.
• MSMQ, по-видимому, лучше / быстрее / проще настраивать / запускать в кластерах.

Я что-то упускаю?Есть ли здесь явный победитель?Любые мысли, опыт или ссылки были бы оценены.Спасибо!

Редактировать:В итоге мы остановились на service broker, потому что у нас есть пользовательский фреймворк DB, используемый в некоторых наших клиентских коде (мы лучше обрабатываем транзакции).Этот код захватил SQL для транзакций, но нет .Весь клиентский код также был версии 1.1 .NET, поэтому нам пришлось бы обновить весь клиентский код.Спасибо за вашу помощь!

Answer 1

Только что перенесший мое приложение из Service Broker в MSMQ, я должен был бы проголосовать за использование MSMQ.Есть несколько факторов, которые следует принимать во внимание, но большинство из них имеют отношение к тому, как вы используете свои данные и где происходит обработка.

• Выполняется ли обработка в базе данных? Сервисный Брокер
• Если это просто перемещение данных? Сервисный Брокер
• Выполняется ли обработка в коде .NET / COM? MSMQ
• Нужны ли вам удаленные распределенные транзакции (например, обработка в окне, отличном от SQL)? MSMQ
• Вам нужно иметь возможность отправлять сообщения, пока адресат недоступен? MSMQ
• Вы хотите использовать NServiceBus, MassTransit, Rhino-ESB и т.д.? MSMQ

Что следует учитывать, независимо от того, что вы выберете

• Как вы узнаете о состоянии вашей очереди?Оба варианта обрабатывают переход на другой ресурс по-разному.Например Сервисный Брокер отключит вашу очередь в определенных сценариях, которые могут привести к отключению вашего приложения.
• Как вы будете составлять отчеты?Если вы уже используете SQL-таблицы в своих отчетах, Сервисный Брокер может легко вписаться, поскольку это просто еще одна динамическая таблица.Если вы уже используете Performance Monitor MSMQ может, впишется лучше. Сервисный Брокер у него много счетчиков производительности, так что не позволяйте этому быть вашим единственным фактором.
• Как вы оцениваете время безотказной работы?Это просто гарантия того, что вы не потеряете транзакции, или вам нужно отвечать синхронно?Я нахожу, что распределенный характер MSMQ обеспечивает более высокое время безотказной работы, поскольку основная очередь может перейти в автономный режим и ничего не потерять.Принимая во внимание , что с Сервисный Брокер ваша база данных должна быть подключена к Сети, иначе вы проиграете.
• У вас уже есть опыт работы с одной из этих технологий?В обоих есть много деталей реализации, которые могут вернуться и укусить вас.
• Независимо от того, какой выбор вы сделаете, насколько легко отключить базовую технологию организации массового обслуживания?Я рекомендую иметь универсальный интерфейс IQueue, для которого вы пишете конкретную реализацию.Таким образом, сделанный вами выбор может быть легко изменен позже, если вы обнаружите, что сделали неправильный.В конце концов, очередь - это просто очередь и не должна привязывать вас к конкретной реализации.

Answer 2

Я уже использовал MSMQ раньше, и единственный элемент, который я бы добавил в ваш список, - это обязательная проверка для управления версиями.Я столкнулся с проблемой, когда на одном сайте был установлен сервер Win 2000 и, следовательно, MSMQ v.2 по сравнению с сервером Win 2003 и MSMQ v3.Весь мой .NET-код нацелен на версию 3, и они несовместимы...или, по крайней мере, не так легко.

Просто учтите, если вы пойдете по маршруту MSMQ.

Answer 3

Ограничение размера сообщения в MSMQ остановило мои поиски в этом направлении.Я изучаю Сервисногоброкера для проекта.

Answer 4

Вам нужно иметь возможность отправлять сообщения, пока адресат недоступен?MSMQ

Я не понимаю, почему?SSB может отправлять сообщения отключенному адресату без каких-либо проблем.Все эти сообщения отправляются в очередь передачи и будут доставлены, когда пункт назначения останется доступным.