Beperkingsbewerkingen in Azure Service Bus
Cloudeigen oplossingen bieden een idee van onbeperkte resources die kunnen worden geschaald met uw workload. Hoewel dit idee meer waar is in de cloud dan bij on-premises systemen, zijn er nog steeds beperkingen in de cloud. Deze beperkingen kunnen leiden tot beperking van aanvragen van clienttoepassingen in zowel standard- als Premium-lagen, zoals beschreven in dit artikel.
Beperking in standard-laag
De standard-laag van Service Bus werkt als een multitenant-installatie met een prijsmodel voor betalen per gebruik. Hier delen meerdere naamruimten in hetzelfde cluster de toegewezen resources. De Standard-laag is de aanbevolen keuze voor ontwikkelomgevingen, QA-omgevingen en productiesystemen met lage doorvoer.
In het verleden had Service Bus coarse beperkingslimieten die strikt afhankelijk zijn van het resourcegebruik. Er is echter een mogelijkheid om beperkingslogica te verfijnen en voorspelbaar beperkingsgedrag te bieden aan alle naamruimten die deze resources delen.
In een poging om eerlijk gebruik en distributie van resources te garanderen in alle Service Bus-standaardnaamruimten die gebruikmaken van dezelfde resources, maakt Service Bus-standaard momenteel gebruik van de op krediet gebaseerde beperkingslogica.
Notitie
Het is belangrijk te weten dat beperking niet nieuw is voor Azure Service Bus of een cloudeigen service.
Kredietbeperking is simpelweg het verfijnen van de manier waarop verschillende naamruimten resources delen in een omgeving met een standard-laag met meerdere tenants en zo eerlijk gebruik mogelijk maken door alle naamruimten die de resources delen.
Wat is beperking op basis van krediet?
Met op tegoed gebaseerde beperking beperkt u het aantal bewerkingen dat in een bepaalde tijdsperiode op een bepaalde naamruimte kan worden uitgevoerd. Hier volgt de werkstroom voor beperking op basis van tegoed.
- Aan het begin van elke periode biedt Service Bus een aantal tegoeden aan elke naamruimte.
- Alle bewerkingen die door de clienttoepassingen van de afzender of ontvanger worden uitgevoerd, worden meegeteld voor deze tegoeden (en afgetrokken van het beschikbare tegoed).
- Als het tegoed wordt uitgeput, worden volgende bewerkingen beperkt tot het begin van de volgende periode.
- Tegoeden worden aan het begin van de volgende periode aangevuld.
Wat zijn de kredietlimieten?
De kredietlimieten zijn momenteel ingesteld op 1000 tegoeden per seconde (per naamruimte). Niet alle bewerkingen worden gelijk gemaakt. Hier volgen de kredietkosten van elk van de bewerkingen.
| Operation | Tegoedkosten |
|---|---|
Gegevensbewerkingen (Send, SendAsync, Receive, ReceiveAsync) Peek |
1 tegoed per bericht |
Beheerbewerkingen (Create, Read, , UpdateDelete in wachtrijen, onderwerpen, abonnementen, filters) |
10 tegoed |
Notitie
Wanneer u naar een onderwerp verzendt, wordt elk bericht geëvalueerd op basis van filters voordat het beschikbaar wordt gesteld voor het abonnement. Elke filterevaluatie telt ook mee op basis van de kredietlimiet (dat wil gezegd 1 tegoed per filterevaluatie).
Hoe kan ik weten dat ik wordt beperkt?
Wanneer de aanvragen van de clienttoepassing worden beperkt, ontvangt de clienttoepassing het volgende serverantwoord.
The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.
Hoe kan ik voorkomen dat de beperking wordt beperkt?
Met gedeelde resources is het belangrijk om een eerlijk gebruik af te dwingen voor verschillende Service Bus-naamruimten die deze resources delen. Beperking zorgt ervoor dat een piek in één workload niet tot gevolg heeft dat andere werkbelastingen op dezelfde resources worden beperkt. Zoals verderop in het artikel wordt vermeld, is er geen risico dat het wordt beperkt omdat de SDK's (Client Software Development Kits) en andere Azure PaaS-aanbiedingen het standaardbeleid voor opnieuw proberen hebben ingebouwd. Eventuele vertraagde aanvragen worden opnieuw geprobeerd met exponentieel uitstel en uiteindelijk door te gaan wanneer het tegoed wordt aangevuld.
Begrijpelijkerwijs kunnen sommige toepassingen gevoelig zijn voor beperking. In dat geval wordt u aangeraden uw huidige Service Bus Standard-naamruimte te migreren naar Premium. Bij migratie kunt u toegewezen resources toewijzen aan uw Service Bus-naamruimte en de resources op de juiste manier omhoog schalen als er een piek in uw workload is en de kans op beperking verminderen. Bovendien kunt u, wanneer uw werkbelasting afneemt tot normale niveaus, de resources omlaag schalen die aan uw naamruimte zijn toegewezen.
Beperking in Premium-laag
De Service Bus Premium-laag wijst toegewezen resources, in termen van berichteneenheden, toe aan elke naamruimte die door de klant is ingesteld. Deze toegewezen resources bieden voorspelbare doorvoer en latentie en worden aanbevolen voor systemen met hoge doorvoer of gevoelige productieklassen. Daarnaast kunnen klanten met de Premium-laag hun doorvoercapaciteit omhoog schalen wanneer ze pieken in de workload ervaren. Zie Berichteneenheden van een Azure Service Bus-naamruimte automatisch bijwerken voor meer informatie.
Hoe werkt beperking in Service Bus Premium?
Met exclusieve resourcetoewijzing voor de Premium-laag wordt beperking uitsluitend aangestuurd door de beperkingen van de resources die aan de naamruimte zijn toegewezen. Als het aantal aanvragen groter is dan de huidige resources kan verwerken, worden de aanvragen beperkt.
Hoe kan ik weten dat ik wordt beperkt?
Er zijn verschillende manieren om beperking in de Service Bus Premium-laag te identificeren.
- Vertraagde aanvragen worden weergegeven in de metrische gegevens van de Azure Monitor-aanvraag om te bepalen hoeveel aanvragen zijn beperkt.
- Hoog CPU-gebruik geeft aan dat de huidige resourcetoewijzing hoog is en aanvragen mogelijk worden beperkt als de huidige workload niet vermindert.
- Hoog geheugengebruik geeft aan dat de huidige resourcetoewijzing hoog is en aanvragen mogelijk worden beperkt als de huidige workload niet vermindert.
Hoe kan ik voorkomen dat de beperking wordt beperkt?
Omdat de Service Bus Premium-naamruimte al toegewezen resources heeft, kunt u de mogelijkheid verminderen om te worden beperkt door het aantal berichteneenheden dat aan uw naamruimte is toegewezen, omhoog te schalen in de gebeurtenis (of verwacht) van een piek in de workload. Zie Berichteneenheden van een Azure Service Bus-naamruimte automatisch bijwerken voor meer informatie.
Veelgestelde vragen
Hoe is beperking van invloed op mijn toepassing?
Wanneer een aanvraag wordt beperkt, betekent dit dat de service bezet is omdat deze meer aanvragen ondervindt dan de resources toestaan. Als dezelfde bewerking na enkele ogenblikken opnieuw wordt geprobeerd, kan de aanvraag worden uitgevoerd zodra de service de huidige workload heeft doorlopen.
Aangezien beperking het verwachte gedrag van een systeemeigen cloudservice is, wordt logica voor opnieuw proberen ingebouwd in de Service Bus SDK zelf. De standaardinstelling is ingesteld op automatisch opnieuw proberen met een exponentiële back-off om ervoor te zorgen dat we niet elke keer dezelfde aanvraag hebben beperkt. De standaardlogica voor opnieuw proberen is van toepassing op elke bewerking.
Notitie
Berichtverwerkingscode die andere services van derden aanroept, kan ook worden beperkt door die andere services. Zie de documentatie over het beperkingspatroon voor meer informatie over het afhandelen van deze scenario's.
Leidt beperking tot gegevensverlies?
Azure Service Bus is geoptimaliseerd voor persistentie. We zorgen ervoor dat alle gegevens die naar Service Bus worden verzonden, worden doorgevoerd in opslag voordat de service het succes van de aanvraag bevestigt.
Zodra de aanvraag is bevestigd door Service Bus, betekent dit dat Service Bus de aanvraag heeft verwerkt. Als Service Bus een fout retourneert, betekent dit dat Service Bus de aanvraag niet heeft verwerkt en dat de clienttoepassing de aanvraag opnieuw moet proberen.
Wanneer een aanvraag echter wordt beperkt, impliceert de service dat deze de aanvraag momenteel niet kan accepteren en verwerken vanwege resourcebeperkingen. Dit impliceert geen gegevensverlies, omdat Service Bus de aanvraag niet heeft bekeken. In dit geval zorgt het vertrouwen op het standaardbeleid voor opnieuw proberen van de Service Bus SDK ervoor dat de aanvraag uiteindelijk wordt verwerkt.
Gerelateerde inhoud
Zie de volgende geavanceerde onderwerpen voor meer informatie en voorbeelden van het gebruik van Service Bus-berichten: