Bewährte Methoden für die Kommunikation unter Verwendung von Warteschlangen

Artikel
04/06/2023

Dieses Thema enthält empfohlene Methoden für die Kommunikation unter Verwendung von Warteschlangen in Windows Communication Foundation (WCF). In den folgenden Abschnitten werden bewährte Methoden aus der Perspektive eines Szenarios vorgestellt.

Schnelles Warteschlangen-Messaging nach dem Best-Effort-Prinzip

Falls Sie die Vorzüge der Nachrichtentrennung beim Warteschlangen-Messaging nutzen möchten und auf einen schnellen, leistungsfähigen Nachrichtenaustausch mit einer Best-Effort-Zusicherung angewiesen sind, verwenden Sie eine Warteschlange, bei der es sich nicht um eine Transaktionswarteschlange handelt, und legen Sie die ExactlyOnce-Eigenschaft auf false fest.

Darüber hinaus können Sie die Durable-Eigenschaft auf false festlegen, um die Kosten, die beim Schreiben auf einen Datenträger entstehen, zu umgehen.

Die Sicherheit wirkt sich auf die Leistung aus. Weitere Informationen finden Sie unter Überlegungen zur Leistung.

Zuverlässiges End-to-End-Warteschlangen-Messaging

In den folgenden Abschnitten werden bewährte Methoden für Szenarien beschrieben, in denen ein zuverlässiges End-to-End-Messaging erforderlich ist.

Grundlegende zuverlässige Übertragung

Um eine zuverlässige End-to-End-Übertragung zu gewährleisten, legen Sie die ExactlyOnce-Eigenschaft auf den Wert true fest Die Durable-Eigenschaft kann je nach Anforderungen auf true oder false festgelegt werden. (Die Standardeinstellung ist true.) Im Allgemeinen wird für die Durable-Eigenschaft der Wert true gewählt, wenn eine zuverlässige End-to-End-Übertragung gewünscht wird. Dies geht zwar auf Kosten der Leistung, Meldungen gehen bei dieser Einstellung jedoch nicht verloren, falls ein Warteschlangen-Manager einmal abstürzen sollte.

Verwendung von Transaktionen

Sie müssen Transaktionen verwenden, um eine zuverlässige End-to-End-Übertragung zu gewährleisten. ExactlyOnce-Zusicherungen gewährleisten nur, dass Nachrichten an die Zielwarteschlange gesendet werden. Um sicherzustellen, dass die Nachricht auch empfangen wird, verwenden Sie Transaktionen. Ohne Transaktionen geht bei einem Absturz des Diensts die gerade zugestellte Nachricht verloren, wobei sie jedoch an die Anwendung gesendet wird.

Verwendung von Warteschlangen für unzustellbare Nachrichten

Bei Verwendung von Warteschlangen für unzustellbare Nachrichten werden Sie benachrichtigt, falls eine Nachricht nicht in die Zielwarteschlange gestellt werden kann. Sie können die vom System bereitgestellte oder Ihre eigene Warteschlange für unzustellbare Nachrichten verwenden. Im Allgemeinen empfiehlt sich die Verwendung Ihrer eigenen Warteschlange für unzustellbare Nachrichten, da Sie die nicht zustellbaren Nachrichten einer Anwendung dann an eine bestimmte Warteschlange für unzustellbare Nachrichten senden können. Andernfalls werden alle nicht zustellbaren Nachrichten aller Anwendungen auf dem System in eine einzige Warteschlange gestellt. In diesem Fall muss dann jede Anwendung in der Warteschlange für unzustellbare Nachrichten nach den für sie relevanten unzustellbaren Nachrichten suchen. Gelegentlich können keine benutzerdefinierten Warteschlangen für unzustellbare Nachrichten verwendet werden, zum Beispiel bei MSMQ 3.0.

Es wird davon abgeraten, Warteschlangen für unzustellbare Nachrichten für eine zuverlässige End-to-End-Kommunikation zu deaktivieren.

Weitere Informationen finden Sie unter Verwenden von Warteschlangen für unzustellbare Nachrichten zur Handhabung von Nachrichtenübertragungsfehlern.

Handhabung beschädigter (nicht verarbeitbarer) Nachrichten

Die Handhabung beschädigter Nachrichten gibt Ihnen die Möglichkeit zur Wiederherstellung nach Fehlern bei der Nachrichtenverarbeitung.

Wenn Sie die Funktion für die Handhabung beschädigter Nachrichten verwenden, muss die ReceiveErrorHandling-Eigenschaft auf den richtigen Wert festgelegt werden. Bei Drop gehen die Daten verloren. Andererseits wird bei der Einstellung Fault auf dem Diensthost ein Fehler ausgegeben, wenn dieser auf eine beschädigte (nicht verarbeitbare) Nachricht stößt. Bei MSMQ 3.0 ist die Einstellung Fault die beste Option, um Datenverluste zu vermeiden und die beschädigte Nachricht zu eliminieren. Bei Verwendung von MSMQ 4.0 ist Move die empfohlene Vorgehensweise. Durch Move wird die kritische Nachricht aus der Warteschlange verschoben, sodass neue Nachrichten verarbeitet werden können. Die beschädigte Nachricht kann dann separat vom Dienst für beschädigte Nachrichten verarbeitet werden.

Weitere Informationen finden Sie unter Behandlung nicht verarbeitbarer Nachrichten.

Hoher Durchsatz

Verwenden Sie Folgendes, um bei einem einzelnen Endpunkt einen hohen Durchsatz zu erreichen:

Transaktive Batchverarbeitung: Bei der transaktiven Batchverarbeitung ist sichergestellt, dass viele Nachrichten in einer einzelnen Transaktion gelesen werden können. Hierdurch werden die Commits für Transaktionen optimiert und die Gesamtleistung verbessert. Nachteil der Batchverarbeitung: Tritt bei einer Nachricht im Batch ein Fehler auf, wird der gesamte Batch zurückgesetzt, und die Nachrichten müssen so lange einzeln verarbeitet werden, bis die Batchverarbeitung wieder sicher aufgenommen werden kann. Da beschädigte Nachrichten in der Regel nur selten auftreten, ist die Batchverarbeitung die bevorzugte Methode, die Systemleistung zu verbessern, insbesondere dann, wenn noch andere Ressourcen-Manager an der Transaktion beteiligt sind. Weitere Informationen finden Sie unter Batchverarbeitung von Nachrichten in einer Transaktion.
Parallelität: Parallelität erhöht den Durchsatz, verschärft jedoch auch den Wettstreit um freigegebene Ressourcen. Weitere Informationen finden Sie unter Parallelität.
Einschränkung: Schränken Sie die Anzahl der Nachrichten in der Verteilerpipeline ein, um eine optimale Leistung zu erzielen. Ein Beispiel hierfür finden Sie unter Drosselung.

Beachten Sie bei der Batchverarbeitung, dass Parallelität und Einschränkung zu simultanen Batches führen.

Um einen höheren Durchsatz und eine bessere Verfügbarkeit zu erreichen, können Sie auch eine WCF-Dienstefarm verwenden, die aus der Warteschlange liest. Hierfür müssen diese Dienste denselben Vertrag auf demselben Endpunkt verfügbar machen. Eine Dienstefarm ist am besten bei Anwendungen geeignet, die sehr viele Nachrichten produzieren, da dann mehrere Dienste aus derselben Warteschlange lesen können.

Beachten Sie bei der Verwendung von Farmen, dass MSMQ 3.0 keine remote durchgeführten Lesevorgänge unterstützt. MSMQ 4.0 dagegen unterstützt remote durchgeführte Lesevorgänge.

Weitere Informationen finden Sie unter Batchverarbeitung von Nachrichten in einer Transaktion.

Warteschlangen und Arbeitseinheitssemantik

Gelegentlich können die Nachrichten in einer Gruppe von Nachrichten in der Warteschlange miteinander verwandt sein, das heißt, dass die Reihenfolge dieser Nachrichten von Bedeutung ist. In diesen Szenarien sollte die Gruppe der verwandten Nachrichten als Einheit verarbeitet werden, das heißt, es werden entweder alle oder keine Nachrichten verarbeitet. Verwenden Sie zur Implementierung dieses Verhaltens Sitzungen mit Warteschlangen.

Weitere Informationen finden Sie unter Gruppieren von Nachrichten in der Warteschlange einer Sitzung.

Korrelieren von Anforderung-Antwort-Nachrichten

Warteschlangen sind zwar im Allgemeinen unidirektional, es kann jedoch vorkommen, dass Sie eine empfangene Antwort zu einer zuvor gesendeten Anforderung in Bezug setzen möchten. Falls eine solche Zuordnung erforderlich ist, sollten Sie, wenn möglich, mit der Nachricht Ihren eigenen SOAP-Nachrichtenheader mit Zuordnungsinformationen verwenden. In der Regel wird dieser Header vom Sender an die Nachricht angehängt. Beim Empfänger wird der Nachrichtenheader mit den Zuordnungsinformationen dann während der Verarbeitung der Nachricht an die Antwortnachricht, die als neue Nachricht an eine Antwortwarteschlange gesendet wird, angehängt, sodass die Antwortnachricht beim Sender der Anforderungsnachricht zugeordnet werden kann.

Integrieren von Nicht-WCF-Anwendungen

Verwenden Sie MsmqIntegrationBinding, um WCF-Dienste oder -Clients mit Nicht-WCF-Diensten oder -Clients zu integrieren. Die Nicht-WCF-Anwendung kann eine MSMQ-Anwendung sein, die mit System.Messaging, COM+, Visual Basic oder C++ geschrieben wurde.

Beachten Sie bei der Verwendung von MsmqIntegrationBinding folgende Punkte:

WCF-Nachrichtentexte sind nicht dasselbe wie MSMQ-Nachrichtentexte. Wenn Sie eine WCF-Nachricht mithilfe einer Bindung in der Warteschlange senden, wird der WCF-Nachrichtentext in eine MSMQ-Nachricht eingefügt. In der MSMQ-Infrastruktur wird diese Zusatzinformation jedoch nicht wahrgenommen, MSMQ sieht lediglich die MSMQ-Nachricht.
MsmqIntegrationBinding unterstützt die gängigen Serialisierungstypen. Je nach Serialisierungstyp nimmt der Texttyp der generischen Nachricht - MsmqMessage<T> - unterschiedliche Typparameter an. So ist bei ByteArray zum Beispiel MsmqMessage\<byte[]>Stream und bei MsmqMessage<Stream> der Parameter erforderlich.
Bei der XML-Serialisierung können Sie mit dem KnownTypes-Attribut des <behavior>-Elements den bekannten Typ angeben, mit dem dann wiederum ermittelt wird, wie die XML-Nachricht zu deserialisieren ist.