Service Bus-wachtrijen, -onderwerpen en -abonnementen ontdekken
De berichtenentiteiten die de kern vormen van de berichtenmogelijkheden in Service Bus zijn wachtrijen, onderwerpen en abonnementen en regels/acties.
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. Omdat berichten duurzaam in de wachtrij worden opgeslagen, hoeven producenten (afzenders) en consumenten (ontvangers) geen berichten gelijktijdig te verwerken.
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.
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.
U kunt wachtrijen maken met behulp van de Azure-portal, PowerShell, CLI of Resource Manager-sjablonen. Verzend en ontvang vervolgens berichten met behulp van clients die zijn geschreven in C#, Java, Python en JavaScript.
Ontvangstmodi
U kunt twee verschillende modi opgeven waarin Service Bus berichten ontvangt: Ontvangen en verwijderen of Vergrendeling bekijken.
Ontvangen en verwijderen
In deze modus, wanneer Service Bus 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. Denk bijvoorbeeld aan een scenario 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.
Vergrendeling bekijken
In deze modus wordt de ontvangstbewerking een bewerking met twee fasen, waardoor er toepassingen kunnen worden ondersteund die geen ontbrekende berichten kunnen tolereren.
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.
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.
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.
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.
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, kunt u alleen een subset van deze berichten naar de wachtrij van het virtuele abonnement 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 een filteractie die is gedefinieerd voor een abonnement, uitgevoerd op alle berichten voor dat abonnement.