Share via

Azure Service Bus-üzenetek előzetes kezelése

  • Cikk

Ha bármely hivatalos Service Bus-ügyfél esetében engedélyezi az előkezelés funkciót, a fogadó több üzenetet szerez be, mint amennyit az alkalmazás eredetileg kért, a megadott előzetes verziószámig. Amikor az üzenetek visszakerülnek az alkalmazásba, az ügyfél további üzeneteket szerez be a háttérben, hogy kitöltse az előbetöltési puffert.

Előzetes betöltés engedélyezése

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.

Állítsa be a ServiceBusReceiver és a ServiceBusProcessor objektum előzetes darabszám tulajdonságát.

Megjegyzé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.

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ás időkorlátja ketyeg. 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 (amely a közvetítő és a helyi gép órája közötti óraeltérés hatálya alá tartozik).

Ha az üzenetzár lejárt, az alkalmazásnak figyelmen kívül kell hagynia az üzenetet, és nem szabad API-hívást kezdeményeznie az üzeneten. Ha az üzenet nem járt le, de a lejárat küszöbön áll, a zárolás megújítható és meghosszabbítható egy másik alapértelmezett zárolási időszakkal. 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. Előfordulhat, hogy az üzenet beolvassa az előcsatorna pufferébe, é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 kézbesíthetők ténylegesen használható (érvényesen zárolt) állapotban, és végül áthelyezik a kézbesítetlen levelek üzenetsorába 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 érkező üzeneteket az első előtti (FIFO) sorrendben ürítik ki, az alkalmazás sorrenden kívül fogadhatja az üzeneteket. Előfordulhat például, hogy az alkalmazás egy 2- 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ási időtúllépésnek nem szabad olyan hosszúnak lennie, hogy az üzenetek túlléphessék a maximális élettartamukat, amikor véletlenül elvetik őket, ezért a zárolásukat le kell járniuk, mielőtt újra kézbesítenék őket.

Következő lépések

Az Azure Service Bus funkcióinak megismeréséhez próbálja ki az Ön által választott nyelven elérhető mintákat.

Minták a régebbi .NET- és Java-ügyfélkódtárakhoz:

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.