Share via

Přehled front

  • Článek

Tato část představuje obecné a základní koncepty za frontou komunikace. Následující části se týkají podrobností o tom, jak jsou zde popsané koncepty řízení front manifestovány ve Službě Windows Communication Foundation (WCF).

Základní koncepty řízení front

Při navrhování distribuované aplikace je důležité zvolit správný přenos komunikace mezi službami a klienty. Druh dopravy, který se má použít, ovlivňuje několik faktorů. Jedním z důležitých faktorů – izolace mezi službou, klientem a přenosem – určuje použití přenosu ve frontě nebo přímého přenosu, například TCP nebo HTTP. Vzhledem k povaze přímých přenosů, jako je TCP a HTTP, se komunikace úplně zastaví, pokud služba nebo klient přestane fungovat nebo pokud síť selže. Služba, klient a síť musí běžet současně, aby aplikace fungovala. Přenosy ve frontě poskytují izolaci, což znamená, že pokud služba nebo klient selže nebo pokud komunikační propojení mezi nimi selže, klient a služba můžou dál fungovat.

Fronty poskytují spolehlivou komunikaci i v případě selhání komunikačních stran nebo sítě. Fronty zaznamenávají a doručují zprávy vyměňované mezi komunikujícími stranami. Fronty jsou obvykle podporovány nějakým druhem úložiště, které může být nestálé nebo odolné. Fronty ukládají zprávy z klienta jménem služby a později tyto zprávy předávají službě. Fronty nepřímých připojení zajišťují izolaci selhání některou stranou, takže je upřednostňovaným komunikačním mechanismem pro systémy s vysokou dostupností a odpojenými službami. Nepřímí se s sebou nese náklady na vysokou latenci. Latence je časové zpoždění mezi časem, kdy klient odešle zprávu, a časem, kdy ji služba obdrží. To znamená, že po odeslání zprávy nevíte, kdy se tato zpráva může zpracovat. Většina frontových aplikací se vyrovnává s vysokou latencí. Následující obrázek znázorňuje koncepční model komunikace ve frontě.

Model of queued communication

Koncepční model komunikace ve frontě

Ve skutečnosti je fronta distribuovaným konceptem. Jako takové mohou být místní pro obě strany nebo vzdálené pro obě strany. Fronta je obvykle místní pro službu. V této konfiguraci nemůže klient záviset na připojení ke vzdálené frontě, aby byl neustále dostupný. Podobně musí být fronta dostupná nezávisle na dostupnosti služby, která čte z fronty. Správce front spravuje kolekci front. Zodpovídá za příjem zpráv odeslaných do front od jiných správců front. Zodpovídá také za správu připojení ke vzdáleným frontám a přenosu zpráv do těchto vzdálených front. Aby se zajistila dostupnost front bez ohledu na selhání aplikací klienta nebo služby, správce front se obvykle spouští jako externí služba.

Když klient odešle zprávu do fronty, odešle zprávu do cílové fronty, což je fronta spravovaná správcem front služby. Správce front v klientovi odešle zprávu do fronty přenosu (nebo odchozí). Fronta přenosu je fronta ve správci front klienta, která ukládá zprávy pro přenos do cílové fronty. Správce front pak najde cestu ke správci fronty, který vlastní cílovou frontu, a přenese do ní zprávu. Aby správci front zajistili spolehlivou komunikaci, implementují spolehlivý přenosový protokol, aby se zabránilo ztrátě dat. Správce cílové fronty přijímá zprávy adresované cílové frontě, které vlastní, a ukládá zprávy. Služba odesílá požadavky na čtení z cílové fronty, kdy správce fronty pak zprávu doručí do cílové aplikace. Následující obrázek znázorňuje komunikaci mezi čtyřmi stranami.

Queued Application Diagram

Komunikace ve frontě v typickém scénáři nasazení

Správce front proto poskytuje požadovanou izolaci, aby odesílatel a příjemce mohli nezávisle selhat, aniž by to mělo vliv na skutečnou komunikaci. Výhodou dodatečných nepřímých informací, které fronty poskytují, také umožňuje čtení více instancí aplikace ze stejné fronty, aby zemědělství fungovalo mezi uzly s vyšší propustností. Proto není neobvyklé, že se fronty používají k dosažení vyšších požadavků na škálování a propustnost.

Fronty a transakce

Transakce umožňují seskupit sadu operací, aby pokud jedna operace selže, všechny operace selžou. Příkladem použití transakcí je, když osoba používá atm k převodu 1 000 USD ze svého účtu úspory na svůj kontrolní účet. To zahrnuje následující operace:

  • Stažení 1 000 USD z účtu úspory

  • Vklad 1 000 USD na kontrolní účet.

