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

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

Некоторые сведения:

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

Вещи, которые я обнаружил до сих пор:

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

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

EDIT: мы закончили тем, что придерживались сервис-брокера, потому что у нас есть пользовательская структура базы данных, используемая в некоторых наших клиентских кодах (мы лучше обрабатываем транзакции). Этот код захватил SQL для транзакций, но нет. Клиентский код также был все версии 1.1.NET, поэтому нам пришлось бы обновить весь клиентский код. Спасибо за вашу помощь!

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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