Metodtips för kommunikation i kö

Artikel
03/30/2023

Det här avsnittet innehåller rekommenderade metoder för köad kommunikation i Windows Communication Foundation (WCF). I följande avsnitt beskrivs rekommenderade metoder ur ett scenarioperspektiv.

Snabba meddelanden med bästa ansträngning i kö

För scenarier som kräver separation som köade meddelanden ger och snabba, högpresterande meddelanden med bästa möjliga garantier använder du en icke-transaktionell kö och anger ExactlyOnce egenskapen till false.

Dessutom kan du välja att inte ådra dig kostnaden för diskskrivningar genom att ange Durable egenskapen till false.

Säkerheten påverkar prestandan. Mer information finns i Prestandaöverväganden.

Tillförlitliga köade meddelanden från slutpunkt till slutpunkt

I följande avsnitt beskrivs rekommenderade metoder för scenarier som kräver tillförlitliga meddelanden från slutpunkt till slutpunkt.

Grundläggande tillförlitlig överföring

För tillförlitlighet från slutpunkt till slutpunkt anger du ExactlyOnce egenskapen till true för att säkerställa överföring. Egenskapen Durable kan anges till true eller false beroende på dina krav (standardvärdet är true). I allmänhet är egenskapen Durable inställd true på som en del av tillförlitligheten från slutpunkt till slutpunkt. Kompromissen är en prestandakostnad, men gör meddelandet beständigt så att meddelandet inte går förlorat om en köhanterare kraschar.

Användning av transaktioner

Du måste använda transaktioner för att säkerställa tillförlitlighet från slutpunkt till slutpunkt. ExactlyOnce säkerställer endast att meddelanden levereras till målkön. Använd transaktioner för att säkerställa att meddelandet tas emot. Om tjänsten kraschar utan transaktioner förlorar du meddelandet som levereras men faktiskt levereras till programmet.

Användning av köer med obeställbara bokstäver

Köer med obeställbara meddelanden ser till att du meddelas om ett meddelande inte kan levereras till målkön. Du kan använda den systembaserade kön med obeställbara meddelanden eller en anpassad kö med obeställbara meddelanden. I allmänhet är det bäst att använda en anpassad kö med obeställbara meddelanden eftersom du kan skicka meddelanden med obeställbara meddelanden från ett program till en enda kö med obeställbara meddelanden. Annars levereras alla meddelanden med obeställbara meddelanden för alla program som körs i systemet till en enda kö. Varje program måste sedan söka igenom kön med obeställbara meddelanden för att hitta de meddelanden med obeställbara meddelanden som är relevanta för programmet. Ibland är det inte möjligt att använda en anpassad kö med obeställbara meddelanden, till exempel när du använder MSMQ 3.0.

Det rekommenderas inte att stänga av köer med obeställbara meddelanden för tillförlitlig kommunikation från slutpunkt till slutpunkt.

Mer information finns i Använda köer med obeställbara meddelanden för att hantera fel vid meddelandeöverföring.

Användning av giftmeddelandehantering

Hantering av giftmeddelanden ger möjlighet att återställa från misslyckandet med att bearbeta meddelanden.

När du använder funktionen för hantering av giftmeddelanden kontrollerar du att ReceiveErrorHandling egenskapen är inställd på rätt värde. Om du ställer in den på innebär det att Drop data går förlorade. Å andra sidan felas tjänstvärden när ett giftmeddelande identifieras om det ställs in Fault på fel. Att använda MSMQ 3.0 Fault är det bästa alternativet för att undvika dataförlust och flytta giftmeddelandet ur vägen. Att använda MSMQ 4.0 Move är den rekommenderade metoden. Move flyttar ett förgiftat meddelande från kön så att tjänsten kan fortsätta att bearbeta nya meddelanden. Tjänsten poison-message kan sedan bearbeta giftmeddelandet separat.

Mer information finns i Hantering av giftmeddelanden.

Uppnå högt dataflöde

Använd följande för att uppnå högt dataflöde på en enda slutpunkt:

Transacted batching. Transacted batching säkerställer att många meddelanden kan läsas i en enda transaktion. Detta optimerar transaktionsincheckningar, vilket ökar den övergripande prestandan. Kostnaden för batchbearbetning är att om ett fel inträffar i ett enda meddelande i en batch, återställs hela batchen och meddelandena måste bearbetas en i taget tills det är säkert att batcha igen. I de flesta fall är giftmeddelanden sällsynta, så batchbearbetning är det bästa sättet att öka systemets prestanda, särskilt när du har andra resurshanterare som deltar i transaktionen. Mer information finns i Batching Messages in a Transaction (Batching Messages in a Transaction).
Samtidighet. Samtidighet ökar dataflödet, men samtidighet påverkar också konkurrensen om delade resurser. Mer information finns i Samtidighet.
Begränsning. För optimal prestanda begränsar du antalet meddelanden i dispatcher-pipelinen. Ett exempel på hur du gör detta finns i Begränsning.

När du använder batchbearbetning bör du vara medveten om att samtidighet och begränsning översätts till samtidiga batchar.

Om du vill uppnå högre dataflöde och tillgänglighet använder du en servergrupp med WCF-tjänster som läser från kön. Detta kräver att alla dessa tjänster exponerar samma kontrakt på samma slutpunkt. Servergruppsmetoden fungerar bäst för program som har hög produktionsfrekvens för meddelanden eftersom den gör det möjligt för ett antal tjänster att läsa från samma kö.

När du använder servergrupper bör du vara medveten om att MSMQ 3.0 inte stöder fjärrstyrda läsningar. MSMQ 4.0 stöder fjärrstyrda läsningar.

Mer information finns i Batching Messages in a Transaction (Batching Messages in a Transaction).

Köer med arbetsenhetssemantik

I vissa scenarier kan en grupp meddelanden i en kö vara relaterade och därför är ordningen på dessa meddelanden betydande. I sådana scenarier bearbetar du en grupp relaterade meddelanden tillsammans som en enda enhet: antingen bearbetas alla meddelanden korrekt eller så är inga. Om du vill implementera sådant beteende använder du sessioner med köer.

Mer information finns i Gruppera köade meddelanden i en session.

Korrelera begärandesvarsmeddelanden

Köer är vanligtvis enkelriktade, men i vissa scenarier kanske du vill korrelera ett svar som tagits emot till en begäran som skickades tidigare. Om du behöver en sådan korrelation rekommenderar vi att du använder din egen SOAP-meddelanderubrik som innehåller korrelationsinformation med meddelandet. Normalt bifogar avsändaren det här huvudet med meddelandet, och mottagaren bifogar när meddelandet bearbetas och svarar med ett nytt meddelande i en svarskö avsändarens meddelandehuvud som innehåller korrelationsinformationen så att avsändaren kan identifiera svarsmeddelandet med begärandemeddelandet.

Integrera med icke-WCF-program

Använd MsmqIntegrationBinding när du integrerar WCF-tjänster eller -klienter med icke-WCF-tjänster eller klienter. Det icke-WCF-programmet kan vara ett MSMQ-program som skrivits med System.Messaging, COM+, Visual Basic eller C++.

När du använder MsmqIntegrationBindingbör du vara medveten om följande:

En WCF-meddelandetext är inte samma som en MSMQ-meddelandetext. När du skickar ett WCF-meddelande med en köbindning placeras WCF-meddelandetexten i ett MSMQ-meddelande. MSMQ-infrastrukturen är omedveten om den här extra informationen. det ser bara MSMQ-meddelandet.
MsmqIntegrationBinding stöder populära serialiseringstyper. Baserat på serialiseringstypen tar brödtexttypen för det allmänna meddelandet, MsmqMessage<T>, olika typparametrar. Till exempel ByteArray kräver MsmqMessage\<byte[]> och Stream kräver MsmqMessage<Stream>.
Med XML-serialisering kan du ange den kända typen med hjälp av KnownTypes attributet för <beteendeelementet> som sedan används för att avgöra hur XML-meddelandet ska deserialiseras.

Dela via