Azure Service Bus – Üzenet lejárata (élettartam)

  • Cikk

Az üzenetben szereplő hasznos adatokra, illetve az üzenet fogadónak átadott parancsára vagy vizsgálatára szinte mindig valamilyen alkalmazásszintű lejárati határidő vonatkozik. Egy ilyen határidő után a tartalom már nem lesz kézbesítve, vagy a kért művelet már nem lesz végrehajtva.

Az olyan fejlesztési és tesztelési környezetek esetében, amelyekben az üzenetsorokat és témaköröket gyakran használják az alkalmazások vagy alkalmazásrészek részleges futtatásának kontextusában, a rekedt tesztüzenetek automatikus szemétgyűjtése is kívánatos, hogy a következő tesztfuttatás tiszta legyen.

Megjegyzés:

Ha még nem ismeri a Service Bus-fogalmakat, tekintse meg a Service Bus-fogalmakat és a Service Bus-üzenetsorokat, témaköröket és előfizetéseket.

Az egyes üzenetek lejárata szabályozható az élettartamot meghatározó rendszertulajdonság beállításával, amely relatív időtartamot határoz meg. A lejárat abszolút pillanattá válik, amikor az üzenet beolvasódik az entitásba. Ekkor a lejárati időpont -at-utc tulajdonság a következő értéket veszi fel: enqueued-time-utc + time-to-live. A közvetített üzenetek élettartamának (TTL) beállítása nem lesz kényszerítve, ha nincsenek aktívan figyelő ügyfelek.

Az utc-időpontban lejáró időbélyegen túllépve az üzenetek nem lesznek jogosultak a lekérésre. A lejárat nem érinti a kézbesítéshez jelenleg zárolt üzeneteket. Ezek az üzenetek továbbra is a szokásos módon vannak kezelve. Ha a zárolás lejár, vagy az üzenet el van hagyva, a lejárat azonnal érvénybe lép. Amíg az üzenet zárolva van, előfordulhat, hogy az alkalmazás egy lejárt üzenet birtokában van. Az, hogy az alkalmazás hajlandó-e továbblépni a feldolgozásra, vagy úgy dönt, hogy feladja az üzenetet, a implementálón múlik.

A rendkívül alacsony TTL ezredmásodperc vagy másodperc sorrendben az üzenetek lejáratát okozhatja, mielőtt a fogadó alkalmazások megkapják. Vegye figyelembe az alkalmazáshoz használható legmagasabb TTL-t.

Megjegyzés:

Ütemezett üzenetek esetén meg kell adnia, hogy mikor jelenjen meg az üzenet a lekérési várólistán. Az üzenet Service Busba küldésének időpontja eltér attól az időponttól, amikor az üzenetet lekérte. Az üzenet lejárati ideje a lekért időponttól függ, nem attól az időponttól, amikor az üzenetet elküldi a Service Busnak. Ezért a lejár-at-utc még enqueued time + time-to-live.

Ha például 5 percet UtcNowad megScheduledEnqueueTimeUtc, és TimeToLive 10 percre, az üzenet 5 + 10 = 15 perc múlva lejár. Az üzenet 5 perc után megjelenik az üzenetsorban, és a 10 perces számláló onnan kezdődik.

Entitásszintű lejárat

Az üzenetsorba vagy témakörbe küldött összes üzenetre alapértelmezett lejárat vonatkozik, amely az entitás szintjén van beállítva. A portálon is beállítható a létrehozás során, és később módosítható. Az alapértelmezett lejárat az entitásnak küldött összes olyan üzenetre érvényes, amelyben az élettartam nincs explicit módon beállítva. Az alapértelmezett lejárat az élettartam értékének felső határaként is működik. Az alapértelmezett értéknél hosszabb élettartamú üzeneteket a rendszer a lekérés előtt csendesen módosítja az alapértelmezett üzenet élettartam-idő értékére.

Megjegyzés:

  • A közvetített üzenetek alapértelmezett élettartam-értéke az aláírt 64 bites egész szám legnagyobb lehetséges értéke, ha egyébként nincs megadva.
  • Üzenetküldési entitások (üzenetsorok és témakörök) esetén az alapértelmezett lejárati idő szintén a lehető legnagyobb érték a Service Bus standard és prémium szintű, aláírt 64 bites egész számához. Az alapszint esetében az alapértelmezett (szintén maximális) lejárati idő 14 nap.
  • Ha a témakör az előfizetésnél kisebb TTL-t ad meg, a témakör TTL-jének alkalmazása történik.

A lejárt üzenetek opcionálisan áthelyezhetők egy kézbesítetlen üzenetsorba. Ezt a beállítást programozott módon vagy az Azure Portal használatával is konfigurálhatja. Ha a beállítás le van tiltva, a rendszer elveti a lejárt üzeneteket. A kézbesítetlen levelek üzenetsorába áthelyezett lejárt üzenetek megkülönböztethetők a többi kézbesítetlen levéltől, ha kiértékeli a kézbesítetlen levelek ok tulajdonságát, amelyet a közvetítő tárol a felhasználói tulajdonságok szakaszban.

