Soll ich MSMQ oder SQL Service Broker für Transaktionen verwenden?

Question

Ich habe von meinem Teamleiter zu untersuchen MSMQ als Option für die neue Version unseres Produkts gefragt. Sie SQL Service Broker in unserer aktuellen Version verwenden. Ich habe meinen gerechten Anteil an Experimenten durchgeführt und googeln zu finden, welches Produkt für meine Bedürfnisse besser ist, aber ich dachte, dass ich die beste Seite fragen würde ich für die Programmierung Antworten kennen.

Einige Details:

• Unser Kunde ist .NET 1.1 und 2.0-Code; das ist, wo die Nachricht wird gesendet von werden.
• Das Ziel in einer SQL Server 2005-Instanz. Alle Nachrichten, am Ende werden Datenbank-Updates oder Einsätze auf.
• Wir werden mehrere Updates senden, die als eine Transaktion behandelt werden müssen.
• Wir haben perfekte Nachricht Wiederherstellbarkeit haben; keine Nachrichten verloren gehen.
• Wir haben asynchron und in der Lage sein, um Nachrichten auch zu akzeptieren, wenn das Ziel SQL Server ausgefallen ist.
• unsere eigenen Warteschlangen Lösung zu entwickeln, ist keine Option; Wir sind ein kleines Team.

Dinge, die ich entdeckt habe, so weit:

• Sowohl MSMQ und SQL Service Broker kann den Job.
• Es scheint, dass Service-Broker schneller für Transaktionsnachricht sind.
• Service Broker erfordert eine SQL-Server irgendwo läuft, während MSMQ jede konfigurierte Windows-Rechner muss laufen irgendwo.
• MSMQ besser / schneller / einfacher einzurichten / run in Clustern zu sein scheint.

Bin ich etwas fehlt? Gibt es einen klaren Sieger hier? Alle Gedanken, Erfahrungen oder Links würden geschätzt. Vielen Dank!

EDIT: Am Ende haben wir mit Service-Broker haften, weil wir einen benutzerdefinierten DB Rahmen in einigen unserer Client-Code verwendet haben (wir behandeln Transaktionen besser). Der SQL-Code für Transaktionen erfaßt, aber nicht. Der Client-Code auch alle Version 1.1 von .NET, so würden wir alle den Client-Code zu aktualisieren. Vielen Dank für Ihre Hilfe!

Answer 1

Nachdem ich meine Anwendung nur migriert von Service Broker zu MSMQ, würde ich für die Verwendung von MSMQ abzustimmen. Es gibt mehrere Faktoren zu berücksichtigen, aber die meisten von denen haben zu tun, wie Sie Ihre Daten und wo die Verarbeitungsdauer werden.

• Wenn die Verarbeitung in der Datenbank gemacht? Service Broker
• Wenn es nur Daten bewegen? Service Broker
• wird die Verarbeitung in .NET / COM-Code getan? MSMQ
• Haben Sie Remote verteilte Transaktionen benötigen (zB Verarbeitung auf einem Feld anders als SQL)? MSMQ
• Müssen Sie in der Lage sein, um Nachrichten zu senden, während das Ziel nach unten ist? MSMQ
• Sie möchten nServiceBus, Masstransit, Rhino-ESB etc. benutzen? MSMQ

Dinge zu berücksichtigen, egal, was Sie wählen

• Wie wissen Sie die Gesundheit Ihrer Warteschlange? Beide Optionen anders behandeln Failover. Zum Beispiel Service Broker wird die Warteschlange in bestimmten Szenarien deaktivieren, die Ihre Anwendung herunternehmen können.
• Wie werden Sie perform Berichterstattung? Wenn Sie bereits SQL-Tabellen in Ihren Berichten verwenden, Service Broker leicht passen kann, wie es nur eine weitere dynamische Tabelle ist. Wenn Sie bereits Performance Monitor verwenden MSMQ passen kann schöner. Service Broker eine Menge von Leistungsindikatoren hat, so lassen Sie sich nicht das einzige Faktor sein.
• Wie messen Sie die Verfügbarkeit? Ist es nur dafür, dass Sie nicht die Transaktionen verlieren, oder haben Sie synchron reagieren müssen? Ich finde, dass die verteilte Natur von MSMQ für höhere Verfügbarkeit ermöglicht, weil die Hauptwarteschlange offline gehen kann und nichts verlieren. Während bei Service Broker Ihre Datenbank online sein müssen oder Sie sonst verlieren.
• Haben Sie bereits Erfahrungen mit einer dieser Technologien? Beide haben viele Implementierungsdetails, die zurückkommen und beißen Sie.
• Keine Mutter, welche Wahl Sie treffen, wie einfach es ist die zugrunde liegende Queuing-Technologie wechseln out? Ich empfehle, die eine generische Schnittstelle iQueue, dass Sie eine konkrete Umsetzung gegen schreiben. Auf diese Weise der Auswahl kann man leicht machen später geändert werden, wenn Sie feststellen, dass Sie die falsche gemacht. Immerhin eine Warteschlange ist nur eine Warteschlange und sollten Sie in eine bestimmte Implementierung nicht sperren.

Answer 2

ich MSMQ habe, bevor sie verwendet und der einzige Artikel, den ich zu Ihrer Liste hinzufügen würde, ist eine Überprüfung der Voraussetzungen für die Versionierung. Ich lief in ein Problem, bei dem eine Seite Win 2000 Server hatte und deshalb MSMQ v.2, im Vergleich zu Win 2003 Server und MSMQ v3. All mein .NET-Code gezielt v.3 und sie sind nicht kompatibel ... oder zumindest nicht so einfach so.

Nur eine Überlegung, wenn Sie den MSMQ Weg zu gehen.

Answer 3

Die Nachrichtengrößenbeschränkung in MSMQ hat meine Graben in dieser Richtung angehalten. Ich lerne, Service Broker für das Projekt.

Answer 4

  

Sie benötigen, um Nachrichten zu senden, während das Ziel nach unten ist? MSMQ

Ich verstehe nicht, warum? SSB kann problemlos Nachrichten an getrenntes Ziel senden. All diese Nachrichten an Übertragungswarteschlange zu gehen und würden geliefert werden, wenn Ziel erreichbar bleiben.