Sdílet prostřednictvím

Azure Service Bus – Vypršení platnosti zpráv (Time to Live)

  • Článek

Datová část zprávy nebo příkaz nebo dotaz, které zpráva předá příjemci, je téměř vždy předmětem určité formy konečného termínu vypršení platnosti na úrovni aplikace. Po uplynutí takového termínu se obsah už nedoručí nebo se už požadovaná operace nespustí.

Pro vývojová a testovací prostředí, ve kterých se fronty a témata často používají v kontextu částečných spuštění aplikací nebo částí aplikace, je také žádoucí, aby se zprávy s vlákny automaticky odebraly, aby se další testovací běh mohl začít vyčistit.

Poznámka:

Pokud ještě neznáte koncepty služby Service Bus, podívejte se na koncepty služby Service Bus a fronty, témata a odběry služby Service Bus.

Vypršení platnosti každé jednotlivé zprávy lze řídit nastavením vlastnosti systému time-to-live , která určuje relativní dobu trvání. Vypršení platnosti se stane absolutním okamžikem, když je zpráva zapsána do fronty entity. V takovém případě vlastnost expires-at-utc přebírá hodnotu enqueued-time-utc + time-to-live. Nastavení hodnoty TTL (Time to Live) u zprostředkované zprávy se nevynucuje, pokud aktivně nenaslouchají žádní klienti.

Poznámka:

Zprostředkovatel nemusí okamžitě odebrat zprávy, jejichž platnost vypršela. Zprostředkovatel se může rozhodnout, že tyto zprávy lazily vypršet, a to na základě toho, jestli je entita v době vypršení platnosti zprávy aktivní. V důsledku toho můžou zákazníci při použití vypršení platnosti zprávy pozorovat nesprávný počet zpráv a během operace náhledu se tyto zprávy mohou dokonce zobrazit. Při příjmu zpráv však nebude zpráva s vypršenou platností zahrnuta.

Po vypršení platnosti rychlých zpráv ve standardu UTC se zprávy stanou způsobilými k načtení. Vypršení platnosti nemá vliv na zprávy, které jsou aktuálně uzamčené pro doručování. Tyto zprávy se pořád zpracovávají normálně. Pokud zámek vyprší nebo zpráva je opuštěná, platnost se projeví okamžitě. Když je zpráva zamčená, aplikace může mít zprávu, která vypršela. Bez ohledu na to, jestli je aplikace ochotná pokračovat ve zpracování, nebo se rozhodne zprávu opustit, je až do implementátoru.

Extrémně nízká hodnota TTL v řádu milisekund nebo sekund může způsobit vypršení platnosti zpráv před příjmem přijímacích aplikací. Vezměte v úvahu nejvyšší hodnotu TTL, která funguje pro vaši aplikaci.

Poznámka:

U plánovaných zpráv zadáte čas zařazení, ve kterém má být zpráva materializována ve frontě pro načtení. Čas odeslání zprávy do služby Service Bus se liší od okamžiku, kdy je zpráva zapsána do fronty. Doba vypršení platnosti zprávy závisí na době zařazení zprávy, nikoli v době odeslání zprávy do služby Service Bus. Proto platnost vyprší-at-utc je stále ve frontě času + time-to-live.

Pokud například nastavíte ScheduledEnqueueTimeUtc hodnotu 5 minut od UtcNowa TimeToLive na 10 minut, platnost zprávy vyprší po 5 + 10 = 15 minut od této chvíle. Zpráva se materializuje ve frontě po 5 minutách a 10minutový čítač začíná od této chvíle.

Vypršení platnosti na úrovni entity

Všechny zprávy odeslané do fronty nebo tématu podléhají výchozímu vypršení platnosti nastavenému na úrovni entity. Můžete ho také nastavit na portálu během vytváření a později upravit. Výchozí vypršení platnosti se používá pro všechny zprávy odeslané do entity, kde není explicitně nastaven časový limit. Výchozí vypršení platnosti také funguje jako strop pro hodnotu time-to-live. Zprávy s delším vypršením platnosti mezi časem, než je výchozí hodnota, se před zařazením do fronty bezobslužně upraví na výchozí hodnotu time-to-live zprávy.

Poznámka:

  • Výchozí hodnota time-to-live pro zprostředkovanou zprávu je největší možnou hodnotou pro 64bitové celé číslo se 64bitovou adresou, pokud není zadáno jinak.
  • Pro entity zasílání zpráv (fronty a témata) je výchozí čas vypršení platnosti také největší možnou hodnotou podepsaného 64bitového celého čísla pro úrovně Service Bus Standard a Premium . Výchozí (maximální) doba vypršení platnosti úrovně Basic je 14 dnů.
  • Pokud téma určuje menší hodnotu TTL než předplatné, použije se hodnota TTL tématu.

Zprávy s vypršenou platností je možné volitelně přesunout do fronty nedoručených zpráv. Toto nastavení můžete nakonfigurovat programově nebo pomocí webu Azure Portal. Pokud je tato možnost zakázaná, zprávy s vypršenou platností se zahodí. Zprávy s vypršenou platností přesunuté do fronty nedoručených zpráv lze odlišit od ostatních nedoručených zpráv vyhodnocením vlastnosti důvodu nedoručených zpráv, kterou zprostředkovatel ukládá v části vlastností uživatele.

Pokud je zpráva chráněna před vypršením platnosti při uzamčení a pokud je příznak nastaven u entity, zpráva se přesune do fronty nedoručených zpráv, protože zámek je opuštěný nebo vyprší jeho platnost. Pokud se ale zpráva úspěšně ustálí, nepřesune se, což předpokládá, že aplikace ji úspěšně zpracovala, i když došlo k nominálnímu vypršení platnosti. Další informace o uzamčení a vypořádání zpráv naleznete v tématu Přenosy zpráv, zámky a vypořádání.

Kombinace funkce time-to-live a automatického (a transakčního) nedoručeného dopisu při vypršení platnosti je cenným nástrojem pro zajištění jistoty, zda je úloha udělená obslužné rutině nebo skupině obslužných rutin v rámci konečného termínu načtena ke zpracování, protože je dosaženo konečného termínu.

Představte si například web, který potřebuje spolehlivě spouštět úlohy v back-endu s omezeným škálováním, a který občas zaznamená špičky provozu nebo chce být izolovaný proti epizodám dostupnosti tohoto back-endu. V běžném případě obslužná rutina na straně serveru pro odeslaná uživatelská data odešle informace do fronty a následně obdrží odpověď potvrzující úspěšné zpracování transakce do fronty odpovědí. Pokud dojde ke špičkám provozu a obslužná rutina back-endu nemůže zpracovat položky backlogu včas, vrátí se úlohy, jejichž platnost vypršela, ve frontě nedoručených zpráv. Interaktivní uživatel může být upozorněn, že požadovaná operace trvá o něco déle než obvykle, a žádost pak může být umístěna do jiné fronty pro cestu zpracování, kde se konečný výsledek zpracování odešle uživateli e-mailem.

Dočasné entity

Fronty, témata a odběry služby Service Bus je možné vytvořit jako dočasné entity, které se automaticky odeberou, když se po určitou dobu nepoužívaly.

Automatické vyčištění je užitečné ve scénářích vývoje a testování, ve kterých se entity vytvářejí dynamicky a po použití se nevyčistí, a to kvůli nějakému přerušení testovacího nebo ladění. Je také užitečné, když aplikace vytváří dynamické entity, jako je například fronta odpovědí, pro příjem odpovědí zpět do procesu webového serveru nebo do jiného relativně krátkodobého objektu, kde je obtížné spolehlivě vyčistit tyto entity, když instance objektu zmizí.

Funkce je povolena pomocí automatického odstranění u nečinné vlastnosti entity. Tato vlastnost je nastavená na dobu trvání, po kterou musí být entita nečinná (nepoužitá), než se automaticky odstraní. Minimální hodnota této vlastnosti je 5 minut.

Důležité

Nastavení úrovně uzamčení Azure Resource Manageru na CanNotDeleteobor názvů nebo na vyšší úrovni nezabrání odstranění entit AutoDeleteOnIdle . Pokud nechcete, aby byla entita odstraněna, nastavte AutoDeleteOnIdle vlastnost na DataTime.MaxValuehodnotu .

Nečinnost

Tady je, co se považuje za nečinnost entit (fronty, témata a odběry):

Entity Co se považuje za nečinné
Fronta
  • Žádné odesílání
  • Žádné přijetí
  • Žádné aktualizace fronty
  • Žádné naplánované zprávy
  • Bez procházení nebo náhledu
Téma
  • Žádné odesílání
  • Žádné aktualizace tématu
  • Žádné naplánované zprávy
  • Žádné operace s odběry tématu (viz další řádek)
Předplatné
  • Žádné přijetí
  • Žádné aktualizace předplatného
  • Do předplatného se nepřidávají žádná nová pravidla.
  • Bez procházení nebo náhledu

Důležité

Pokud máte nastavení automatického předávání ve frontě nebo předplatném, je to ekvivalentem toho, že příjemce peform přijímá ve frontě nebo předplatném a nebude nečinný.

Sady SDK

Další kroky

Další informace o zasílání zpráv služby Service Bus najdete v následujících článcích: