Devrais-je utiliser MSMQ ou SQL Service Broker pour les transactions?

Question

Le responsable de mon équipe m'a demandé d'examiner MSMQ en tant qu'option pour la nouvelle version de notre produit. Nous utilisons SQL Service Broker dans notre version actuelle. J'ai fait ma juste part d'expérimentation et de recherche sur Google pour trouver le produit qui répond le mieux à mes besoins, mais je pensais que je demanderais au meilleur site que je connaisse pour obtenir des réponses en matière de programmation.

Quelques détails:

• Notre client est le code .NET 1.1 et 2.0; C’est là que le message sera envoyé.
• La cible dans une instance de SQL Server 2005. Tous les messages finissent par être des mises à jour ou des insertions dans la base de données.
• Nous vous enverrons plusieurs mises à jour qui doivent être traitées comme une transaction.
• Nous devons pouvoir récupérer parfaitement les messages. aucun message ne peut être perdu.
• Nous devons être asynchrones et pouvoir accepter les messages même lorsque le serveur SQL cible est en panne.
• Développer notre propre solution de file d’attente n’est pas une option; nous sommes une petite équipe.

Ce que j'ai découvert jusqu'à présent:

• MSMQ et SQL Service Broker peuvent effectuer le travail.
• Il semble que service broker soit plus rapide pour les messages transactionnels.
• Service Broker nécessite un serveur SQL qui s'exécute quelque part, tandis que MSMQ nécessite qu'une machine Windows configurée s'exécute quelque part.
• MSMQ semble être meilleur / plus rapide / plus facile à configurer / exécuter en clusters.

Est-ce que je manque quelque chose? Y a-t-il un gagnant clair ici? Toutes les pensées, expériences ou liens seraient valorisés. Merci!

EDIT: Nous avons fini par rester avec Service Broker car nous avons une structure de base de données personnalisée utilisée dans certains de nos codes clients (nous gérons mieux les transactions). Ce code a capturé SQL pour les transactions, mais pas. Le code client était également entièrement de la version 1.1 de .NET, nous devions donc mettre à niveau tout le code client. Merci pour votre aide!

Answer 1

Venant juste de migrer mon application de Service Broker vers MSMQ, je devrais voter pour l’utilisation de MSMQ. Plusieurs facteurs doivent être pris en compte, mais la plupart d'entre eux sont liés à la manière dont vous utilisez vos données et à l'emplacement du traitement.

• Si le traitement est effectué dans la base de données? Service Broker
• S'il s'agit simplement d'un transfert de données? Service Broker
• Le traitement est-il effectué en code .NET / COM? MSMQ
• Avez-vous besoin de transactions distribuées distantes (par exemple, le traitement sur une boîte autre que SQL)? MSMQ
• Avez-vous besoin de pouvoir envoyer des messages lorsque la destination est en panne? MSMQ
• Voulez-vous utiliser nServiceBus, MassTransit, Rhino-ESB, etc.? MSMQ

Éléments à prendre en compte, quel que soit votre choix

• Comment connaissez-vous la santé de votre file d'attente? Les deux options gèrent le basculement différemment. Par exemple, Service Broker désactivera votre file d'attente dans certains scénarios susceptibles de détruire votre application.
• Comment allez-vous effectuer les rapports? Si vous utilisez déjà des tables SQL dans vos rapports, Service Broker peut facilement s'intégrer car il ne s'agit que d'une autre table dynamique. Si vous utilisez déjà l'Analyseur de performances, MSMQ vous convient mieux. Service Broker dispose de nombreux compteurs de performance. Ne laissez donc pas cela être votre seul facteur.
• Comment mesurez-vous le temps de disponibilité? S'assure-t-il simplement de ne pas perdre de transactions ou devez-vous répondre de manière synchrone? Je trouve que la nature distribuée de MSMQ permet une disponibilité plus longue, car la file d'attente principale peut être déconnectée et ne rien perdre. Attendu qu'avec Service Broker , votre base de données doit être en ligne, sinon vous perdez votre chance.
• Avez-vous déjà utilisé l'une de ces technologies? Les deux ont beaucoup de détails de mise en œuvre qui peuvent revenir et vous mordre.
• Peu importe le choix que vous faites, est-il facile de désactiver la technologie de mise en file d'attente sous-jacente? Je recommande d'avoir une interface IQueue générique sur laquelle vous écrivez une implémentation concrète. De cette façon, le choix que vous faites peut facilement être modifié ultérieurement si vous constatez que vous avez fait le mauvais choix. Après tout, une file d’attente n’est qu’une file d’attente et ne devrait pas vous enfermer dans une implémentation spécifique.

Answer 2

J'ai déjà utilisé MSMQ et le seul élément à ajouter à votre liste est une vérification préalable du contrôle de version. J'ai rencontré un problème où un site avait Win 2000 Server et donc MSMQ v.2, par rapport à Win 2003 Server et MSMQ v3. Tous mes codes .NET ciblés v.3 et ils ne sont pas compatibles ... ou du moins pas facilement.

Juste une considération si vous choisissez la route MSMQ.

Answer 3

La limitation de la taille des messages dans MSMQ m'a empêché de creuser dans cette direction. Je suis en train d'apprendre Service Broker pour le projet.

Answer 4

  

Avez-vous besoin de pouvoir envoyer des messages lorsque la destination est en panne? MSMQ

Je ne comprends pas pourquoi? SSB peut envoyer des messages à une destination déconnectée sans aucun problème. Tous ces messages vont dans la file d’attente et seront remis lorsque la destination reste accessible.