Question Inconvénients de SQL Server Service Broker [fermé]


J'ai fait de la R & D pour la portée de SQL Server Service Broker afin de remplacer la solution de messagerie actuelle MSMQ. Je veux connaître les inconvénients de SQL Server Service Broker contrairement à MSMQ pour les critères suivants.

  1. Développement
  2. Dépannage
  3. Performance (disons que nous devons traiter 100 000 messages par jour, avec une taille moyenne d'environ 25 Ko)
  4. Évolutivité

15
2018-02-05 06:43


origine


Réponses:


J'ai utilisé Service Broker dans mon projet actuel, ayant déjà utilisé MSMQ (courtier par Le transport en commun) avec beaucoup de succès. Au début, je doutais de l’utilisation de Service Broker, mais je dois admettre qu’elle a très bien fonctionné.

Si vous utilisez le modèle Publish / Subscribe, alors j'utiliserais Message Queuing à chaque fois (bien que j'utiliserais RabbitMQ sur MSMQ si le projet le permettait) mais que vous souhaitiez simplement passer en revue 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 planifiiez avoir beaucoup de files d'attente différentes, vous pouvez le gérer. Les projets Sql Server dans Visual Studio prennent beaucoup de temps à 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 de interroger les vues du système - et parfois vous ne pouvez tout simplement pas savoir ce qui ne va pas. C'est ennuyeux, mais MSMQ a le même genre de problèmes.

Performance

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 de SLA, et la taille de nos messages est importante. Je pense que nous traitons près de 100 000 messages par heure lors des tests de charge lourde.

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

Vous voudrez aussi utiliser les procédures de traitement des erreurs détaillées par Remus Rusanu. (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!)

Évolutivité

Si vous le souhaitez, vous pouvez certainement utiliser plusieurs serveurs, même si nous n’avons pas eu à le faire, et à partir de la taille de la charge que vous avez mentionnée, vous n’en aurez pas besoin non plus.

Je ne pense pas avoir vraiment réussi à répondre à votre question, car je n'ai pas suffisamment mis en évidence les inconvénients des files d'attente Service Broker. Je dirais que la nature impénétrable de son fonctionnement interne est ce qui me gêne le plus - quand ça marche, ça marche très bien, mais quand ça ne marche plus, il peut être très difficile de comprendre pourquoi. En outre, si vous avez beaucoup de messages dans une file d'attente, utilisez ALTER QUEUE prend beaucoup de temps pour terminer.

Le fait de ne pas savoir comment vous utilisez MSMQ rend également difficile la comparaison équitable des deux technologies.


29
2018-02-08 00:25