Freigeben über

Übersicht über Warteschlangen

In diesem Abschnitt werden die allgemeinen und kernen Konzepte für die Kommunikation in der Warteschlange vorgestellt. In den nachfolgenden Abschnitten erfahren Sie, wie die hier beschriebenen Warteschlangenkonzepte in Windows Communication Foundation (WCF) manifestiert werden.

Grundlegende Warteschlangenbegriffe

Beim Entwerfen einer verteilten Anwendung ist die Auswahl des richtigen Transports für die Kommunikation zwischen Diensten und Clients wichtig. Mehrere Faktoren wirken sich auf die Art des zu verwendenden Transports aus. Ein wichtiger Faktor – Isolation zwischen dem Dienst, dem Client und dem Transport – bestimmt die Verwendung eines in die Warteschlange eingereihten Transports oder eines direkten Transports, z. B. TCP oder HTTP. Aufgrund der Art der direkten Transporte wie TCP und HTTP wird die Kommunikation vollständig beendet, wenn der Dienst oder der Client nicht mehr funktioniert oder wenn das Netzwerk fehlschlägt. Der Dienst, der Client und das Netzwerk müssen gleichzeitig ausgeführt werden, damit die Anwendung funktioniert. Warteschlangentransporte ermöglichen eine Isolation. Dies bedeutet, dass der Client und der Dienst weiterhin funktionieren, wenn der Dienst bzw. der Client ausfallen oder wenn die jeweiligen Kommunikationsverbindungen ausfallen.

Warteschlangen bieten zuverlässige Kommunikation auch bei Fehlern in den Kommunikationsparteien oder im Netzwerk. Warteschlangen erfassen und übermitteln Nachrichten, die zwischen den kommunizierenden Parteien ausgetauscht werden. Warteschlangen werden in der Regel von einem Speicher eines bestimmten Typs unterstützt, beispielsweise flüchtiger oder permanenter Speicher. Warteschlangen speichern Nachrichten von einem Client im Auftrag eines Diensts und leiten diese Nachrichten später an den Dienst weiter. Die Dereferenzierungswarteschlangen ermöglichen eine sichere Fehlerisolation für beide Parteien. Aus diesem Grund ist dies der bevorzugte Kommunikationsmechanismus für Systeme, die eine hohe Verfügbarkeit erfordern, sowie für verteilte Dienste. Die Dereferenzierung führt jedoch zu einer hohen Latenz. Latenz ist die Zeitverzögerung zwischen dem Zeitpunkt, zu dem der Client eine Nachricht sendet, und dem Zeitpunkt, zu dem der Dienst ihn empfängt. Dies bedeutet, dass Sie nach dem Senden einer Nachricht nicht wissen, wann diese Nachricht verarbeitet werden kann. Die meisten in die Warteschlange eingereihten Anwendungen bewältigen hohe Latenz. Die folgende Abbildung zeigt ein konzeptionelles Modell der Kommunikation in der Warteschlange.

Modell der in die Warteschlange eingereihten Kommunikation

Konzeptionelles Modell für die Kommunikation in der Warteschlange

In Wirklichkeit ist die Warteschlange ein verteiltes Konzept. Eine Warteschlange kann also für eine Partei lokal oder für beide Parteien entfernt angeordnet sein. In der Regel ist die Warteschlange lokal für den Dienst. In dieser Konfiguration kann der Client nicht von der Konnektivität mit der Remotewarteschlange abhängen, um ständig verfügbar zu sein. Außerdem muss die Warteschlange unabhängig von der Verfügbarkeit des Diensts, der aus der Warteschlange ausliest, verfügbar sein. Ein Warteschlangenmanager verwaltet eine Sammlung von Warteschlangen. Es ist dafür verantwortlich, Nachrichten anzunehmen, die von anderen Warteschlangenmanagern an seine Warteschlangen gesendet werden. Außerdem ist sie für die Verwaltung der Konnektivität mit Remotewarteschlangen und das Übertragen von Nachrichten in diese Remotewarteschlangen verantwortlich. Um die Verfügbarkeit von Warteschlangen trotz Client- oder Dienstanwendungsfehlern sicherzustellen, wird der Warteschlangen-Manager in der Regel als externer Dienst ausgeführt.

