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

Question

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: В итоге мы остановились на сервисном брокере, потому что у нас есть пользовательская структура БД, используемая в некоторых наших клиентских кодах (мы лучше обрабатываем транзакции). Этот код захватил SQL для транзакций, но не. Код клиента был также полностью версии 1.1 .NET, поэтому нам пришлось бы обновить весь код клиента. Спасибо за вашу помощь!

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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