Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A Prefetch funkció a háttérben lévő üzeneteket egy helyi előcsatorna-pufferbe olvassa be, egészen az előbetöltések számához. Az üzenetek a pufferből lesznek kézbesítve. Ahogy ez történik, a pufferben szabadít fel helyet, és a fogadó többet fog előre befogni a háttérben.
Az Előjegyzés funkció engedélyezéséhez állítsa az üzenetsor vagy az előfizetési ügyfél előjegyzési számát nullánál nagyobb számra. Az érték nullára állítása kikapcsolja az előbetöltést. Ha a funkció kikapcsolása után vannak üzenetek az előcsatorna pufferében, az alkalmazás először a pufferből fogadja ezeket az üzeneteket, majd a szolgáltatáshoz fordul.
Állítsa be a ServiceBusReceiverOptions és a ServiceBusProcessorOptions objektumok előzetes darabszám tulajdonságát.
Feljegyzés
A Java Script SDK nem támogatja az előzetes verziójú funkciót.
Bár az üzenetek elérhetők az előbetöltési pufferben, az azt követő fogadási hívások azonnal teljesülnek a pufferből. A puffer feltöltése a háttérben történik, amint elérhetővé válik a hely. Ha nem érhetők el üzenetek kézbesítésre, a fogadási művelet kiüríti a puffert, majd a várt módon várakozik vagy blokkol.
Fontos megjegyezni, hogy PrefetchCount meghatározza a helyi pufferben bármikor létezhet üzenetek maximális számát. Ez azt is jelenti, hogy szigorú felső korlátként szolgál arra vonatkozóan, hogy hány üzenet dolgozható fel egyszerre. Ha MaxConcurrentCalls magasabb PrefetchCountérték van beállítva, a processzor nem fogja tudni használni az összes egyidejű üzenetkezelőt, mivel egyszerre csak az PrefetchCount üzenetek lehetnek aktívak a memóriában.
Miért nem a Prefetch az alapértelmezett beállítás?
Az előkezelés felgyorsítja az üzenetfolyamot azáltal, hogy egy üzenet könnyen elérhető a helyi lekéréshez, mielőtt az alkalmazás rákérdez. Ez az átviteli sebesség-nyereség egy olyan kompromisszum eredménye, amelyet az alkalmazás szerzőjének explicit módon kell végrehajtania.
A fogadási és törlési mód használata esetén az előbetöltési pufferbe beolvasott összes üzenet már nem érhető el az üzenetsorban. Az üzenetek csak a memóriában lévő előbetöltési pufferben maradnak, amíg be nem érkeznek az alkalmazásba. Ha az alkalmazás az üzenetek alkalmazásba való fogadása előtt véget ér, az üzenetek helyreállíthatatlanok (elvesznek).
A betekintő zárolás fogadási módjának használatakor a rendszer zárolt állapotban szerzi be az előtelepítési pufferbe beolvasott üzeneteket a pufferbe. A zárolási időzítő attól a pillanattól kezdődik, amikor az üzenet előre be van illesztve a pufferbe. Ha az előbetöltési puffer nagy méretű, és a feldolgozás olyan hosszú ideig tart, hogy az üzenetzárolások lejárnak, miközben az előbetöltési pufferben marad, vagy akár az alkalmazás az üzenet feldolgozása közben is, előfordulhat, hogy az alkalmazás számára zavaró eseményeket kell kezelnie. Előfordulhat, hogy az alkalmazás lejáró vagy hamarosan lejáró zárolású üzenetet kap. Ha igen, az alkalmazás feldolgozhatja az üzenetet, de a zárolási lejárat miatt nem tudja befejezni az üzenetet. Az alkalmazás ellenőrizheti a tulajdonságot LockedUntilUtc , de ne feledje, hogy óraeltérés van a közvetítő és a helyi gép óra között.
Ha a zárolás csendesen lejár az előbetöltési pufferben, az üzenet elhagyva lesz, és ismét elérhetővé válik az üzenetsorból való lekéréshez. Ezután a rendszer ismét beolvassa az üzenetet az előtelepítési pufferbe, és a végén helyezi el, ha az előtelepítési puffert általában nem lehet feldolgozni az üzenet lejárata során, az üzenetek ismételten előre be vannak ágyazva, de soha nem lesznek ténylegesen használható (érvényesen zárolt) állapotban kézbesítve, és végül áthelyezik a kézbesítetlen levelek várólistájára a maximális kézbesítési szám túllépése után.
Ha egy alkalmazás explicit módon felhagy egy üzenettel, előfordulhat, hogy az üzenet ismét elérhető lesz az üzenetsorból való lekéréshez. Ha az előletöltés engedélyezve van, a rendszer ismét beolvassa az üzenetet az előbetöltési pufferbe, és a végén helyezi el. Mivel az előcsatorna-pufferből származó üzeneteket az első előtti (FIFO) sorrendben ürítik ki, előfordulhat, hogy az alkalmazás sorrenden kívül fogadja az üzeneteket. Előfordulhat például, hogy az alkalmazás egy 2-s azonosítójú üzenetet, majd egy 1- (korábban elhagyatott) azonosítójú üzenetet kap a pufferből.
Ha nagy fokú megbízhatóságra van szüksége az üzenetfeldolgozáshoz, és a feldolgozás jelentős munkát és időt vesz igénybe, javasoljuk, hogy konzervatívan vagy egyáltalán ne használja a Prefetch funkciót. Ha nagy átviteli sebességre van szüksége, és az üzenetek feldolgozása általában olcsó, az előbetöltés jelentős átviteli sebességet eredményez.
Az előjegyzések maximális számát és az üzenetsoron vagy előfizetésen konfigurált zárolási időtartamot úgy kell egyensúlyozni, hogy a zárolási időtúllépés legalább meghaladja az előbetöltési puffer maximális méretére vonatkozó összesített üzenetfeldolgozási időt, plusz egy üzenetet. Ugyanakkor a zárolás időtartama nem lehet olyan hosszú, hogy az üzenetek túlléphessék a maximális élettartamukat zárolva, mivel ez azt jelentené, hogy az üzenetek el lesznek távolítva, ha nem lehet befejezni őket az előkezeléskor.
2026. szeptember 30-án kivonjuk az Azure Service Bus SDK-kódtárakat a WindowsAzure.ServiceBus, a Microsoft.Azure.ServiceBus és a com.microsoft.azure.servicebus kódtárakból, amelyek nem felelnek meg az Azure SDK irányelveinek. Az SBMP protokoll támogatását is megszüntetjük, így 2026. szeptember 30. után már nem használhatja ezt a protokollt. Migrálás a legújabb Azure SDK-kódtárakba, amelyek kritikus fontosságú biztonsági frissítéseket és továbbfejlesztett képességeket kínálnak ezen dátum előtt.
Bár a régebbi kódtárak 2026. szeptember 30-tól továbbra is használhatók, a Microsoft már nem kap hivatalos támogatást és frissítéseket. További információkért lásd a támogatási nyugdíjazási bejelentést.