Wenn ein Client eine Nachricht an eine Warteschlange sendet, wird die Nachricht an die Zielwarteschlange adressiert, bei der es sich um die vom Warteschlangen-Manager des Diensts verwaltete Warteschlange handelt. Der Warteschlangen-Manager auf dem Client sendet die Nachricht an eine Übertragungswarteschlange (auch: Ausgangswarteschlange). Die Übertragungswarteschlange ist eine Warteschlange im Clientwarteschlangen-Manager, die Nachrichten zur Übertragung in die Zielwarteschlange speichert. Der Warteschlangen-Manager findet dann einen Pfad zum Warteschlangen-Manager, der die Zielwarteschlange besitzt, und überträgt die Nachricht an ihn. Um eine zuverlässige Kommunikation sicherzustellen, implementieren die Warteschlangenmanager ein zuverlässiges Übertragungsprotokoll, um Datenverluste zu verhindern. Der Zielwarteschlangen-Manager akzeptiert Nachrichten, die an die Zielwarteschlange adressiert sind, die sie besitzt, und speichert die Nachrichten. Wenn der Dienst Leseanforderungen für die Zielwarteschlange sendet, stellt der Warteschlangen-Manager die Nachricht an die Zielanwendung zu. Die folgende Abbildung zeigt die Kommunikation zwischen den vier Parteien.

Diagramm der Anwendung in der Warteschlange

Warteschlangenkommunikation in einem typischen Bereitstellungsszenario

Der Warteschlangen-Manager stellt die erforderliche Isolation bereit, damit es sich nicht auf die Kommunikation auswirkt, wenn der Absender und Empfänger einzeln ausfallen. Der Vorteil der zusätzlichen Dereferenzierung, den Warteschlangen bieten, ermöglicht es außerdem, dass mehrere Anwendungsinstanzen aus ein und derselben Warteschlange auslesen, damit beim Farming zwischen den Knoten ein höherer Durchsatz erzielt wird. Daher ist es nicht ungewöhnlich, dass Warteschlangen verwendet werden, um höhere Skalierungs- und Durchsatzanforderungen zu erzielen.

Warteschlangen und Transaktionen

Transaktionen ermöglichen es Ihnen, eine Gruppe von Vorgängen zusammen zu gruppieren, sodass alle Vorgänge fehlschlagen, wenn ein Vorgang fehlschlägt. Ein Beispiel für die Verwendung von Transaktionen besteht darin, dass eine Person einen Geldautomaten verwendet, um 1.000 $ von ihrem Sparkonto auf ihr Prüfkonto zu übertragen. Dies beinhaltet die folgenden Vorgänge:

  • Auszahlung von 1.000 $ aus dem Sparkonto.

  • 1.000 $ auf dem Bankkonto einzahlen.

Wenn der erste Vorgang erfolgreich ist und 1.000 $ aus dem Sparkonto zurückgezogen wird, aber der zweite Vorgang fehlschlägt, geht der 1.000 $ verloren, da er bereits aus dem Sparkonto zurückgezogen wurde. Wenn ein Vorgang fehlschlägt, müssen beide Vorgänge fehlschlagen, um die Konten in einem gültigen Zustand beizubehalten.

In Transaktionsnachrichten können Nachrichten an die Warteschlange gesendet und von der Warteschlange unter einer Transaktion empfangen werden. Wenn also eine Nachricht in einer Transaktion gesendet wird und die Transaktion zurückgesetzt wird, lautet das Ergebnis so, als ob die Nachricht nie an die Warteschlange gesendet wurde. Analog dazu, wenn eine Nachricht in einer Transaktion empfangen wird und die Transaktion zurückgesetzt wird, ist das Ergebnis so, als ob die Nachricht nie empfangen wurde. Die Nachricht verbleibt in der Warteschlange, um gelesen zu werden.

Aufgrund der hohen Latenz haben Sie beim Senden einer Nachricht keine Möglichkeit zu wissen, wie lange es dauert, um die Zielwarteschlange zu erreichen, noch wissen Sie, wie lange es dauert, bis der Dienst die Nachricht verarbeitet. Aus diesem Gründen möchten Sie keine einzelne Transaktion verwenden, um die Nachricht zu senden, die Nachricht zu empfangen und dann die Nachricht zu verarbeiten. Dabei wird eine Transaktion erstellt, für die für einen unbestimmten Zeitraum kein Commit besteht. Wenn ein Client und ein Dienst über eine Warteschlange mithilfe von Transaktionen kommunizieren, sind daran zwei Transaktionen beteiligt: eine beim Client und eine beim Dienst. Die folgende Abbildung zeigt die Transaktionsgrenzen einer typischen Warteschlangenkommunikation.

