Delen via

Service Bus-wachtrijen, -onderwerpen en -abonnementen

  • Artikel

Azure Service Bus ondersteunt betrouwbare berichtenwachtrijen en duurzame berichten publiceren/abonneren. De berichtenentiteiten die de kern vormen van de berichtenmogelijkheden in Service Bus zijn wachtrijen, onderwerpen en abonnementen.

Belangrijk

Als u niet eerder met Azure Service Bus werkt, leest u wat is Azure Service Bus? voordat u dit artikel doorloopt.

Wachtrijen

Wachtrijen maken gebruik van het FIFO-principe (first in, first out) voor de berichtbezorging naar een of meer concurrerende gebruikers. Ontvangers ontvangen doorgaans berichten in de volgorde waarin ze aan de wachtrij zijn toegevoegd. En slechts één bericht dat de consument ontvangt en verwerkt elk bericht.

Afbeelding van de werking van servicewachtrijen.

Een belangrijk voordeel van het gebruik van wachtrijen is het tijdelijk loskoppelen van toepassingsonderdelen. Met andere woorden, de producenten (afzenders) en consumenten (ontvangers) hoeven niet tegelijkertijd berichten te verzenden en te ontvangen, omdat berichten blijvend in de wachtrij worden opgeslagen. Bovendien hoeft de producent niet te wachten op een antwoord van de consument om berichten te blijven verwerken en verzenden.

Een gerelateerd voordeel is load leveling, waarmee producenten en consumenten berichten met verschillende tarieven kunnen verzenden en ontvangen. In veel toepassingen varieert de systeembelasting in de loop van de tijd. De verwerkingstijd die nodig is voor elke werkeenheid is doorgaans constant. Als u berichtproducenten en consumenten met een wachtrij tussenkomt, betekent dit dat de verbruikende toepassing alleen de gemiddelde belasting moet 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 te verwerken. 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 biedt deze pull-taakverdeling het beste gebruik van de werkcomputers, zelfs als de werkcomputers met verwerkingskracht pull-berichten op hun eigen maximumsnelheid. 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 zich niet van elkaar bewust zijn, kan een consument worden geüpgraded zonder dat dit gevolgen heeft voor de producent.

Wachtrijen maken

U kunt wachtrijen maken met een van de volgende opties:

Verzend en ontvang vervolgens berichten met behulp van clients die zijn geschreven in programmeertalen, waaronder de volgende:

Ontvangstmodi

U kunt twee verschillende modi opgeven waarin gebruikers berichten van Service Bus kunnen ontvangen.

  • Ontvangen en verwijderen. Wanneer Service Bus in deze modus de aanvraag van de consument ontvangt, wordt het bericht gemarkeerd als verbruikt en geretourneerd naar de consumententoepassing. Deze modus is het eenvoudigste model. Het werkt het beste voor scenario's waarin de toepassing het verwerken van een bericht niet tolereert als er een fout optreedt. Als u dit scenario wilt begrijpen, moet u een scenario overwegen waarin de consument de ontvangstaanvraag uitgeeft en vervolgens vastloopt voordat deze wordt verwerkt. Wanneer Service Bus het bericht markeert als verbruikt, begint de toepassing berichten te gebruiken bij het opnieuw opstarten. Het bericht dat het heeft verbruikt voordat de crash werd gecrasht, wordt gemist. Dit proces wordt vaak maximaal één keer verwerkt.
  • Kijk slot. In deze modus wordt de ontvangstbewerking een bewerking met twee fasen, waardoor er toepassingen kunnen worden ondersteund die geen ontbrekende berichten kunnen tolereren.

    1. Hiermee vindt u het volgende te gebruiken bericht, wordt het vergrendeld om te voorkomen dat andere consumenten het ontvangen en retourneer het bericht vervolgens naar de toepassing.

    2. Nadat de app 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 een of andere reden niet kan verwerken, kan deze de Service Bus-service vragen om het bericht af te schaffen . Service Bus ontgrendelt het bericht en maakt het beschikbaar om opnieuw te worden ontvangen, hetzij 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 dan ontgrendelt Service Bus het bericht en maakt het beschikbaar zodat het weer kan worden ontvangen.

      Als de toepassing vastloopt nadat het bericht is verwerkt, maar voordat deze vraagt of de Service Bus-service het bericht wil voltooien, verzendt Service Bus het bericht opnieuw naar de toepassing wanneer deze opnieuw wordt opgestart. Dit proces wordt vaak ten minste eenmaal verwerking genoemd. Dat wil dat elk bericht ten minste één keer wordt verwerkt. In bepaalde situaties kan hetzelfde bericht echter opnieuw worden verzonden. Als in uw scenario dubbele verwerking niet kan worden getolereerd, voegt u extra logica toe in uw toepassing om duplicaten te detecteren. Zie Duplicaatdetectie, die exact eenmaal wordt verwerkt , voor meer informatie.

      Notitie

      Zie Settling receive operations 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 publicatie- en abonneerpatroon . Dit is handig voor het schalen naar grote aantallen ontvangers. Elk gepubliceerd bericht wordt beschikbaar gesteld aan elk abonnement dat bij het onderwerp is geregistreerd. Publisher verzendt een bericht naar een onderwerp en een of meer abonnees ontvangen een kopie van het bericht.

Afbeelding van een Service Bus-onderwerp met drie abonnementen.

De abonnementen kunnen meer filters gebruiken om de berichten te beperken die ze willen ontvangen. Uitgevers verzenden berichten naar een onderwerp op dezelfde manier als berichten naar een wachtrij. Consumenten ontvangen echter geen berichten rechtstreeks uit 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. Gebruikers ontvangen berichten van een abonnement op dezelfde manier als de manier waarop ze berichten uit een wachtrij ontvangen.

De functionaliteit voor het verzenden van berichten van een wachtrij wordt rechtstreeks toegewezen aan een onderwerp en de functionaliteit voor het ontvangen van berichten wordt toegewezen aan een abonnement. 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, taakverdeling 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 een van de volgende opties:

Verzend vervolgens berichten naar een onderwerp en ontvang berichten van abonnementen met behulp van clients die zijn geschreven in programmeertalen, waaronder de volgende:

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 met gewenste eigenschappen te vinden en vervolgens bepaalde wijzigingen in deze eigenschappen uit te voeren. Terwijl Service Bus-abonnementen alle berichten zien die naar het onderwerp worden verzonden, is het mogelijk om alleen een subset van deze berichten naar de wachtrij van het virtuele abonnement te kopiëren. Dit filteren wordt uitgevoerd met behulp van abonnementsfilters. Dergelijke wijzigingen worden filteracties genoemd. Wanneer een abonnement wordt gemaakt, kunt u een filterexpressie opgeven die werkt op de eigenschappen van het bericht. De eigenschappen kunnen zowel de systeemeigenschappen (bijvoorbeeld Label) als de aangepaste toepassingseigenschappen (bijvoorbeeld StoreName)zijn. De SQL-filterexpressie is in dit geval optioneel. Zonder een SQL-filterexpressie wordt elke filteractie die is gedefinieerd voor een abonnement uitgevoerd op alle berichten voor dat abonnement.

Zie het voorbeeld TopicFilters op GitHub voor een volledig werkend voorbeeld. Zie Onderwerpfilters en -acties voor meer informatie over filters.

Java Message Service (JMS) 2.0-entiteiten

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

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

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

Express-entiteiten

Express-entiteiten zijn gemaakt voor scenario's met hoge doorvoer en verminderde latentie. Als een bericht met express-entiteiten wordt verzonden naar een wachtrij of onderwerp, wordt het niet onmiddellijk opgeslagen in het berichtenarchief. In plaats daarvan wordt het bericht in eerste instantie in de cache opgeslagen in het geheugen. Berichten die in de entiteit blijven, worden na een vertraging naar het berichtenarchief geschreven, waardoor deze worden beschermd tegen verlies als gevolg van een storing.

In reguliere entiteiten wordt elke runtime-bewerking (zoals Send, Complete, Abandon, Deadletter) eerst in de store bewaard en pas nadat dit aan de client is bevestigd als geslaagd. In express-entiteiten wordt een runtime-bewerking als eerste bevestigd aan de client en wordt pas later luily persistent gemaakt in de store. Als een computer opnieuw wordt opgestart of wanneer er een hardwareprobleem optreedt, worden bepaalde erkende runtimebewerkingen mogelijk helemaal niet behouden. Dit betekent dat de client een lagere latentie krijgt en een hogere doorvoer met express-entiteiten, ten koste van mogelijk gegevensverlies en/of herlevering van berichten.

Bovendien zijn in de loop van de tijd veel optimalisaties uitgevoerd binnen Service Bus, wat betekent dat de doorvoer- en latentievoordelen van snelle entiteiten momenteel minimaal zijn. Bovendien biedt de Premium-laag van Service Bus geen ondersteuning voor Express-entiteiten. Daarom wordt het momenteel niet aanbevolen om deze functie te gebruiken.

Volgende stappen

Probeer de voorbeelden in de taal van uw keuze:

Gebruik de volgende koppelingen voor voorbeelden die gebruikmaken van de oudere .NET- en Java-clientbibliotheken:

Op 30 september 2026 gaan we de Azure Service Bus SDK-bibliotheken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus en com.microsoft.azure.servicebus buiten gebruik stellen, die niet voldoen aan de Azure SDK-richtlijnen. We beëindigen ook de ondersteuning van het SBMP-protocol, zodat u dit protocol na 30 september 2026 niet meer kunt gebruiken. Migreer naar de nieuwste Azure SDK-bibliotheken, die vóór die datum essentiële beveiligingsupdates en verbeterde mogelijkheden bieden.

Hoewel de oudere bibliotheken nog steeds meer dan 30 september 2026 kunnen worden gebruikt, ontvangen ze geen officiële ondersteuning en updates meer van Microsoft. Zie de aankondiging van de buitengebruikstelling van de ondersteuning voor meer informatie.