Pokud první operace proběhne úspěšně a 1 000 USD se z účtu úspory stáhne, ale druhá operace selže, ztratí se 1 000 USD, protože už byla stažena z účtu úspory. Pokud chcete účty zachovat v platném stavu, pokud jedna operace selže, musí obě operace selhat.

V transakčním zasílání zpráv lze zprávy odesílat do fronty a přijímat z fronty v rámci transakce. Pokud je tedy zpráva odeslána v transakci a transakce je vrácena zpět, výsledek je, jako by zpráva nebyla nikdy odeslána do fronty. Podobně pokud je zpráva přijata v transakci a transakce se vrátí zpět, výsledek je, jako by zpráva nebyla nikdy přijata. Zpráva zůstane ve frontě, kterou chcete přečíst.

Z důvodu vysoké latence nemáte při odesílání zprávy žádný způsob, jak dlouho trvá dosažení cílové fronty, ani nevíte, jak dlouho trvá, než služba zprávu zpracuje. Z tohoto důvodu nechcete použít jednu transakci k odeslání zprávy, přijetí zprávy a zpracování zprávy. Tím se vytvoří transakce, která není potvrzena za neurčitou dobu. Když klient a služba komunikují prostřednictvím fronty pomocí transakce, jsou zapojeny dvě transakce: jedna v klientovi a jedna ve službě. Následující obrázek znázorňuje hranice transakcí v typické komunikaci ve frontě.

Queue with transactions

Komunikace ve frontě zobrazující samostatné transakce pro zachytávání a doručování

Transakce klienta zpracovává a odesílá zprávu. Při potvrzení transakce je zpráva ve frontě přenosu. Ve službě transakce přečte zprávu z cílové fronty, zpracuje zprávu a pak potvrdí transakci. Pokud během zpracování dojde k chybě, zpráva se vrátí zpět a umístí se do cílové fronty.

Asynchronní komunikace pomocí front

Fronty poskytují asynchronní komunikační prostředky. Aplikace, které odesílají zprávy pomocí front, nemůžou čekat na přijetí a zpracování zprávy příjemcem kvůli vysoké latenci zavedené správcem front. Zprávy můžou zůstat ve frontě delší dobu, než je zamýšlená aplikace. Aby se tomu zabránilo, může aplikace ve zprávě zadat hodnotu Time-To-Live. Tato hodnota určuje, jak dlouho má zpráva zůstat ve frontě přenosu. Pokud je tato časová hodnota překročena a zpráva stále nebyla odeslána do cílové fronty, lze zprávu přenést do fronty nedoručených zpráv.

Když odesílatel odešle zprávu, návrat z operace odeslání znamená, že zpráva byla odeslána pouze do fronty přenosu odesílatele. Pokud dojde k selhání při získávání zprávy do cílové fronty, odesílající aplikace o ní nemůže okamžitě vědět. Pokud si chcete takové chyby poznamenat, zpráva, která selhala, se přenese do fronty nedoručených zpráv.

Všechny chyby, jako je například zpráva, která se nedaří spojit s cílovou frontou nebo vypršením platnosti time-to-Live, se musí zpracovat samostatně. Není tedy neobvyklé, že aplikace zařazené do fronty zapisuje dvě sady logiky:

  • Normální logika klienta a služby pro odesílání a příjem zpráv.

  • Logika kompenzace pro zpracování zpráv z neúspěšného přenosu nebo doručení

Tyto koncepty jsou popsány v následujících částech.

Programování fronty nedoručených zpráv

Fronty nedoručených zpráv obsahují zprávy, které se nepodařilo dosáhnout cílové fronty z různých důvodů. Důvody můžou být v rozsahu od zpráv s vypršenou platností až po problémy s připojením, které brání přenosu zprávy do cílové fronty.

Aplikace obvykle může číst zprávy z celé systémové fronty nedoručených zpráv, určit, co se nepovedlo, a provést odpovídající akci, například opravit chyby a znovu odeslat zprávu nebo si ji poznamenejte.

Programování fronty otrávených zpráv

Jakmile se zpráva převede do cílové fronty, může se službě opakovaně nepodaří zprávu zpracovat. Například aplikace, která čte zprávu z fronty v rámci transakce a aktualizace databáze může databázi dočasně odpojit. V tomto případě se transakce vrátí zpět, vytvoří se nová transakce a zpráva se znovu načte z fronty. Druhý pokus může být úspěšný nebo neúspěšný. V některých případech může v závislosti na příčině chyby zpráva do aplikace opakovaně selhat. V tomto případě se zpráva považuje za "jed". Tyto zprávy se přesunou do otrávené fronty, kterou může číst aplikace pro zpracování jedů.

Viz také