Warteschlange mit Transaktionen

Warteschlangenkommunikation mit separaten Transaktionen zur Erfassung und Zustellung

Die Clienttransaktion verarbeitet und sendet die Nachricht. Wenn die Transaktion zugesichert wird, befindet sich die Nachricht in der Übertragungswarteschlange. Im Dienst liest die Transaktion die Nachricht aus der Zielwarteschlange, verarbeitet die Nachricht und führt dann einen Commit für die Transaktion durch. Wenn während der Verarbeitung ein Fehler auftritt, wird die Nachricht zurückgesetzt und in der Zielwarteschlange platziert.

Asynchrone Kommunikation mithilfe von Warteschlangen

Warteschlangen sind ein asynchrones Mittel der Kommunikation. Anwendungen, die Nachrichten mithilfe von Warteschlangen senden, können nicht warten, bis die Nachricht vom Empfänger empfangen und verarbeitet wird, weil die vom Warteschlangen-Manager eingeführte hohe Latenz vorliegt. Nachrichten können länger als die beabsichtigte Anwendung in der Warteschlange verbleiben. Um dies zu vermeiden, kann die Anwendung einen Wert vom Typ "Time-To-Live" für die Nachricht angeben. Dieser Wert gibt an, wie lange die Nachricht in der Übertragungswarteschlange verbleiben soll. Wenn dieser Zeitwert überschritten wird und die Nachricht noch nicht an die Zielwarteschlange gesendet wurde, kann die Nachricht an eine Warteschlange für unzustellbare Nachrichten übertragen werden.

Wenn der Absender eine Nachricht sendet, bedeutet die Rückgabe vom Sendevorgang, dass die Nachricht nur an die Übertragungswarteschlange des Absenders gesendet wurde. Wenn beispielsweise ein Fehler beim Abrufen der Nachricht in die Zielwarteschlange auftritt, kann die sendende Anwendung nicht sofort darüber informiert werden. Um solche Fehler zu notieren, wird die fehlgeschlagene Nachricht in eine Dead-Letter-Queue verschoben.

Jeder Fehler, wie etwa eine Nachricht, die die Zielwarteschlange nicht erreicht, oder wenn das ZeitlimitTo-Live abgelaufen ist, muss separat verarbeitet werden. Es ist daher nicht ungewöhnlich, dass in die Warteschlange eingereihte Anwendungen zwei Logikgruppen schreiben:

  • Die normale Client- und Dienstlogik des Sendens und Empfangens von Nachrichten.

  • Kompensationslogik zum Verarbeiten von Nachrichten aus der fehlgeschlagenen Übertragung oder Übermittlung.

In den folgenden Abschnitten werden diese Konzepte erläutert.

Programmierung der Warteschlange für unzustellbare Nachrichten

Warteschlangen für unzustellbare Nachrichten enthalten Nachrichten, die die Zielwarteschlange aus verschiedenen Gründen nicht erreichen. Die Gründe können von abgelaufenen Nachrichten bis hin zu Verbindungsproblemen reichen, die die Übertragung der Nachricht in die Zielwarteschlange verhindern.

In der Regel kann eine Anwendung Nachrichten aus einer systemweiten Warteschleife lesen, ermitteln, was schief gelaufen ist, und geeignete Maßnahmen ergreifen, z. B. die Fehler korrigieren und die Nachricht erneut senden oder die Nachricht notieren.

Programmierung für Warteschlangen für potenziell schädliche Nachrichten

Sobald eine Nachricht die Zielwarteschlange erreicht hat, kann der Dienst die Nachricht wiederholt nicht verarbeiten. Beispielsweise kann eine Anwendung, die unter einer Transaktion eine Nachricht aus der Warteschlange liest und eine Datenbank aktualisiert, feststellen, dass die Datenbank vorübergehend getrennt ist. In diesem Fall wird die Transaktion zurückgesetzt, eine neue Transaktion erstellt, und die Nachricht wird aus der Warteschlange erneut gelesen. Ein zweiter Versuch kann erfolgreich sein oder fehlschlagen. In einigen Fällen kann die Nachricht je nach Ursache des Fehlers wiederholt die Übermittlung an die Anwendung fehlschlagen. In diesem Fall gilt die Nachricht als "Gift". Solche Nachrichten werden in eine Giftwarteschlange verschoben, die von einer Giftbehandlungsanwendung gelesen werden kann.

Siehe auch

  • Last updated on