Prefetch Azure Service Bus-meddelanden
Funktionen Prefetch hämtar meddelanden i bakgrunden till en lokal prefetch-buffert upp till antalet prefetch. Meddelanden hanteras från bufferten. När det händer frigörs utrymme i bufferten, och mottagaren kommer att prefetch mer i bakgrunden.
Om du vill aktivera prefetch-funktionen anger du antalet prefetch för kön eller prenumerationsklienten till ett tal som är större än noll. Om värdet ställs in på noll inaktiveras prefetch. Om det finns meddelanden i prefetch-bufferten när funktionen har inaktiverats tar programmet emot dessa meddelanden från bufferten först och går sedan till tjänsten.
Ange egenskapen prefetch count för objekten ServiceBusReceiverOptions och ServiceBusProcessorOptions .
Kommentar
Java Script SDK stöder inte Prefetch-funktionen .
Meddelanden är tillgängliga i prefetch-bufferten, men efterföljande mottagningsanrop uppfylls omedelbart från bufferten. Bufferten fylls på i bakgrunden när utrymmet blir tillgängligt. Om det inte finns några meddelanden tillgängliga för leverans tömmer mottagningsåtgärden bufferten och väntar eller blockerar sedan som förväntat.
Varför är Prefetch inte standardalternativet?
Prefetch påskyndar meddelandeflödet genom att ha ett meddelande som är tillgängligt för lokal hämtning innan programmet ber om ett. Den här dataflödesvinsten är resultatet av en kompromiss som programförfattaren uttryckligen måste göra.
När du använder mottagnings - och borttagningsläget är alla meddelanden som hämtas till prefetch-bufferten inte längre tillgängliga i kön. Meddelandena finns bara kvar i minnesintern prefetch-bufferten tills de tas emot i programmet. Om programmet slutar innan meddelandena tas emot i programmet kan dessa meddelanden inte återställas (förlorade).
När du använder visningslåsets mottagningsläge hämtas meddelanden som hämtats till prefetch-bufferten till bufferten i ett låst tillstånd. Låstimern startar från det ögonblick då meddelandet förinställs i bufferten. Om prefetch-bufferten är stor och bearbetningen tar så lång tid att meddelandelåsen upphör att gälla medan de stannar kvar i prefetch-bufferten eller även när programmet bearbetar meddelandet, kan det finnas några förvirrande händelser som programmet kan hantera. Programmet kan hämta ett meddelande med ett lås som har upphört att gälla eller snart upphör att gälla. I så fall kan programmet bearbeta meddelandet, men upptäcker sedan att det inte kan slutföra meddelandet på grund av att låset upphör att gälla. Programmet kan kontrollera LockedUntilUtc egenskapen, men kom ihåg att det finns klocksnedvridning mellan asynkron och lokal datorklocka.
Om låset tyst upphör att gälla i prefetch-bufferten behandlas meddelandet som övergivet och görs återigen tillgängligt för hämtning från kön. Sedan hämtas meddelandet igen till prefetchbufferten och placeras i slutet Om förinläsningsbufferten vanligtvis inte kan bearbetas under meddelandets giltighetstid, förinstalleras meddelanden upprepade gånger men levereras aldrig effektivt i ett användbart (giltigt låst) tillstånd och flyttas så småningom till kön med obeställbara meddelanden när det maximala leveransantalet har överskridits.
Om ett program uttryckligen avger ett meddelande kan meddelandet återigen vara tillgängligt för hämtning från kön. När prefetch är aktiverat hämtas meddelandet till prefetch-bufferten igen och placeras i slutet. Eftersom meddelandena från prefetch-bufferten töms i fifo-ordningen (first-in first-out) kan programmet ta emot meddelanden i fel ordning. Programmet kan till exempel få ett meddelande med ID 2 och sedan ett meddelande med ID 1 (som övergavs tidigare) från bufferten.
Om du behöver en hög grad av tillförlitlighet för meddelandebearbetning, och bearbetningen tar mycket tid och arbete, rekommenderar vi att du använder Prefetch-funktionen konservativt eller inte alls. Om du behöver högt dataflöde och meddelandebearbetning ofta är billigt ger prefetch betydande fördelar med dataflödet.
Det maximala antalet prefetch och låsvaraktigheten som konfigurerats i kön eller prenumerationen måste balanseras så att tidsgränsen för låset åtminstone överskrider den kumulativa förväntade meddelandebearbetningstiden för den maximala storleken på prefetch-bufferten plus ett meddelande. Samtidigt bör låsets varaktighet inte vara så lång att meddelanden kan överskrida sin maximala tid att leva medan de är låsta, eftersom det skulle innebära att de tas bort om de inte kunde slutföras när de var förinställda.
Den 30 september 2026 drar vi tillbaka Azure Service Bus SDK-biblioteken WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus och com.microsoft.azure.servicebus, som inte följer Riktlinjerna för Azure SDK. Vi kommer också att avsluta stödet för SBMP-protokollet, så du kommer inte längre att kunna använda det här protokollet efter den 30 september 2026. Migrera till de senaste Azure SDK-biblioteken, som erbjuder kritiska säkerhetsuppdateringar och förbättrade funktioner, före det datumet.
Även om de äldre biblioteken fortfarande kan användas efter den 30 september 2026 får de inte längre officiell support och uppdateringar från Microsoft. Mer information finns i meddelandet om supportavgång.