Begränsningsåtgärder på Azure Service Bus
Molnbaserade lösningar ger en uppfattning om obegränsade resurser som kan skalas med din arbetsbelastning. Även om den här uppfattningen är mer sann i molnet än med lokala system, finns det fortfarande begränsningar som finns i molnet. Dessa begränsningar kan orsaka begränsning av klientprogrambegäranden på både standard- och premiumnivåer enligt beskrivningen i den här artikeln.
Begränsning på standardnivå
Standardnivån för Service Bus fungerar som en konfiguration med flera klientorganisationer med en prismodell för betala per användning. Här delar flera namnområden i samma kluster de allokerade resurserna. Standardnivån är det rekommenderade valet för utvecklingsmiljöer, QA-miljöer och produktionssystem med lågt dataflöde.
Tidigare hade Service Bus grova begränsningsgränser som är strikt beroende av resursutnyttjande. Det finns dock en möjlighet att förfina begränsningslogik och tillhandahålla förutsägbart begränsningsbeteende för alla namnområden som delar dessa resurser.
I ett försök att säkerställa rättvis användning och distribution av resurser i alla Service Bus-standardnamnområden som använder samma resurser använder Service Bus Standard för närvarande kreditbaserad begränsningslogik.
Kommentar
Det är viktigt att observera att begränsning inte är nytt för Azure Service Bus eller någon molnbaserad tjänst.
Kreditbaserad begränsning förfinar helt enkelt hur olika namnområden delar resurser i en standardnivåmiljö för flera klientorganisationer och därmed möjliggör rättvis användning av alla namnområden som delar resurserna.
Vad är kreditbaserad begränsning?
Kreditbaserad begränsning begränsar antalet åtgärder som kan utföras på ett visst namnområde under en viss tidsperiod. Här är arbetsflödet för kreditbaserad begränsning.
- I början av varje tidsperiod ger Service Bus vissa krediter till varje namnområde.
- Åtgärder som utförs av avsändare eller mottagarklientprogram räknas mot dessa krediter (och subtraheras från tillgängliga krediter).
- Om krediterna är uttömda begränsas efterföljande åtgärder fram till början av nästa tidsperiod.
- Krediterna fylls på i början av nästa tidsperiod.
Vilka är kreditgränserna?
Kreditgränserna är för närvarande inställda på 1 000 krediter varje sekund (per namnområde). Alla åtgärder skapas inte lika med. Här är kreditkostnaderna för var och en av åtgärderna.
| Åtgärd | Kreditkostnad |
|---|---|
Dataåtgärder (Send, SendAsync, Receive, ReceiveAsync, Peek) |
1 kredit per meddelande |
Hanteringsåtgärder (Create, Read, Update, Delete i köer, ämnen, prenumerationer, filter) |
10 krediter |
Kommentar
När du skickar till ett ämne utvärderas varje meddelande mot filter innan det görs tillgängligt i prenumerationen. Varje filterutvärdering räknas också mot kreditgränsen (det vill: 1 kredit per filterutvärdering).
Hur gör jag för att vet att jag är begränsad?
När klientprogrambegäranden begränsas får klientprogrammet följande serversvar.
The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.
Hur kan jag undvika att begränsas?
Med delade resurser är det viktigt att framtvinga någon form av rättvis användning i olika Service Bus-namnområden som delar dessa resurser. Begränsning säkerställer att en topp i en enskild arbetsbelastning inte gör att andra arbetsbelastningar på samma resurser begränsas. Som vi nämnde senare i artikeln finns det ingen risk att begränsas eftersom klientprogramutvecklingspaketen (SDK:er) och andra Azure PaaS-erbjudanden har den inbyggda standardprincipen för återförsök. Eventuella begränsade begäranden görs på nytt med exponentiell backoff och går så småningom igenom när krediterna fylls på.
Det är förståeligt att vissa program kan vara känsliga för begränsning. I så fall rekommenderar vi att du migrerar ditt aktuella Service Bus-standardnamnområde till Premium. Vid migrering kan du allokera dedikerade resurser till ditt Service Bus-namnområde och skala upp resurserna på lämpligt sätt om det finns en topp i arbetsbelastningen och minska sannolikheten för att begränsas. När din arbetsbelastning minskar till normala nivåer kan du dessutom skala ned de resurser som allokerats till ditt namnområde.
Begränsning på premiumnivå
Service Bus Premium-nivån allokerar dedikerade resurser, när det gäller meddelandeenheter, till varje namnområdeskonfiguration av kunden. Dessa dedikerade resurser ger förutsägbart dataflöde och svarstider och rekommenderas för system med högt dataflöde eller känsliga produktionsklasser. Dessutom gör premiumnivån det möjligt för kunder att skala upp sin dataflödeskapacitet när de upplever toppar i arbetsbelastningen. Mer information finns i Uppdatera meddelandeenheter automatiskt i ett Azure Service Bus-namnområde.
Hur fungerar begränsning i Service Bus Premium?
Med exklusiv resursallokering för premiumnivån drivs begränsningen enbart av begränsningarna för de resurser som allokerats till namnområdet. Om antalet begäranden är fler än vad de aktuella resurserna kan betjäna begränsas begäranden.
Hur gör jag för att vet att jag är begränsad?
Det finns olika sätt att identifiera begränsningar på Service Bus Premium-nivån.
- Begränsade begäranden visas på måtten för Azure Monitor-begäranden för att identifiera hur många begäranden som begränsades.
- Hög CPU-användning anger att den aktuella resursallokeringen är hög och att begäranden kan begränsas om den aktuella arbetsbelastningen inte minskar.
- Hög minnesanvändning anger att den aktuella resursallokeringen är hög och att begäranden kan begränsas om den aktuella arbetsbelastningen inte minskar.
Hur kan jag undvika att begränsas?
Eftersom Service Bus Premium-namnområdet redan har dedikerade resurser kan du minska risken för att begränsas genom att skala upp antalet meddelandeenheter som allokerats till ditt namnområde i händelse (eller förväntan) av en topp i arbetsbelastningen. Mer information finns i Uppdatera meddelandeenheter automatiskt i ett Azure Service Bus-namnområde.
Vanliga frågor och svar
Hur påverkar begränsning mitt program?
När en begäran begränsas innebär det att tjänsten är upptagen eftersom den har fler begäranden än vad resurserna tillåter. Om samma åtgärd provas igen efter en liten stund, när tjänsten har gått igenom sin aktuella arbetsbelastning, kan begäran uppfyllas.
Eftersom begränsning är det förväntade beteendet för alla molnbaserade tjänster är omprövningslogik inbyggd i själva Service Bus SDK. Standardvärdet är inställt på automatiskt återförsök med en exponentiell back-off för att säkerställa att vi inte har samma begäran begränsas varje gång. Standardlogik för återförsök gäller för varje åtgärd.
Kommentar
Kod för meddelandebearbetning som anropar andra tjänster från tredje part kan också begränsas av dessa andra tjänster. Mer information om hur du hanterar dessa scenarier finns i dokumentationen om begränsningsmönstret.
Leder begränsningen till dataförlust?
Azure Service Bus är optimerat för beständighet. Vi ser till att alla data som skickas till Service Bus är förpliktade till lagring innan tjänsten bekräftar att begäran har slutförts.
När begäran har bekräftats av Service Bus innebär det att Service Bus har bearbetat begäran. Om Service Bus returnerar ett fel innebär det att Service Bus inte har kunnat bearbeta begäran och att klientprogrammet måste försöka begära igen.
Men när en begäran begränsas innebär tjänsten att den inte kan acceptera och bearbeta begäran just nu på grund av resursbegränsningar. Det innebär inte någon form av dataförlust eftersom Service Bus helt enkelt inte har tittat på begäran. I det här fallet säkerställer användning av standardprincipen för återförsök i Service Bus SDK att begäran bearbetas så småningom.
Relaterat innehåll
Mer information och exempel på hur du använder Service Bus-meddelanden finns i följande avancerade avsnitt: