Overzicht van wachtrijen
In deze sectie worden de algemene en kernconcepten voor communicatie in de wachtrij geïntroduceerd. In volgende secties vindt u meer informatie over hoe de hier beschreven wachtrijconcepten worden gemanifesteerd in Windows Communication Foundation (WCF).
Basisconcepten voor wachtrijen
Bij het ontwerpen van een gedistribueerde toepassing is het belangrijk om het juiste transport te kiezen voor communicatie tussen services en clients. Verschillende factoren zijn van invloed op het type transport dat moet worden gebruikt. Een belangrijke factor: isolatie tussen de service, de client en het transport bepaalt het gebruik van een transport in de wachtrij of een direct transport, zoals TCP of HTTP. Vanwege de aard van directe transporten, zoals TCP en HTTP, stopt de communicatie helemaal als de service of de client niet meer functioneert of als het netwerk uitvalt. De service, de client en het netwerk moeten tegelijkertijd worden uitgevoerd om de toepassing te laten werken. Transporten in wachtrij bieden isolatie, wat betekent dat als de service of client mislukt of als de communicatiekoppelingen tussen deze verbindingen mislukken, de client en service kunnen blijven functioneren.
Wachtrijen bieden zelfs betrouwbare communicatie met storingen in de communicerende partijen of het netwerk. Wachtrijen leggen berichten vast en leveren berichten die worden uitgewisseld tussen de communicerende partijen. Wachtrijen worden doorgaans ondersteund door een winkel, die vluchtig of duurzaam kan zijn. Wachtrijen slaan berichten van een client op namens een service en sturen deze berichten later door naar de service. De indirectiewachtrijen bieden een gegarandeerde isolatie van fouten door beide partijen, waardoor het het voorkeurscommunicatiemechanisme is voor systemen met hoge beschikbaarheid en niet-verbonden services. De indirectie wordt geleverd met de kosten van hoge latentie. Latentie is de tijdsvertraging tussen de tijd die de client verzendt en het tijdstip waarop de service het ontvangt. Dit betekent dat wanneer een bericht is verzonden, u niet weet wanneer dat bericht kan worden verwerkt. De meeste toepassingen in de wachtrij hebben te maken met hoge latentie. In de volgende afbeelding ziet u een conceptueel model van communicatie in de wachtrij.
Conceptueel model voor communicatie in wachtrij
In werkelijkheid is de wachtrij een gedistribueerd concept. Als zodanig kunnen ze lokaal zijn voor een partij of extern voor beide partijen. Normaal gesproken is de wachtrij lokaal voor de service. In deze configuratie kan de client niet afhankelijk zijn van de verbinding met de externe wachtrij om voortdurend beschikbaar te zijn. Op dezelfde manier moet de wachtrij beschikbaar zijn, onafhankelijk van de beschikbaarheid van de service die uit de wachtrij wordt gelezen. Een wachtrijbeheerder beheert een verzameling wachtrijen. Het is verantwoordelijk voor het accepteren van berichten die zijn verzonden naar de wachtrijen van andere wachtrijbeheerders. Het is ook verantwoordelijk voor het beheren van connectiviteit met externe wachtrijen en het overdragen van berichten naar die externe wachtrijen. Om de beschikbaarheid van wachtrijen te garanderen ondanks fouten in client- of servicetoepassingen, wordt wachtrijbeheer doorgaans uitgevoerd als een externe service.
Wanneer een client een bericht naar een wachtrij verzendt, wordt het bericht naar de doelwachtrij verzonden. Dit is de wachtrij die wordt beheerd door de wachtrijbeheerder van de service. De wachtrijbeheerder op de client verzendt het bericht naar een overdrachtswachtrij (of uitgaande) wachtrij. De overdrachtswachtrij is een wachtrij in de clientwachtrijbeheerder waarin berichten voor verzending naar de doelwachtrij worden opgeslagen. De wachtrijbeheerder zoekt vervolgens een pad naar de wachtrijbeheerder die eigenaar is van de doelwachtrij en brengt het bericht naar het. Om betrouwbare communicatie te garanderen, implementeren de wachtrijbeheerders een betrouwbaar overdrachtsprotocol om gegevensverlies te voorkomen. De doelwachtrijbeheerder accepteert berichten die zijn geadresseerd aan de doelwachtrijen die eigenaar zijn en slaat de berichten op. De service doet aanvragen om te lezen uit de doelwachtrij, waarna de wachtrijbeheerder het bericht vervolgens aan de doeltoepassing levert. In de volgende afbeelding ziet u de communicatie tussen de vier partijen.
Communicatie in wachtrij in een typisch implementatiescenario
De wachtrijbeheerder biedt dus de vereiste isolatie, zodat de afzender en ontvanger onafhankelijk kunnen mislukken zonder dat dit van invloed is op de werkelijke communicatie. Het voordeel van extra indirectie die wachtrijen bieden, maakt het ook mogelijk dat meerdere toepassingsexemplaren uit dezelfde wachtrij kunnen lezen, zodat landbouwwerk tussen de knooppunten een hogere doorvoer bereikt. Daarom is het niet ongebruikelijk dat wachtrijen worden gebruikt om hogere schaal- en doorvoervereisten te bereiken.
Wachtrijen en transacties
Met transacties kunt u een set bewerkingen groeperen, zodat alle bewerkingen mislukken als één bewerking mislukt. Een voorbeeld van het gebruik van transacties is wanneer een persoon een ATM gebruikt om $ 1000 over te dragen van hun spaarrekening naar hun bankrekening. Dit houdt de volgende bewerkingen in:
1000 dollar uit de spaarrekening intrekken.
$ 1.000 in de bankrekening storten.
Als de eerste bewerking slaagt en $ 1.000 wordt ingetrokken van de spaarrekening, maar de tweede bewerking mislukt, gaat de $ 1000 verloren omdat deze al van de spaarrekening is ingetrokken. Als één bewerking mislukt, moeten beide bewerkingen mislukken om de accounts in een geldige status te houden.
In transactionele berichten kunnen berichten naar de wachtrij worden verzonden en ontvangen uit de wachtrij onder een transactie. Dus als een bericht wordt verzonden in een transactie en de transactie wordt teruggedraaid, is het resultaat alsof het bericht nooit naar de wachtrij is verzonden. Als een bericht in een transactie wordt ontvangen en de transactie wordt teruggedraaid, is het resultaat alsof het bericht nog nooit is ontvangen. Het bericht blijft in de wachtrij staan om te worden gelezen.
Vanwege een hoge latentie weet u niet hoe lang het duurt om de doelwachtrij te bereiken en weet u ook niet hoe lang het duurt voordat de service het bericht verwerkt. Daarom wilt u niet één transactie gebruiken om het bericht te verzenden, het bericht te ontvangen en vervolgens het bericht te verwerken. Hiermee wordt een transactie gemaakt die niet is vastgelegd voor een onbepaalde tijdsduur. Wanneer een client en service communiceren via een wachtrij met behulp van een transactie, zijn er twee transacties betrokken: één op de client en één op de service. In de volgende afbeelding ziet u de transactiegrenzen in typische communicatie in de wachtrij.
Communicatie in wachtrij met afzonderlijke transacties voor vastleggen en leveren
De clienttransactie verwerkt en verzendt het bericht. Wanneer de transactie is doorgevoerd, bevindt het bericht zich in de transmissiewachtrij. In de service leest de transactie het bericht uit de doelwachtrij, verwerkt het bericht en voert de transactie vervolgens door. Als er een fout optreedt tijdens de verwerking, wordt het bericht teruggedraaid en in de doelwachtrij geplaatst.
Asynchrone communicatie met behulp van wachtrijen
Wachtrijen bieden een asynchroon communicatiemiddel. Toepassingen die berichten verzenden met behulp van wachtrijen, kunnen niet wachten totdat het bericht is ontvangen en verwerkt door de ontvanger vanwege een hoge latentie die is geïntroduceerd door de wachtrijbeheerder. Berichten kunnen veel langer in de wachtrij blijven staan dan de beoogde toepassing. Om dit te voorkomen, kan de toepassing een Time-To-Live-waarde voor het bericht opgeven. Deze waarde geeft aan hoe lang het bericht in de overdrachtswachtrij moet blijven. Als deze tijdwaarde wordt overschreden en het bericht nog steeds niet naar de doelwachtrij is verzonden, kan het bericht worden overgebracht naar een wachtrij met onbestelbare berichten.
Wanneer de afzender een bericht verzendt, impliceert de retour van de verzendbewerking dat het bericht alleen naar de verzendwachtrij van de afzender is verzonden. Als er een fout optreedt bij het ophalen van het bericht naar de doelwachtrij, kan de verzendende toepassing er niet onmiddellijk van op de hoogte zijn. Als u dergelijke fouten wilt noteren, wordt het mislukte bericht overgebracht naar een wachtrij met onbestelbare berichten.
Elke fout, zoals een bericht dat de doelwachtrij of time-to-live verloopt, moet afzonderlijk worden verwerkt. Het is daarom niet ongebruikelijk dat toepassingen in de wachtrij twee sets logica schrijven:
De normale client- en servicelogica voor het verzenden en ontvangen van berichten.
Compensatielogica voor het verwerken van berichten van de mislukte verzending of levering.
In de volgende secties worden deze concepten besproken.
Dead-Letter Queue Programming
Wachtrijen met dode letters bevatten om verschillende redenen berichten die de doelwachtrij niet kunnen bereiken. De redenen kunnen variëren van verlopen berichten tot connectiviteitsproblemen waardoor de overdracht van het bericht naar de doelwachtrij wordt voorkomen.
Normaal gesproken kan een toepassing berichten lezen uit een wachtrij met dode letters in het systeem, bepalen wat er mis is gegaan en de juiste actie ondernemen, zoals het corrigeren van de fouten en het opnieuw verzenden van het bericht of het noteren ervan.
Programmering van berichtenwachtrijen vergiftigen
Nadat een bericht naar de doelwachtrij is verzonden, kan de service het bericht herhaaldelijk niet verwerken. Een toepassing die bijvoorbeeld een bericht uit de wachtrij leest onder een transactie en een database bijwerkt, kan de verbinding met de database tijdelijk verbreken. In dit geval wordt de transactie teruggedraaid, wordt er een nieuwe transactie gemaakt en wordt het bericht opnieuw gelezen vanuit de wachtrij. Een tweede poging kan slagen of mislukken. In sommige gevallen, afhankelijk van de oorzaak van de fout, kan het bericht herhaaldelijk mislukken bij de bezorging van de toepassing. In dit geval wordt het bericht beschouwd als 'gif'. Dergelijke berichten worden verplaatst naar een gifwachtrij die kan worden gelezen door een gifverwerkingstoepassing.