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

Wurde ich gefragt, von meinem team-leader zu untersuchen, MSMQ, als option für die neue version unseres Produktes. Wir verwenden SQL Service Broker in unserer aktuellen version. Ich habe meinen Gerechten Anteil an Experimentieren und Googeln, um herauszufinden, welches Produkt ist besser für meine Bedürfnisse, aber ich dachte, ich würde bitten, die beste Seite die ich kenne für die Programmierung Antworten.

Einige details:

  • Unser Kunde ist .NET 1.1 und 2.0-code; das ist, wo die Nachricht gesendet werden soll.
  • Die Gegner in einer Instanz von SQL Server 2005. Alle Nachrichten, die am Ende als Datenbank-updates oder inserts.
  • Senden wir mehrere updates, die behandelt werden muss als eine Transaktion.
  • Wir haben die perfekte Nachricht Wiederherstellbarkeit; keine Nachrichten verloren gehen können.
  • Wir werden asynchron und in der Lage zu akzeptieren Nachrichten, auch wenn die Ziel-SQL-server ist down.
  • Die Entwicklung unserer eigenen queuing-Lösung ist keine option; wir sind ein kleines team.

Dinge, die ich entdeckt habe bisher:

  • Beide MSMQ und SQL Service Broker den job tun können.
  • Es scheint, dass service broker ist schneller für Transaktions-E-Mails.
  • Service Broker erfordert einen SQL-server laufen irgendwo, in der Erwägung, dass MSMQ Bedürfnisse konfigurierte Windows-Maschine läuft irgendwo.
  • MSMQ scheint besser/schneller/einfacher zu set-up/run-in-Cluster.

Bin ich etwas fehlt? Gibt es einen klaren Sieger hier? Alle Gedanken, Erfahrungen, oder links wären sehr geschätzt. Danke!

EDIT: Wir landeten kleben mit service broker-denn wir haben eine benutzerdefinierte DB Rahmen, die in einige unserer client-code (wir Transaktionen besser). Dass code, erfasst die SQL-Transaktionen, aber nicht . Der client-code auch alle in der version 1.1 .NET, so hätten wir um ein upgrade aller client-code. Vielen Dank für Ihre Hilfe!

InformationsquelleAutor der Frage Ed Schwehm | 2008-10-27

  1. 32

    Gerade migriert, meine Anwendung von Service Broker zu MSMQ, ich würde Stimmen für die Verwendung von MSMQ. Es gibt mehrere Faktoren zu berücksichtigen, aber die meisten von denen haben zu tun mit, wie Sie Ihre Daten nutzen und wo die Verarbeitung Leben.

    • Wenn die Verarbeitung der Daten erfolgt in der Datenbank? Service Broker
    • Wenn es nur das verschieben der Daten? Service Broker
    • Ist die Verarbeitung erfolgt in .NET/COM-code? MSMQ
    • Benötigen Sie remote-verteilte Transaktionen (zum Beispiel die Bearbeitung auf einem Feld anders als SQL)? MSMQ
    • Müssen Sie in der Lage sein, Nachrichten zu senden, während das Ziel down ist? MSMQ
    • Möchten Sie verwenden, nServiceBus, MassTransit, Rhino-ESB, etc.? MSMQ

    Dinge zu beachten, egal was Sie wählen,

    • Wie Sie wissen, die Gesundheit der Warteschlange? Beide Optionen Griff-failover anders. Zum Beispiel Service Broker wird, deaktivieren Sie die Warteschlange in bestimmten Szenarien, mit denen Sie Ihre Anwendung.
    • Wie werden Sie führen reporting? Wenn Sie bereits SQL-Tabellen in Ihren berichten, Service Broker einfach fit in, wie es nur eine andere dynamische Tabelle einfügen. Wenn Sie bereits mithilfe des Systemmonitors MSMQ könnten schöner sein. Service Broker eine Menge von Leistungsindikatoren, so lassen Sie sich nicht Ihre einzige Faktor.
    • Wie Messen Sie die Betriebszeit? Ist es lediglich dafür, dass Sie nicht verlieren, Transaktionen, oder Sie brauchen, um zu reagieren synchron? Ich finde, dass die verteilte Natur von MSMQ ermöglicht eine höhere Verfügbarkeit, da die Haupt-queue können offline gehen und nichts verlieren. In der Erwägung, dass mit Service Broker Ihre Datenbank muss online sein, oder sonst Sie verlieren.
    • Sie haben bereits Erfahrung mit einer dieser Technologien? Beide haben eine Menge von details zur Implementierung, können kommen zurück und beißen Sie.
    • Kein mater, was Wahl, die Sie machen, wie einfach ist es zu wechseln aus der zugrunde liegenden Warteschlangen-Technologie? Ich empfehle mit einem generischen interface IQueue, dass Sie schreiben, eine konkrete Umsetzung vor. Auf diese Weise die Wahl, die Sie machen, kann auch nachträglich einfach geändert werden, wenn Sie feststellen, dass Sie aus den falschen. Denn eine Warteschlange ist nur eine Warteschlange und sollte nicht sperren Sie in einer bestimmten Implementierung.

    InformationsquelleAutor der Antwort Aaron Weiker

  2. 4

    Ich verwendet habe, MSMQ vor und die einzige Sache, die ich möchte hinzufügen zur Liste ist eine überprüfung der Voraussetzungen für die Versionsverwaltung. Ich lief in ein Problem, wo die eine Seite hatte Win 2000 Server und daher MSMQ-v. 2, im Vergleich zu Win 2003 Server und MSMQ-v3. Alle meine .NET-code gezielten v. 3 und Sie sind nicht kompatibel... oder zumindest nicht so leicht.

    Nur eine überlegung, wenn Sie gehen, der MSMQ-route.

    InformationsquelleAutor der Antwort Mike L

  3. 3

    Die Größe der Nachricht-Einschränkung in MSMQ angehalten wurde, meine Graben sich in diese Richtung. Ich bin Lern-Service-Broker für das Projekt.

    InformationsquelleAutor der Antwort Dan

  4. 1

    Müssen Sie in der Lage sein, Nachrichten zu senden, während das Ziel down ist? MSMQ

    Verstehe ich nicht, warum? Kann die SSB senden von Nachrichten an offline-Ziel ohne Probleme. Alle diese Nachrichten auf übertragungs-Warteschlange und würde geliefert werden, wenn Ziel bleiben erreichbar.

    InformationsquelleAutor der Antwort user368415

Schreibe einen Kommentar