web-dev-qa-db-fra.com

Inconvénients de SQL Server Service Broker

J'ai fait de la recherche et du développement pour l'étendue de SQL Server Service Broker pour remplacer la solution de messagerie actuelle MSMQ. Je veux connaître les inconvénients de SQL Server Service Broker par rapport à MSMQ pour les critères suivants.

  1. Développement
  2. Dépannage
  3. Performances (disons que nous devons traiter 100 000 messages par jour, avec une taille moyenne d'environ 25 Ko)
  4. Évolutivité
sql-servermsmqmessage-queueservice-broker
20
mit

J'ai utilisé Service Broker dans mon projet actuel, après avoir utilisé MSMQ (négocié par MassTransit ) avec beaucoup de succès. Au départ, je doutais de l'utilisation de Service Broker, mais je dois admettre qu'il a très bien fonctionné.

Si vous utilisez le modèle de publication/abonnement, j'utiliserais Message Queuing à chaque fois (bien que j'utiliserais RabbitMQ sur MSMQ si le projet le permettait), mais lorsque vous souhaitez simplement parcourir une pile de données et la conserver sur Sql Server , alors Service Broker est une excellente solution: le fait qu'il soit si "proche du métal" est un gros avantage.

Développement

Service Broker nécessite beaucoup de passe-partout, ce qui est pénible, mais à moins que vous ne prévoyiez d'avoir beaucoup de files d'attente différentes, c'est gérable. Les projets Sql Server dans Visual Studio prennent beaucoup de peine à se déployer.

Dépannage

Service Broker est une boîte noire - les messages entrent et ils sortent généralement, mais s'ils ne le font pas, le dépannage peut être problématique, et tout ce que vous pouvez faire est interroger les vues du système - et parfois vous ne peut tout simplement pas savoir ce qui a mal tourné. C'est ennuyeux, mais MSMQ a le même genre de problèmes ..

Performances

Les performances de Service Broker sont excellentes. Nous traitons beaucoup plus de 100 000 messages par jour, plus de 30 000 par heure à notre charge SLA et nos tailles de message sont importantes. Je dirais que nous traitons près de 100 000 messages par heure pendant tests de charges lourdes.

Pour de meilleures performances, je vous conseille d'utiliser un pool de dialogue comme celui-ci 1 comme la création d'une boîte de dialogue Service Broker peut être une opération coûteuse .

Vous voudrez également utiliser les procédures de gestion des erreurs détaillées par Remus Rusan . (Si vous utilisez Service Broker, vous pourriez aussi bien lire tout ce que Remus a écrit sur le sujet avant de commencer, car vous finirez par le lire éventuellement!)

Évolutivité

Vous pouvez certainement utiliser plus d'un serveur pour évoluer si nécessaire, bien que nous n'ayons pas dû le faire, et d'après la taille de la charge que vous mentionnez, je ne pense pas que vous en ayez besoin non plus.

Je ne pense pas avoir vraiment réussi à répondre à votre question, car je n'ai pas suffisamment souligné les inconvénients des files d'attente Service Broker. Je dirais que la nature impénétrable de son fonctionnement interne est la chose qui m'agace le plus - quand cela fonctionne, cela fonctionne très bien, mais quand il cesse de fonctionner, il peut être très difficile de comprendre pourquoi. De plus, si vous avez beaucoup de messages dans une file d'attente, utilisez ALTER QUEUE prend beaucoup de temps.

Ne pas savoir comment vous utilisez MSMQ rend également différent la comparaison équitable des deux technologies.

1 Recréé dans un Gist comme rl d'origine est maintenant "désactivé" et la page n'est pas dans les archives Internet. Finalement trouvé une copie ici

34
stuartd