Aanbevolen procedures voor communicatie in wachtrij

Artikel
03/02/2024

Dit onderwerp bevat aanbevolen procedures voor communicatie in de wachtrij in WCF (Windows Communication Foundation). In de volgende secties worden aanbevolen procedures besproken vanuit het perspectief van een scenario.

Snelle berichten in wachtrij met best effort

Gebruik een niet-transactionele wachtrij en stel de ExactlyOnce eigenschap falsein op scenario's waarvoor scheiding in de wachtrij is vereist en snelle, krachtige berichten met best effort-garanties.

Bovendien kunt u ervoor kiezen om de kosten van schijfschrijfbewerkingen niet te maken door de Durable eigenschap in te stellen op false.

Beveiliging heeft gevolgen voor de prestaties. Zie Prestatieoverwegingen voor meer informatie.

Betrouwbare end-to-end-berichten in wachtrij

In de volgende secties worden aanbevolen procedures beschreven voor scenario's waarvoor end-to-end betrouwbare berichten zijn vereist.

Eenvoudige betrouwbare overdracht

Voor end-to-end betrouwbaarheid stelt u de ExactlyOnce eigenschap in om true de overdracht te garanderen. De Durable eigenschap kan worden ingesteld op true of false afhankelijk van uw vereisten (de standaardinstelling is true). Over het algemeen wordt de Durable eigenschap ingesteld true als onderdeel van end-to-end betrouwbaarheid. Het compromis is een prestatiekosten, maar maakt het bericht duurzaam, zodat het bericht niet verloren gaat als een wachtrijbeheerder vastloopt.

Gebruik van transacties

U moet transacties gebruiken om end-to-end betrouwbaarheid te garanderen. ExactlyOnce garanties zorgen er alleen voor dat berichten worden bezorgd in de doelwachtrij. Gebruik transacties om ervoor te zorgen dat het bericht wordt ontvangen. Als de service vastloopt, verliest u zonder transacties het bericht dat wordt bezorgd, maar daadwerkelijk aan de toepassing wordt geleverd.

Gebruik van wachtrijen met dode letters

Wachtrijen met dode letters zorgen ervoor dat u een melding ontvangt als een bericht niet in de doelwachtrij wordt bezorgd. U kunt de door het systeem geleverde wachtrij met dode letters of een aangepaste wachtrij met dode letters gebruiken. Over het algemeen is het gebruik van een aangepaste wachtrij met dode letters het beste omdat u hiermee berichten van een toepassing kunt verzenden naar één wachtrij met dode letters. Anders worden alle onbestelbare berichten die plaatsvinden voor alle toepassingen die op het systeem worden uitgevoerd, bezorgd in één wachtrij. Elke toepassing moet vervolgens zoeken in de wachtrij met dode letters om de berichten met dode letters te vinden die relevant zijn voor die toepassing. Soms is het gebruik van een aangepaste wachtrij met dode letters niet haalbaar, zoals bij het gebruik van MSMQ 3.0.

Het wordt afgeraden om wachtrijen met dode letters uit te schakelen voor end-to-end betrouwbare communicatie.

Zie Wachtrijen met onbestelbare berichten gebruiken voor het afhandelen van fouten bij berichtoverdracht voor meer informatie.

Gebruik van afhandeling van gifberichten

Verwerking van gifberichten biedt de mogelijkheid om te herstellen van het mislukken van het verwerken van berichten.

Wanneer u de functie voor het verwerken van gifberichten gebruikt, moet u ervoor zorgen dat de ReceiveErrorHandling eigenschap is ingesteld op de juiste waarde. Dit instellen betekent Drop dat de gegevens verloren gaan. Aan de andere kant stelt u deze in op Fault fouten in de servicehost wanneer een gifbericht wordt gedetecteerd. Het gebruik van MSMQ 3.0 Fault is de beste optie om gegevensverlies te voorkomen en het gifbericht uit de weg te verplaatsen. Het gebruik van MSMQ 4.0 Move is de aanbevolen aanpak. Move verplaatst een vergiftigd bericht uit de wachtrij, zodat de service nieuwe berichten kan blijven verwerken. De gifberichtservice kan het gifbericht vervolgens afzonderlijk verwerken.

Zie Afhandeling van gifberichten voor meer informatie.

Hoge doorvoer bereiken

Als u een hoge doorvoer op één eindpunt wilt bereiken, gebruikt u het volgende:

Getransacteerde batchverwerking. Transacted batching zorgt ervoor dat veel berichten in één transactie kunnen worden gelezen. Hierdoor worden transactiedoorvoeringen geoptimaliseerd, waardoor de algehele prestaties toenemen. De kosten van batchverwerking zijn dat als er een fout optreedt in één bericht in een batch, de hele batch wordt teruggedraaid en de berichten één voor één moeten worden verwerkt totdat de batch opnieuw veilig is. In de meeste gevallen zijn gifberichten zeldzaam, dus batchverwerking is de voorkeurswijze om de systeemprestaties te verhogen, met name wanneer u andere resourcemanagers hebt die deelnemen aan de transactie. Zie Berichten in batches in een transactie voor meer informatie.
Gelijktijdigheid. Gelijktijdigheid verhoogt de doorvoer, maar gelijktijdigheid is ook van invloed op conflicten met gedeelde resources. Zie Gelijktijdigheid voor meer informatie.
Aanvraagbeperking. Beperk het aantal berichten in de dispatcherpijplijn voor optimale prestaties. Zie Beperking voor een voorbeeld van hoe u dit doet.

Wanneer u batchverwerking gebruikt, moet u er rekening mee houden dat gelijktijdigheid en beperking worden omgezet in gelijktijdige batches.

Als u een hogere doorvoer en beschikbaarheid wilt bereiken, gebruikt u een farm met WCF-services die uit de wachtrij worden gelezen. Dit vereist dat al deze services hetzelfde contract beschikbaar maken op hetzelfde eindpunt. De farmbenadering werkt het beste voor toepassingen met een hoge productiesnelheid van berichten, omdat hiermee een aantal services kan worden gelezen uit dezelfde wachtrij.

Wanneer u farms gebruikt, moet u er rekening mee houden dat MSMQ 3.0 geen externe leesbewerkingen ondersteunt. MSMQ 4.0 ondersteunt externe leesbewerkingen.

Zie Berichten in batches in een transactie voor meer informatie.

Wachtrijen met Semantiek voor werkeenheden

In sommige scenario's kan een groep berichten in een wachtrij gerelateerd zijn en daarom is de volgorde van deze berichten aanzienlijk. In dergelijke scenario's verwerkt u een groep gerelateerde berichten als één eenheid: alle berichten worden verwerkt of niet. Gebruik sessies met wachtrijen om dit gedrag te implementeren.

Zie Berichten in een wachtrij groeperen in een sessie voor meer informatie.

Correleren van aanvraag-antwoordberichten

Hoewel wachtrijen doorgaans in één richting zijn, wilt u in sommige scenario's mogelijk een antwoord correleren dat is ontvangen van een aanvraag die eerder is verzonden. Als u een dergelijke correlatie nodig hebt, wordt u aangeraden uw eigen SOAP-berichtkop toe te passen die correlatiegegevens met het bericht bevat. Normaal gesproken voegt de afzender deze koptekst toe aan het bericht, en de ontvanger, bij het verwerken van het bericht en het beantwoorden met een nieuw bericht in een antwoordwachtrij, de berichtkop van de afzender die de correlatie-informatie bevat, zodat de afzender het antwoordbericht kan identificeren met het aanvraagbericht.

Integreren met niet-WCF-toepassingen

Gebruik MsmqIntegrationBinding deze functie bij het integreren van WCF-services of -clients met niet-WCF-services of -clients. De niet-WCF-toepassing kan een MSMQ-toepassing zijn die is geschreven met System.Messaging, COM+, Visual Basic of C++.

Houd rekening met het volgende wanneer u dit gebruikt MsmqIntegrationBinding:

De hoofdtekst van een WCF-bericht is niet hetzelfde als de hoofdtekst van een MSMQ-bericht. Wanneer u een WCF-bericht verzendt met behulp van een binding in de wachtrij, wordt de hoofdtekst van het WCF-bericht in een MSMQ-bericht geplaatst. De MSMQ-infrastructuur is vergeten aan deze extra informatie; alleen het MSMQ-bericht wordt weergegeven.
MsmqIntegrationBinding ondersteunt populaire serialisatietypen. Op basis van het serialisatietype gebruikt het hoofdteksttype van het algemene bericht MsmqMessage<T>verschillende typeparameters. Vereist en vereist MsmqMessage<Stream>bijvoorbeeld MsmqMessage\<byte[]>ByteArray Stream.
Met XML-serialisatie kunt u het bekende type opgeven met behulp van het KnownTypes kenmerk voor het <gedragselement> dat vervolgens wordt gebruikt om te bepalen hoe het XML-bericht moet worden gedeserialiseerd.

Delen via