Service Bus-wachtrijen, -onderwerpen en -abonnementen

Azure Service Bus biedt ondersteuning voor een set op berichten gebaseerde middlewaretechnologieën in de cloud, waaronder betrouwbare berichten in de wachtrij en duurzame berichten voor publiceren/abonneren. Deze brokered messaging-mogelijkheden kunnen worden zien als losgekoppelde berichtenfuncties die ondersteuning bieden voor publiceren/abonneren, tijdelijke ontkoppeling en taakverdelingsscenario's met behulp van de Service Bus messaging-workload. Losgekoppelde communicatie heeft veel voordelen. Clients en servers kunnen bijvoorbeeld verbinding maken wanneer dat nodig is en hun bewerkingen op een asynchrone manier uitvoeren.

De berichtentiteiten die de kern vormen van de berichtenmogelijkheden in Service Bus zijn wachtrijen, onderwerpen en abonnementen en regels/acties.

Wachtrijen

Wachtrijen bieden FIFO-berichten (First In, First Out) aan een of meer concurrerende consumenten. Dat wil zeggen dat ontvangers doorgaans berichten ontvangen en verwerken in de volgorde waarin ze aan de wachtrij zijn toegevoegd. En slechts één bericht dat de consument ontvangt en verwerkt elk bericht. Een belangrijk voordeel van het gebruik van wachtrijen is het bereiken van tijdelijke ontkoppeling van toepassingsonderdelen. Met andere woorden, de producenten (afzenders) en consumenten (ontvangers) hoeven niet tegelijkertijd berichten te verzenden en te ontvangen. Dat komt doordat berichten blijvend worden opgeslagen in de wachtrij. Bovendien hoeft de producent niet te wachten op een antwoord van de consument om door te gaan met het verwerken en verzenden van berichten.

Een gerelateerd voordeel is load leveling, waarmee producenten en consumenten berichten met verschillende snelheden kunnen verzenden en ontvangen. In veel toepassingen varieert de systeembelasting in de tijd. De verwerkingstijd die voor elke werkeenheid is vereist, is doorgaans echter constant. Het door elkaar brengen van berichtproducenten en consumenten met een wachtrij betekent dat de verbruikende toepassing alleen de gemiddelde belasting hoeft te kunnen verwerken in plaats van piekbelasting. De lengte van de wachtrij neemt toe of af, al naargelang het binnenkomende verkeer. Met deze mogelijkheid bespaart u rechtstreeks geld met betrekking tot de hoeveelheid infrastructuur die nodig is om de belasting van de toepassing aan te kunnen. Naarmate de belasting toeneemt, kunnen er meer werkprocessen worden toegevoegd om uit de wachtrij te lezen. Elk bericht worden door slechts één van de werkprocessen verwerkt. Bovendien maakt deze taakverdeling op basis van pull het beste gebruik van de werkcomputers mogelijk, zelfs als de werkcomputers met verwerkingskracht pull-berichten op hun eigen maximale snelheid gebruiken. Dit patroon wordt vaak aangeduid als het concurrerend consumenten-patroon.

Het gebruik van wachtrijen tussen berichtproducenten en consumenten biedt een inherente losse koppeling tussen de onderdelen. Omdat producenten en consumenten niet op de hoogte zijn van elkaar, kan een consument worden bijgewerkt zonder dat dit gevolgen heeft voor de producent.

Wachtrijen maken

U kunt wachtrijen maken met de Azure Portal, PowerShell, CLIof Resource Manager sjablonen. Verzend en ontvang vervolgens berichten met behulp van clients die zijn geschreven in C#, Java, Python, JavaScripten PHP.

Modi voor ontvangen

U kunt twee verschillende modi opgeven waarin Service Bus berichten ontvangt.

  • Ontvangen en verwijderen. Wanneer in deze modus Service Bus aanvraag van de consument ontvangt, wordt het bericht als verbruikt markeert en wordt het bericht naar de consumententoepassing teruggezonden. Deze modus is het eenvoudigste model. Dit werkt het beste voor scenario's waarin de toepassing het niet verwerken van een bericht kan tolereren als er een fout optreedt. Als u dit scenario wilt begrijpen, kunt u een scenario overwegen waarin de consument de ontvangstaanvraag uit geeft en vervolgens vast loopt voordat deze wordt verwerkt. Omdat Service Bus het bericht markeert als verbruikt, begint de toepassing berichten te verbruiken bij het opnieuw opstarten. Het bericht dat vóór de crash is verbruikt, wordt gemist.
  • Vergrendelen bekijken. In deze modus wordt de ontvangstbewerking in twee fases, waardoor toepassingen kunnen worden ondersteund die geen ontbrekende berichten kunnen tolereren.

    1. Zoekt het volgende bericht dat moet worden verbruikt, vergrendelt het om te voorkomen dat andere consumenten het ontvangen en retourneren het bericht vervolgens naar de toepassing.

    2. Nadat de toepassing klaar is met het verwerken van het bericht, wordt de Service Bus service gevraagd om de tweede fase van het ontvangstproces te voltooien. Vervolgens markeert de service het bericht als verbruikt.

      Als de toepassing het bericht om de een of andere reden niet kan verwerken, kan de toepassing de Service Bus het bericht af te geven. Service Bus ontgrendelt het bericht en maakt het beschikbaar om opnieuw te worden ontvangen, door dezelfde consument of door een andere concurrerende consument. Ten tweede is er een time-out gekoppeld aan de vergrendeling. Als de toepassing het bericht niet kan verwerken voordat de time-out voor vergrendeling verloopt, ontgrendelt Service Bus het bericht en maakt het beschikbaar om opnieuw te worden ontvangen.

      Als de toepassing vast loopt nadat het bericht is verwerkt, maar voordat de Service Bus-service wordt gevraagd het bericht te voltooien, Service Bus het bericht opnieuw aan de toepassing wanneer het opnieuw wordt gestart. Dit proces wordt vaak ten minste eenmaal verwerken genoemd. Dat wil zeggen dat elk bericht ten minste één keer wordt verwerkt. In bepaalde situaties kan hetzelfde bericht echter opnieuw worden weergegeven. Als uw scenario dubbele verwerking niet kan tolereren, voegt u extra logica toe aan uw toepassing om duplicaten te detecteren. Zie Detectie van duplicaten voor meer informatie. Deze functie wordt exactly once processing genoemd.

      Notitie

      Zie Settling receive operations (Settling receive-bewerkingen) voor meer informatie over deze twee modi.

Onderwerpen en abonnementen

Met een wachtrij kan een bericht door één consument worden verwerkt. In tegenstelling tot wachtrijen bieden onderwerpen en abonnementen een een-op-veel-communicatievorm in een patroon voor publiceren en abonneren. Dit is handig voor het schalen naar grote aantallen ontvangers. Elk gepubliceerd bericht wordt beschikbaar gesteld voor elk abonnement dat is geregistreerd bij het onderwerp. Publisher verzendt een bericht naar een onderwerp en een of meer abonnees ontvangen een kopie van het bericht, afhankelijk van de filterregels die zijn ingesteld voor deze abonnementen. De abonnementen kunnen aanvullende filters gebruiken om de berichten te beperken die ze willen ontvangen. Uitgevers verzenden berichten naar een onderwerp op dezelfde manier als ze berichten naar een wachtrij verzenden. Consumenten ontvangen echter niet rechtstreeks berichten van het onderwerp. In plaats daarvan ontvangen consumenten berichten van abonnementen van het onderwerp. Een onderwerpabonnement lijkt op een virtuele wachtrij die kopieën ontvangt van de berichten die naar het onderwerp worden verzonden. Consumenten ontvangen berichten van een abonnement op dezelfde manier als ze berichten van een wachtrij ontvangen.

De functionaliteit voor het verzenden van berichten van een wachtrij wordt rechtstreeks aan een onderwerp toegevoegd en de functionaliteit voor het ontvangen van berichten wordt aan een abonnement toegevoegd. Deze functie betekent onder andere dat abonnementen dezelfde patronen ondersteunen die eerder in deze sectie zijn beschreven met betrekking tot wachtrijen: concurrerende consument, tijdelijke ontkoppeling, load leveling en taakverdeling.

Onderwerpen en abonnementen maken

Het maken van een onderwerp is vergelijkbaar met het maken van een wachtrij, zoals beschreven in de vorige sectie. U kunt onderwerpen en abonnementen maken met behulp van de Azure Portal, PowerShell, CLI of Resource Manager sjablonen. Verzend vervolgens berichten naar een onderwerp en ontvang berichten van abonnementen met behulp van clients die zijn geschreven in C#, Java, Python, JavaScripten PHP.

Regels en acties

In veel scenario's moeten berichten met specifieke kenmerken op verschillende manieren worden verwerkt. Als u deze verwerking wilt inschakelen, kunt u abonnementen configureren om berichten te vinden die gewenste eigenschappen hebben en vervolgens bepaalde wijzigingen aan die eigenschappen uitvoeren. Hoewel Service Bus alle berichten ziet die naar het onderwerp worden verzonden, kunt u alleen een subset van deze berichten kopiëren naar de wachtrij van het virtuele abonnement. Dit filteren wordt bereikt met behulp van abonnementsfilters. Dergelijke wijzigingen worden filteracties genoemd. Wanneer een abonnement is gemaakt, kunt u een filterexpressie leveren die wordt gebruikt voor de eigenschappen van het bericht. De eigenschappen kunnen zowel de systeemeigenschappen (bijvoorbeeld Label) als aangepaste toepassingseigenschappen zijn (bijvoorbeeld StoreName.) De SQL filterexpressie is in dit geval optioneel. Zonder een SQL filterexpressie wordt een filteractie die voor een abonnement is gedefinieerd, uitgevoerd op alle berichten voor dat abonnement.

Zie voor een volledig werkend voorbeeld het OnderwerpFilters-voorbeeld op GitHub.

Zie Onderwerpfilters en acties voor meer informatie over filters.

JMS-entiteiten (Java Message Service) 2.0

De volgende entiteiten zijn toegankelijk via de Java Message Service (JMS) 2.0 API.

  • Tijdelijke wachtrijen
  • Tijdelijke onderwerpen
  • Gedeelde duurzame abonnementen
  • Niet-gedeeld duurzame abonnementen
  • Gedeelde niet-duurzame abonnementen
  • Niet-gedeelde niet-duurzame abonnementen

Meer informatie over de JMS 2.0-entiteiten en over het gebruik ervan.

Volgende stappen

Probeer de voorbeelden in de taal van uw keuze om Azure Service Bus verkennen.

Voorbeelden voor de oudere .NET- en Java-clientbibliotheken vindt u hieronder: