database - englisch - verteilte systeme tanenbaum pdf




Warteschlangen gegen Tabellen in Nachrichtensystemen (4)

  1. Daten werden dauerhaft in einer Tabelle gespeichert. Ich habe so viele Java (jms) -Anwendungen gesehen, die Nachrichten auf dem Weg zu nicht erfassten Ausnahmen oder anderen Fehlern verlieren oder verschwinden lassen.

    Welche JMS-Implementierung? Sun verkauft zuverlässige Warteschlangen, die keine Nachrichten verlieren können. Vielleicht haben Sie gerade ein käsiges JMS-konformes Produkt gekauft. IBMs MQ ist äußerst zuverlässig und es gibt JMS-Bibliotheken für den Zugriff darauf.

  2. Warteschlangen neigen dazu, sich zu füllen. Db Speicher ist praktisch unbegrenzt.

    Ummm ... Wenn deine Warteschlange voll ist, hört sich das an, als sei etwas kaputt. Wenn Ihre Apps abstürzen, ist das keine gute Sache, und Warteschlangen haben damit wenig zu tun. Wenn Sie eine wirklich schlechte JMS-Implementierung erworben haben, kann ich sehen, wo Sie damit möglicherweise nicht zufrieden sind. Es ist ein wettbewerbsfähiger Marktplatz. Suchen Sie einen besseren Warteschlangenmanager. Suns JCAPS hat einen wirklich guten Warteschlangenmanager, früher die SeeBeyond-Nachrichtenwarteschlange.

  3. Tabellen sind leicht zugänglich, während Sie esotische Instrumente verwenden müssen, um aus einer Warteschlange zu lesen.

    Das passt nicht zu meiner Erfahrung. Auf Tabellen wird über diese spezielle "andere Sprache" (SQL) zugegriffen, und ich muss mir Strukturzuordnungen von Tabellen zu Objekten und Datentypzuordnungen von VARCHAR2 zu String merken. Außerdem muss ich eine Art Zugriffsschicht verwenden (JDBC oder ein ORM, das JDBC verwendet). Das scheint sehr, sehr komplex. Auf eine Warteschlange wird durch MessageConsumers und MessageProducers über einfache Sends und Empfänge zugegriffen.

Ich habe die guten und die schlechten Seiten von Messagingsystemen in realen Produktionsumgebungen erlebt, und ich muss zugeben, dass eine gut organisierte Tabelle oder ein Schema von Tabellen einfach jedes Mal schlägt, wenn irgendeine andere Form von Nachrichtenwarteschlange verwendet wird, weil:

  1. Daten werden dauerhaft in einer Tabelle gespeichert. Ich habe so viele Java (jms) -Anwendungen gesehen, die Nachrichten auf dem Weg zu nicht erfassten Ausnahmen oder anderen Fehlern verlieren oder verschwinden lassen.
  2. Warteschlangen neigen dazu, sich zu füllen. Db Speicher ist praktisch unbegrenzt.
  3. Tabellen sind leicht zugänglich, während Sie esotische Instrumente verwenden müssen, um aus einer Warteschlange zu lesen.

Was halten Sie von jedem Ansatz?


Es klingt, als ob die Probleme, die Sie erlebt haben, nicht inhärent für Messaging sind, sondern Artefakte von schlecht implementierten Messaging-Systemen. Ist der Aufbau von Messaging-Systemen schwieriger als der Aufbau von Datenbanksystemen? Ja, wenn Sie nur Datenbanksysteme erstellen.

  • Nachrichten an nicht erfasste Ausnahmen verlieren? Das ist kaum die Schuld der Nachrichtenwarteschlange. Die Anwendungen, die Sie verwenden, sind schlecht entwickelt. Sie entfernen Nachrichten aus der Warteschlange, bevor die Verarbeitung abgeschlossen ist. Sie verwenden keine Transaktionen oder Journaling.
  • Message-Queues füllen sich, während der DB-Speicher "praktisch unendlich" ist? Sie sprechen, als ob die Verwaltung des Speicherplatzes etwas wäre, das Datenbanken nicht benötigten. Nachrichtenwarteschlangenserver erfordern wie die Datenbankserver eine Verwaltung.
  • Esoterische Instrumente aus einer Schlange zu lesen? Vielleicht, wenn Sie asynchrone Methoden als esoterisch empfinden. Vielleicht, wenn Sie Serialisierung und Deserialisierung als esoterisch empfinden. (Zumindest sind das die Dinge, die ich beim Erlernen von Messaging als esoterisch empfunden habe. Wie viele scheinbar esoterische Technologien sind sie wirklich banal, wenn man sie verstanden hat, und sie zu verstehen ist ein wichtiger Teil der Ausbildung des erfahrenen Entwicklers.)

Aspekte des Messaging, die es Datenbanken überlegen machen:

  • Asynchrone Verarbeitung Nachrichtenwarteschlangen benachrichtigen wartende Prozesse, wenn neue Nachrichten eintreffen. Um diese Funktionalität in einer Datenbank zu erreichen, müssen die wartenden Prozesse die Datenbank abfragen.
  • Trennung von Bedenken. Der Kommunikationskanal ist von den Implementierungsdetails des Nachrichteninhalts entkoppelt. Nur der Sender und der Empfänger müssen etwas über das Format des Datenstroms innerhalb einer gegebenen Nachricht wissen.
  • Fehlertoleranz. .. Messaging kann funktionieren, wenn Verbindungen zwischen Servern unterbrochen sind. Nachrichtenwarteschlangen können Nachrichten lokal speichern und sie nur dann an Remoteserver weiterleiten, wenn die Verbindung aktiv ist.
  • System Einbindung. In der Windows-Welt ist zumindest das Messaging in das Betriebssystem integriert. Es verwendet das Sicherheitsmodell des Betriebssystems, es wird über die Tools des Betriebssystems verwaltet usw.

Wenn Sie diese Dinge nicht benötigen, benötigen Sie wahrscheinlich keine Nachrichtenübermittlung.

Hier ist ein einfaches Beispiel für eine Anwendung für Messaging: Ich erstelle gerade ein System, bei dem Benutzer, die über mehrere Netzwerke verteilt sind, ziemlich komplizierte Sätze von Transaktionen eingeben, die verwendet werden, um gedruckte Ausgaben zu erzeugen. Die Ausgabegenerierung ist rechenintensiv und nicht Teil ihres Workflows. dh es ist den Benutzern egal, wann die Ausgabe erzeugt wird, nur das tut es.

Also serialisieren wir die Transaktionen in eine Nachricht und legen sie in eine Warteschlange. Ein auf einem Server ausgeführter Prozess erfasst Nachrichten aus der Warteschlange, erstellt die Ausgabe und speichert die Ausgabe in einem Abbildungssystem.

Wenn wir eine Datenbank als Nachrichtenspeicher verwenden würden, müssten wir ein Schema entwickeln, um ein Transaktionsformat zu speichern, das im Moment nur für den Absender und den Empfänger wichtig ist. Wir müssen sicherstellen, dass jede Workstation im Netzwerk permanent ist. persistente Verbindungen mit dem Datenbankserver, wären wir nicht in der Lage, diese Transaktionslast auf mehrere Server zu verteilen, und unser Ausgabeserver müsste die Datenbank Tausende Male am Tag abfragen, um zu sehen, ob neue Jobs zu verarbeiten sind.


Warteschlangen bieten zuverlässige Nachrichtenübermittlung. Die Store-and-Forward-Verbindung von Warteschlangen macht sie viel skalierbarer als Datenbanken, geschweige denn robuster.

Und Warteschlangen sollten nicht wirklich für die dauerhafte Speicherung von Informationen verwendet werden - es ist besser, sie als temporäre Posteingänge zu betrachten, im Gegensatz zu Datenbanken.


Die Phrase schlägt jedes Mal völlig davon ab, mit welchen Anforderungen Sie beginnen sollten. Sicher wird es nicht jedes Mal für alle schlagen.

Wenn Sie ein einziges System aufbauen, das bereits eine Datenbank verwendet, Sie keine sehr hohen Durchsatzanforderungen haben und nicht mit anderen Teams oder Systemen kommunizieren müssen, haben Sie wahrscheinlich recht.

Datenbank ist eine einfache Alternative zu Nachrichtenwarteschlangen.

Wo eine Nachrichtenwarteschlange leuchtet, ist

  • Sie möchten einen leistungsstarken, hochgradig gleichzeitigen und skalierbaren Load Balancer, mit dem Sie mehrere zehntausend Nachrichten pro Sekunde gleichzeitig über viele Server / Prozesse verarbeiten können (mit einer Datenbanktabelle können Sie ein paar Hundertsekunden verarbeiten und mehrere Threads sind ziemlich hart, da ein Prozess dazu neigt, die Message Queue-Tabelle zu sperren.
  • Sie müssen zwischen verschiedenen Systemen kommunizieren, die verschiedene Datenbanken verwenden (müssen also keinen Schreibzugriff auf Ihre Systemdatenbank an andere Personen in verschiedenen Teams usw. vergeben)

Für einfache Systeme mit einer einzigen Datenbank, Team und ziemlich bescheidenen Leistungsanforderungen - verwenden Sie sicher eine Datenbank. Verwenden Sie das richtige Werkzeug für die Arbeit usw.

Doch wo Nachrichtenwarteschlangen glänzen, ist in großen Organisationen, wo es viele Systeme gibt, die miteinander kommunizieren müssen (und Sie wollen nicht, dass eine Unternehmensdatenbank ein zentraler Punkt des Versagens oder der Ort der Versionshölle ist), oder wenn Sie hohe Leistungsanforderungen.

In Bezug auf die Leistung schlägt eine Nachrichtenwarteschlange immer eine Datenbanktabelle - da Nachrichtenwarteschlangen speziell für den Job entworfen wurden und nicht auf pessimistischen Tabellensperren beruhen (die für eine Datenbankimplementierung einer Warteschlange erforderlich sind - um den Lastausgleich durchzuführen). und gute Nachrichten-Warteschlangen führen eifriges Laden von Nachrichten in Warteschlangen durch, um den Netzwerk-Overhead einer Datenbank zu vermeiden .

Ebenso würden Sie niemals eine Datenbank verwenden, um den Lastausgleich von HTTP-Anforderungen auf Ihren Webservern durchzuführen, da dies zu langsam wäre. Wenn Sie hohe Leistungsanforderungen für Ihren Lastenausgleicher haben, würden Sie auch keine Datenbank verwenden.





message-queue