Freigeben über

Bewährte Methoden für die Kommunikation in der Warteschlange

Dieses Thema enthält empfohlene Methoden für die Kommunikation in der Warteschlange in Windows Communication Foundation (WCF). In den folgenden Abschnitten werden die empfohlenen Methoden aus Szenarioperspektive erläutert.

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 Kosten für Datenträgerschreibvorgänge vermeiden, indem Sie die Durable-Eigenschaft auf false festlegen.

Die Sicherheit hat Auswirkungen auf die Leistung. Weitere Informationen finden Sie unter Leistungsüberlegungen.

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

In den folgenden Abschnitten werden empfohlene Methoden für Szenarien beschrieben, für die end-to-End zuverlässige Nachrichten erforderlich sind.

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 auf true oder false je nach Ihren Anforderungen festgelegt werden (der Standardwert ist true). Im Allgemeinen wird die Durable Eigenschaft auf true als Teil der End-to-End-Zuverlässigkeit festgelegt. 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 die End-to-End-Zuverlässigkeit sicherzustellen. ExactlyOnce Zusicherungen stellen nur sicher, dass Nachrichten an die Zielwarteschlange übermittelt werden. Verwenden Sie Transaktionen, um sicherzustellen, dass die Nachricht empfangen wird. Ohne Transaktionen verlieren Sie, wenn der Dienst abstürzt, die Nachricht, die momentan übermittelt wird, aber eigentlich an die Anwendung gesendet werden soll.

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 Dead-Letter-Queue oder eine benutzerdefinierte Dead-Letter-Queue 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 Dead-Letter Warteschlangen zur Behandlung 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.

Stellen Sie bei Verwendung des Features für die Behandlung von Giftnachrichten sicher, dass die ReceiveErrorHandling Eigenschaft auf den entsprechenden Wert festgelegt ist. Das Festlegen auf Drop bedeutet, dass die Daten verloren gehen. Andererseits wird bei der Einstellung Fault auf dem Diensthost ein Fehler ausgegeben, wenn dieser auf eine beschädigte (nicht verarbeitbare) Nachricht stößt. Die Verwendung von MSMQ 3.0 ist die beste Option, Fault um Datenverluste zu vermeiden und die Giftnachricht wegzuschieben. Die Verwendung von MSMQ 4.0 Move ist der empfohlene Ansatz. Move verschiebt eine vergiftete Nachricht aus der Warteschlange, damit der Dienst weiterhin neue Nachrichten verarbeiten kann. Der Giftnachrichtendienst kann dann die Giftnachricht separat verarbeiten.

Weitere Informationen finden Sie unter Behandlung nicht verarbeitbarer Nachrichten.

Erreichen des hohen Durchsatzes

Verwenden Sie folgendes, um einen hohen Durchsatz für einen einzelnen Endpunkt zu erzielen:

  • Transaktive Batchverarbeitung: Transacted Batching stellt sicher, dass viele Nachrichten in einer einzelnen Transaktion gelesen werden können. Hierdurch werden die Commits für Transaktionen optimiert und die Gesamtleistung verbessert. Die Kosten für die Batchverarbeitung sind: Wenn ein Fehler in einer einzelnen Nachricht in einem Batch auftritt, wird der gesamte Batch zurückgesetzt, und die Nachrichten müssen jeweils einzeln verarbeitet werden, bis es sicher ist, den Batch erneut zu stapeln. In den meisten Fällen sind Giftnachrichten selten, daher ist die Batchverarbeitung die bevorzugte Möglichkeit, die Systemleistung zu erhöhen, insbesondere wenn Sie andere Ressourcenmanager haben, die an der Transaktion teilnehmen. Weitere Informationen finden Sie unter "Nachrichtenbündelung in einer Transaktion".

  • Parallelität. Die Parallelität erhöht den Durchsatz, aber die Parallelität wirkt sich auch auf die Konkurrenz um freigegebene Ressourcen aus. Weitere Informationen finden Sie unter Parallelität.

  • Drosselung. Um eine optimale Leistung zu erzielen, drosseln Sie die Anzahl der Nachrichten in der Dispatcherpipeline. Ein Beispiel dafür finden Sie unter Drosselung.

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

Verwenden Sie eine Farm von WCF-Diensten, die aus der Warteschlange gelesen werden, um einen höheren Durchsatz und eine höhere Verfügbarkeit zu erzielen. Dies erfordert, dass alle diese Dienste denselben Vertrag auf demselben Endpunkt verfügbar machen. Der Farmansatz eignet sich am besten für Anwendungen mit hohen Nachrichtenproduktionsraten, da er es mehreren Diensten ermöglicht, alle aus derselben Warteschlange zu lesen.

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 "Nachrichtenbündelung in einer Transaktion".

Warteschlangen und Arbeitseinheitssemantik

In einigen Szenarien kann eine Gruppe von Nachrichten in einer Warteschlange verwandt sein und daher die Reihenfolge dieser Nachrichten erheblich sein. Verarbeiten Sie in solchen Szenarien eine Gruppe verwandter Nachrichten als einzelne Einheit: Entweder werden alle Nachrichten erfolgreich verarbeitet oder keine. Um dieses Verhalten zu implementieren, verwenden Sie Sitzungen mit Warteschlangen.

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

Korrelieren von Anforderung-Antwort-Nachrichten

Obwohl Warteschlangen normalerweise in eine Richtung verlaufen, möchten Sie in manchen Szenarien eine erhaltene Antwort mit einer zuvor gesendeten Anfrage verknüpfen. Wenn Sie eine solche Korrelation benötigen, wird empfohlen, ihren eigenen SOAP-Nachrichtenkopf anzuwenden, der Korrelationsinformationen mit der Nachricht enthält. 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.

Integration in Nicht-WCF-Anwendungen

Verwenden Sie MsmqIntegrationBinding beim Integrieren von WCF-Diensten oder -Clients mit Nicht-WCF-Diensten oder -Clients. 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 MsmqIntegrationBindingFolgendes:

  • Ein WCF-Nachrichtentext ist nicht identisch mit einem MSMQ-Nachrichtentext. Beim Senden einer WCF-Nachricht mithilfe einer Warteschlangenbindung wird der WCF-Nachrichtentext in eine MSMQ-Nachricht eingefügt. Die MSMQ-Infrastruktur nimmt diese zusätzlichen Informationen nicht wahr; sie nimmt nur die MSMQ-Nachricht wahr.

  • MsmqIntegrationBinding unterstützt beliebte Serialisierungstypen. Basierend auf dem Serialisierungstyp verwendet der Textkörper der generischen Nachricht MsmqMessage<T>verschiedene Typparameter. Zum Beispiel ByteArray erfordert MsmqMessage\<byte[]> und Stream erfordert MsmqMessage<Stream>.

  • Mit der XML-Serialisierung können Sie den bekannten Typ mithilfe des Attributs für das KnownTypes<Verhaltenselement> angeben, das dann verwendet wird, um zu bestimmen, wie die XML-Nachricht deserialisiert wird.

Siehe auch