Кто-нибудь использует Service Broker в SQL Server?

Когда я посетил презентацию SQL Server 2008 в Microsoft, они быстро поглядели, какие функции мы использовали. Оказалось, что во всем лекционном зале моя компания была единственным, кто использовал Service Broker. Это меня очень удивило, поскольку я думал, что больше людей будут использовать его.

Мой опыт работы с SB заключается в том, что он хорошо работает, но довольно сложно администрировать, и сложно получить обзор.

Итак, рассмотрели ли вы использование Service Broker? Если нет, почему бы и нет? Вы отправились на MSMQ? Есть ли что-нибудь в SQL Server 2008, которое заставит вас рассмотреть использование Service Broker.

Ответ 1

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

Мы используем его для загрузки данных из промежуточных таблиц в производственные таблицы, чтобы служба, загружающая промежуточную таблицу, не нуждалась в том, чтобы данные фактически обрабатывались, она может вернуться и получить больше данных для загрузки.

Мы используем его для очереди на удаление файлов из файловой системы. (Когда строка удалена, файл также нужно удалить.)

В предыдущих компаниях я использовал его для печати кредитных документов и проверок, которые были отправлены клиентам.

Я даже использовал Service Broker, чтобы делать ETL из базы данных OLTP в базу данных OLAP для отчетов в режиме реального времени.

Большинство людей (особенно администраторы баз данных) не любят Service Broker, потому что для этого нет никакого пользовательского интерфейса. Если вы хотите использовать сервис-брокер или посмотреть, что он делает, вам нужно писать и запускать некоторые T/SQL.

Ответ 2

Я использую SB в 2005 году около двух лет, при этом одна реализация обрабатывает несколько сотен тысяч сообщений в день. Я бы сказал, что самая большая проблема заключается не столько в архитектуре, сколько в понимании всех нюансов. Документация от Microsoft невелика, и ее очень мало практических примеров. Блог Remus Rusanu действительно помогли в выполнении таких действий, как повторное использование и активация настройки хранимых процедур в диалоговом режиме. Я нашел, что ДЕЙСТВИТЕЛЬНО важно как можно больше использовать диалоги (и задействовать всю связанную с этим блокировку), а также обрабатывать несколько полученных сообщений как набор, а не один за раз.

Мониторинг SB может быть болью. Вы в основном полагаетесь на кучу системных представлений, чтобы рассказать вам, что происходит. Сиротские сообщения - это боль. Там просто много маленьких ошибок, которые могут, ну, getcha.

Помимо проблем, и не так много, я думаю, что это действительно получилось лучше, чем я ожидал. Поскольку SB интегрирован в базу данных, нет отдельных очередей сообщений для резервного копирования вне базы данных. Все это непротиворечиво. Производительность хорошая. Это отличное решение.

Я буду использовать его снова и буду продолжать использовать его.

Ответ 3

В моей нынешней компании наше использование SB несколько отличается от использования других плакатов. Мы используем SB в SQL2005 главным образом в качестве инструмента управления. Например, мы используем его для управления обновлениями небольшого набора изменяемых таблиц, которые присутствуют в большом количестве неизменяемых баз данных. Все сообщения находятся между службами, запущенными в одном экземпляре, и объем сообщений очень низок.

Мой опыт работы с SB состоял в том, что он может быть несколько "исправным" для правильной настройки и, как вы упомянули в своем вопросе, трудно получить обзор состояния SB, потому что нет ни одного средства мониторинга.

Тем не менее, мы обнаружили, что это чрезвычайно ценно как способ автоматизации многих задач управления базой данных прослеживаемым и надежным способом.

Ответ 4

Недавно я рассмотрел использование Service Broker для проекта, но да, решил пойти вместо MSMQ.

Наша архитектура состояла из нескольких (кластерных) серверов, каждый из которых нуждался в надежной записи информации в один экземпляр SQL.

Как я понимаю, SB работает только для связи SQL-SQL, поэтому нам понадобился бы экземпляр SQL для каждого кластерного блока. Мы чувствовали, что это немного ненужно, поэтому с помощью MSMQ

Честно говоря, я не могу придумать сценарий, в котором я буду использовать SB - мне интересно узнать немного больше о вашем сценарии, чтобы увидеть, нет ли у меня чего-то жизненно важного.

Ответ 5

Service Broker может использоваться в различных случаях, когда требуется автоматизация в распределенной архитектуре. Такие приложения принимают события от различных устройств и требуют надежной обработки. Там, где события с устройств (обнаружения) или датчиков используются для обработки логики автоматизации. Для обмена данными между несколькими базами данных или приложениями.

Я надеюсь, что реализация может быть более обеспечена и надежной с SB