it-swarm.com.de

Nachrichtenwarteschlange. Datenbank vs Dedicated MQ

Ich bin nach Rat bezüglich der Nachrichtenwarteschlange. Wir haben Anforderungen an "Jobs", die in eine Nachrichtenwarteschlange gestellt werden sollen.

Der ursprüngliche Vorschlag bestand darin, nur eine SQL Server-Instanz zu verwenden und Nachrichten daraus zu verarbeiten. Alles, was ich im Internet gelesen habe, deutet darauf hin, dass die Verwendung einer Datenbank für eine Nachrichtenwarteschlange keine skalierbare Lösung ist. Aus diesem Grund wurde die Idee vorgeschlagen, RabbitMQ oder ein anderes MQ eines Drittanbieters zu verwenden.

Die andere zu berücksichtigende Sache ist, dass die Anforderung für die "Jobverarbeitung" nicht weniger als 30 Sekunden beträgt, sodass der Prozess, der den Job ausführt, die Datenbank alle 30 Sekunden abfragt. Für mich scheint dies nicht so schlimm zu sein und würde wahrscheinlich in Ordnung funktionieren, ohne der Datenbank eine große Last hinzuzufügen.

Wir haben bereits eine Datenbank auf unseren Clients eingerichtet, die wir dafür verwenden könnten, sodass unseren Kunden nicht viel zusätzlicher Support zur Verfügung steht. Wenn wir jedoch einen MQ eines Drittanbieters hinzufügen, wird die Netzwerkkonfiguration usw. zusätzlich unterstützt beträchtlich, da es viele Benutzer gibt.

Die andere Option, die ich in Betracht gezogen habe, bestand darin, den Benutzern die Wahl zwischen beiden zu ermöglichen. Wenn sie ein kleiner Benutzer sind, ist die SQL Server-Lösung in Ordnung. Wenn sie jedoch ein größerer Benutzer sind, können sie eine MQ-Lösung eines Drittanbieters konfigurieren.

Ich bin von keiner Lösung überzeugt, ich frage mich, ob jemand etwas hat, das ich berücksichtigen oder beraten sollte.

21
user1653400

Alles, was ich im Internet gelesen habe, deutet darauf hin, dass die Verwendung einer Datenbank für eine Nachrichtenwarteschlange keine skalierbare Lösung ist.

Die Realität wird häufig von " benutze nicht [~ # ~] x [~ # ~] ignoriert, weil sie nicht skaliert " (Link enthält einige Sprachen kann unangenehm sein) Menge ist, dass Skalierung nicht immer wichtig ist. Ich würde sogar sagen, dass, wenn man jede Anwendung auf dem Planeten insgesamt betrachtet, die Skalierung selten wichtig ist.

In Ihrem Kommentar wird eine Rate von 20.000 Nachrichten pro Tag angegeben, was bedeutet, dass Sie eine durchschnittliche Rate von 0,23 Nachrichten pro Sekunde (eine alle 4,3 Sekunden) unterstützen müssen. Wenn sich herausstellt, dass Ihr Projekt zwei Größenordnungen erfolgreicher ist als erwartet, steigen Ihre Anforderungen auf die Verarbeitung von 23 Nachrichten pro Sekunde. Dies ist eine Aufgabe, die ich gerne meinem vier Jahre alten Mobiltelefon oder einer Himbeere geben würde Pi. Dies ist immer noch keine groß angelegte Anwendung, selbst wenn Sie noch ein paar Größenordnungen darüber hinausgehen.

Ich habe gesehen (zum Glück von der Seitenlinie aus), dass Projekte schlecht enden, weil sie entweder zu viel Zeit zu früh damit verbracht haben, über die Skalierung nachzudenken, die nicht passieren würde, oder überhaupt keine Zeit damit verbracht haben und von der Skalierung zerquetscht wurden, die es letztendlich tat. Wie alles andere gibt es ein fröhliches Medium. Wenn Sie der Meinung sind, dass eine große Skalierung für Ihre Anwendung eine realistische Möglichkeit ist, sollte es nicht schwierig sein, ein Geschäftsmodell für die geringe zusätzliche Arbeit zu erstellen, um eine ausreichende Abstraktion für nicht skalierbare Teile zu erstellen, deren Bereitstellung kostengünstig ist now. Dies bedeutet, dass später, falls Skalierungsbedarf besteht, Sie eine Möglichkeit (und möglicherweise den Umsatz) haben, diese Teile im Großhandel auszutauschen, ohne das gesamte System überdenken zu müssen.

Während das Nachrichtenvolumen Ihrer Anwendung selbst bei bescheidener Hardware nicht dazu führt, dass eine Datenbank oder ein Nachrichtenwarteschlangensystem ins Schwitzen gerät, haben Sie wahrscheinlich andere Anforderungen an die Verarbeitung Ihrer Nachrichtentransaktionen, die das eine oder andere zu einer besseren Wahl machen. Diese Anforderungen sollten Sie bewerten.

18
Blrfl

Nachrichtenwarteschlangen kommen wirklich zur Geltung, wenn Sie viele von ihnen haben und Nachrichten zwischen ihnen weiterleiten, Fanout an mehr als einen Verbraucher usw.

Wenn Sie nur eine einzige "Jobwarteschlange" mit Dingen haben, die Sie "offline" verarbeiten möchten, reicht eine SQL-Tabelle aus.

Vergessen Sie nicht, sicherzustellen, dass Sie eine Möglichkeit haben, laufende Jobs zu markieren, alte zu bereinigen und zu warnen, wenn das System stoppt. Für eine einzelne Warteschlange ist das manuelle Verwalten dieser Dinge jedoch weniger aufwendig als das Verwalten einer separaten Warteschlangenlösung.

9
Ewan

Wie andere bereits erwähnt haben, ist der Maßstab hier wahrscheinlich nicht wichtig. Das Problem bei der Verwendung von zwei verschiedenen Speichermechanismen ist die Transaktionsintegrität.

Wenn Sie eine dedizierte Nachrichtenwarteschlange verwenden, müssen Sie im Fehlerfall eine der folgenden Optionen auswählen.

  1. Lassen Sie zu, dass Daten auf mb, aber nicht in db sein können
  2. Lassen Sie zu, dass Daten in db, aber nicht in mb sein können
  3. Richten Sie zwei Phasen-Commit- oder verteilte Transaktionen zwischen db und mq ein, was kompliziert sein kann

All diese Probleme verschwinden, wenn Sie Daten nur mit einer normalen Transaktion an einem Ort speichern. Aus diesem Grund ist die Verwendung von db als Task-Warteschlange eine perfekte Lösung.

5

Aus praktischen Gründen sind die Hauptgründe für die Verwendung einer Nachrichtenwarteschlange:

  • Ich musste das Rad nicht neu erfinden. Das Entwerfen selbst der einfachsten Nachrichtenwarteschlange mithilfe einer Datenbank erfordert mindestens ein paar Stunden Nachdenken, ein paar Stunden Codierung usw. Im Vergleich zur Implementierung einer Nachrichtenwarteschlange ist der Zeitaufwand für die Konfiguration und/oder Automatisierung der Konfiguration gering
  • Nachrichtenwarteschlangen haben eine schöne und übersichtliche Schnittstelle für Hersteller und Verbraucher. Dies ist wahrscheinlich das Wichtigste beim Schreiben einer Bewerbung. Ohne die Schnittstelle sind Nachrichtenwarteschlangen im Grunde nur eine Sammlung von Daten
  • Nachrichtenwarteschlangen bieten weitere Funktionen, die möglicherweise in Zukunft benötigt werden

Wenn Sie Benutzern die Auswahl erlauben, ist dies wirklich ein Implementierungsdetail, das Benutzer nicht interessieren sollten. Benutzer sollten dieselbe Schnittstelle erhalten und es sollte keinen Unterschied für Benutzer geben, wenn eine Datenbank oder eine Nachrichtenwarteschlange verwendet wird. Sobald ein einzelnes Design festgelegt ist, können Benutzer wahrscheinlich festlegen, wie viele Knoten bereitgestellt werden müssen, um ihren Anforderungen gerecht zu werden.

4
imel96

Ich habe eine Mssql-Nachrichtenwarteschlangenlösung erstellt, die laut einem Leistungstest 20.000 Vorgänge pro Sekunde verarbeiten kann, und wir benötigen die meiste Zeit 10/s. Ich denke, dass die Tatsache, dass Sie tatsächlich Priorität haben können, eine Funktion ist, die der dedizierten Nachrichtenwarteschlange fehlt. Und das war in meinem Fall eine wichtige Voraussetzung.

1
Stephan Ryer