Должен ли я использовать MSMQ или SQL Service Broker для транзакций?
Руководитель моей команды попросил меня изучить MSMQ в качестве опции для новой версии нашего продукта. Мы используем SQL Service Broker в нашей текущей версии. Я провел свою изрядную долю экспериментов и поисков в Google, чтобы найти, какой продукт лучше подходит для моих нужд, но я думал, что спрошу лучший сайт, который я знаю, для программирования ответов.
Некоторые детали:
- нашим клиентом является .NET 1.1 и 2.0 код; именно отсюда будет отправлено сообщение.
- цель в SQL Server 2005 пример. Все сообщения заканчиваются обновлением или вставкой базы данных.
- мы отправим несколько обновлений, которые должны рассматриваться как транзакция. Мы должны иметь идеальную возможность восстановления сообщений; никакие сообщения не могут быть потеряны.
- мы должны быть асинхронными и принимать сообщения, даже если целевой SQL-сервер не работает.
- разработка собственного решения для массового обслуживания-это не вариант; мы-небольшая команда.
Вещи, которые я обнаружил до сих пор:
- как MSMQ, так и SQL Service Broker может выполнить эту работу.
- похоже, что Service broker работает быстрее для транзакционных сообщений.
- Service Broker требует, чтобы где-то работал SQL-сервер, в то время как MSMQ нуждается в любой настроенной машине Windows, работающей где-то.
- MSMQ, по-видимому, лучше/быстрее/проще настроить/запустить в кластерах.
Я что-то упустил? Есть ли здесь явный победитель? Любые мысли, переживания или связи будут оценены. Спасибо!
Правка: мы застряли с service broker, потому что у нас есть пользовательский фреймворк БД, используемый в некоторых наших клиентских кодах (мы лучше обрабатываем транзакции). Этот код захватил SQL для транзакций, но не сделал этого . Клиентский код был также все версии 1.1 .NET, так что нам пришлось бы обновить весь клиентский код. Спасибо за вашу помощь!
4 ответа:
Имея только что перенесли мою заявку от брокера службу очереди сообщений, мне придется голосовать за использованием msmq. Существует несколько факторов, которые необходимо учитывать, но большинство из них связано с тем, как вы используете свои данные и где живет обработка.
- Если обработка производится в базе данных? Service Broker
- Если это просто перемещение данных? Service Broker
- выполняется ли обработка в коде .NET / COM? MSMQ
- нужен ли вам удаленный распределенный транзакции (например, обработка на коробке, отличной от SQL)? MSMQ
- Нужно ли вам иметь возможность отправлять сообщения, когда адресат не работает? MSMQ
- вы хотите использовать nServiceBus, MassTransit, Rhino-ESB и т. д.? MSMQ
Вещи, которые нужно учитывать независимо от того, что вы выберете
- Как вы узнаете о состоянии своей очереди? Оба варианта обрабатывают отработку отказа по-разному. Например Service Broker отключит вашу очередь в определенные сценарии, которые могут снять ваше приложение.
- Как вы будете выполнять отчетность? Если вы уже используете SQL-таблицы в своих отчетах, Service Broker может легко вписаться, поскольку это просто еще одна динамическая таблица. Если вы уже используете Performance Monitor MSMQ может подойти лучше. Service Broker имеет много счетчиков производительности, поэтому не позволяйте этому быть вашим единственным фактором.
- Как вы измеряете время безотказной работы? Это просто проверка того, что вы не теряете транзакции, или вам нужно отвечать синхронно? Я нахожу, что распределенная природа MSMQ позволяет увеличить время безотказной работы, потому что основная очередь может перейти в автономный режим и ничего не потерять. В то время как с Service Broker ваша база данных должна быть онлайн, иначе вы проиграете.
У вас уже есть опыт работы с одной из этих технологий? У обоих есть много деталей реализации, которые могут вернуться и укусить вас.- независимо от того, какой выбор вы делаете, насколько легко переключить лежащая в основе технологии массового обслуживания? Я рекомендую иметь универсальный интерфейс IQueue, против которого вы пишете конкретную реализацию. Таким образом, выбор, который вы делаете, может быть легко изменен позже, если вы обнаружите, что сделали неправильный выбор. В конце концов, очередь-это просто очередь, и она не должна привязывать вас к конкретной реализации.
Я уже использовал MSMQ раньше, и единственный пункт, который я бы добавил в ваш список, - это проверка предварительных условий для управления версиями. Я столкнулся с проблемой, когда один сайт имел Win 2000 Server и, следовательно, MSMQ V. 2, против Win 2003 Server и MSMQ v3. Весь мой .NET-код нацелен на V. 3, и они несовместимы... или, по крайней мере, не так легко.
Просто соображение, если вы идете по маршруту MSMQ.