Я выполнял r & d для области SQL Server Service Broker, чтобы заменить текущее решение для обмена сообщениями MSMQ. Я хочу знать недостатки SQL Server Service Broker в отличие от MSMQ для следующих критериев.
Я использовал Service Broker в своем текущем проекте, предварительно используя MSMQ (с посредничеством MassTransit) с большим успехом. Вначале я сомневался в использовании Service Broker, но я должен признать, что он очень хорошо справился.
Если вы используете модель публикации/подписки, я бы каждый раз использовал Message Queuing (хотя я бы использовал RabbitMQ над MSMQ, если проект разрешен), но когда вы просто хотите пережевывать стек данных и сохраняете его на Sql Server, то Service Broker - отличное решение: тот факт, что он так "близок к металлу", является большим преимуществом.
развитие
Сервисный брокер требует большого количества шаблонов, что является болью, но если вы не планируете иметь много разных очередей, то это будет возможно. Серверные проекты Sql в Visual Studio несут большую боль при развертывании.
Поиск проблемы
Service Broker - это черный ящик - сообщения поступают, и они обычно выходят, но если они этого не делают, то устранение неполадок может быть проблематичным, и все, что вы можете сделать, это запросить системные представления - и иногда вы просто не можете узнать, что пошло не так. Это раздражает, но MSMQ имеет такие же проблемы.
Спектакль
Производительность сервисного брокера превосходна. Мы обрабатываем намного больше 100 000 сообщений в день, более 30 000 в час при загрузке SLA, а размеры наших сообщений большие. Я бы оценил, что мы обрабатываем около 100 000 сообщений в час во время испытаний на большую нагрузку.
Для лучшей производительности я бы посоветовал использовать Dialog Pool, как этот 1, поскольку создание диалога Service Broker может быть дорогостоящей операцией.
Вы также захотите использовать процедуры обработки ошибок, описанные Ремусом Русану. (Если вы используете Service broker, вы также можете прочитать все, что Ремус написал на эту тему, прежде чем вы начнете, так как вы в конце концов прочтете это!)
Масштабируемость
Конечно, вы можете использовать более одного сервера для масштабирования, хотя нам этого и не нужно было делать, и из упомянутого вами размера загрузки я не думаю, что вам тоже понадобится.
Я не думаю, что мне действительно удалось ответить на ваш вопрос, так как я не выделил достаточно недостатков очередей Service Broker. Я бы сказал, что непроницаемая природа его внутренней работы - это то, что меня больше всего раздражает - когда она работает, она работает очень хорошо, но когда она перестает работать, может быть очень трудно понять, почему. Кроме того, если у вас много сообщений в очереди, использование ALTER QUEUE занимает очень много времени.
Не зная, как вы используете MSMQ, он также отличается тем, что сравнивает две технологии.
1 Снова воссоздается, поскольку исходный URL теперь "отключен", а страница не находится в интернет-архиве.