Ha az üzenet védett a zárolás alatt lévő lejárattól, és ha a jelölő be van állítva az entitáson, az üzenet át lesz helyezve a kézbesítetlen levelek üzenetsorába a zárolás elhagyásakor vagy lejáratakor. Az üzenet azonban nem lesz áthelyezve, ha az üzenet sikeresen rendeződött, ami azt feltételezi, hogy az alkalmazás a névleges lejárat ellenére sikeresen kezelte azt. Az üzenetzárolásokról és a kiegyenlítésről további információt az Üzenetátvitelek, zárolások és kiegyenlítés című témakörben talál.

Az élettartam és az automatikus (és tranzakciós) holtbetűsítés kombinációja a lejáratkor értékes eszköz annak megállapításához, hogy a határidő lejártakor egy kezelőnek vagy kezelők egy csoportjának adott feladatot lekérnek-e feldolgozásra.

Vegyük például azt a webhelyet, amelynek megbízhatóan kell végrehajtania a feladatokat egy méretkorlátozott háttérrendszeren, és amely időnként forgalomnövekedést tapasztal, vagy a háttérrendszer rendelkezésre állási epizódjaival szemben szeretné szigetelni. Normál esetben az elküldött felhasználói adatok kiszolgálóoldali kezelője leküldi az adatokat egy üzenetsorba, majd választ kap, amely megerősíti a tranzakció sikeres kezelését egy válaszsorba. Ha a forgalom kiugróan magas, és a háttérrendszer-kezelő nem tudja időben feldolgozni a hátralékelemeket, a rendszer a lejárt feladatokat a kézbesítetlen levelek várólistáján adja vissza. Az interaktív felhasználó értesítést kaphat arról, hogy a kért művelet a szokásosnál kicsit tovább tart, és a kérés ezután egy másik várólistára helyezhető egy feldolgozási útvonalhoz, ahol a végső feldolgozási eredményt e-mailben küldi el a felhasználónak.

Munkamenet-kompatibilis entitások lejárata

A munkamenet-kompatibilis üzenetsorok vagy témakörök előfizetései esetében az üzenetek a munkamenet szintjén vannak zárolva. Ha az üzenetek TTL-értéke lejár, a rendszer az adott munkamenethez kapcsolódó összes üzenetet elveti vagy kézbesítetlen levélként adja meg az entitás üzeneteinek lejárati beállításán engedélyezett holtbetűsítés alapján. Más szóval, ha a munkamenetben egyetlen üzenet van, amely átment a TTL-en, a munkamenet összes üzenete lejárt. Az üzenetek csak akkor járnak le, ha aktív figyelő van.

Ideiglenes entitások

A Service Bus-üzenetsorok, témakörök és előfizetések ideiglenes entitásokként hozhatók létre, amelyek automatikusan törlődnek, ha egy adott ideig nem használták őket.

Az automatikus törlés olyan fejlesztési és tesztelési forgatókönyvekben hasznos, amelyekben az entitások dinamikusan jönnek létre, és használat után nem törlődnek a teszt vagy hibakeresési futtatás valamilyen megszakadása miatt. Akkor is hasznos, ha egy alkalmazás dinamikus entitásokat, például válaszsort hoz létre a válaszok webkiszolgálói folyamatba való visszafogadásához, vagy egy viszonylag rövid élettartamú objektumba, ahol nehéz megbízhatóan megtisztítani ezeket az entitásokat, amikor az objektumpéldány eltűnik.

A funkció engedélyezve van a névtér üresjárati tulajdonságának automatikus törlésével. Ez a tulajdonság arra az időtartamra van beállítva, amíg egy entitásnak inaktívnak (nem használtnak) kell lennie, mielőtt automatikusan törölve lenne. A tulajdonság minimális értéke 5 perc.

Fontos

Az Azure Resource Manager zárolási szintjének CanNotDeletea névtéren vagy magasabb szinten történő beállítása nem akadályozza meg az entitások AutoDeleteOnIdle törlését. Ha nem szeretné, hogy az entitás törölve legyen, állítsa a tulajdonságot a AutoDeleteOnIdle következőre DataTime.MaxValue: .

Semmittevés

Az entitások (üzenetsorok, témakörök és előfizetések) tétlenségét az alábbiak szerint értékelte:

Entitás Mit tekintünk tétlennek?
Várakozási sor
  • Nincs küldés
  • Nincs fogadás
  • Nincsenek frissítések az üzenetsoron
  • Nincsenek ütemezett üzenetek
  • Nincs tallózás/betekintés
Topic
  • Nincs küldés
  • Nincs frissítés a témakörhöz
  • Nincsenek ütemezett üzenetek
  • Nincs művelet a témakör előfizetésén (lásd a következő sort)
Subscription
  • Nincs fogadás
  • Nincs frissítés az előfizetéshez
  • Nincs új szabály hozzáadva az előfizetéshez
  • Nincs tallózás/betekintés

Fontos

Ha automatikus továbbítási beállítással rendelkezik az üzenetsoron vagy az előfizetésen, akkor az egyenértékű azzal, hogy egy fogadó peform fogadja az üzenetsort vagy az előfizetést, és azok nem lesznek tétlenek.

SDK-k

Következő lépések

A Service Bus üzenetkezelésével kapcsolatos további információkért tekintse meg az alábbi cikkeket: