Jak zvládá DDS®🌀 zahlcení daty
Existují situace, kdy poskytovatelé dat generují tolik dat, že konzumenti nejsou schopni tolik dat zpracovat a jsou zahlcení daty.
Konzumenti tedy omezují rychlost systému, protože nezvládají zpracovávat tolik dat a potřebují, aby poskytovatelé na ně tolik netlačili – snaží se vytvořit protitlak (backpressure). Tato situace může vést až ke kolapsu systému.
V tomto videu 
vám řeknu, jakým způsobem je možné předcházet zahlcení daty.
Protože nechceme, aby se náš systém zhroutil, tak naším cílem je zahlcení daty nějak zvládnout.
Existují čtyři hlavní strategie, jak to provést.
- Udělejte konzumenta silnějšího
= zvyšujte zdroje, aby konzument zvládal data zpracovávat rychlostí, kterou je poskytovatel zasílá (vertikální škálování nebo horizontální škálování). - Ovládejte producenta
= potřebuje řídit producenta dat, aby zpomalil rychlost odesílání dat. Zde můžete použít strategie jako:
Konzument si data od poskytovatele vyžádá sám, když je na to připraven (pull mechanismus) místo toho, aby byla data posílána konzumentovi (push mechanismus). Takto to řeší např. Apache Kafka, která funguje jako nekonečný buffer. Omezení počtu dat, která odesíláme konzumentům najednou Zrušení zasílání dat, když je spotřebitel nemůže zpracovat. - Využijte vyrovnávací paměť
= dočasné shromažďování příchozích dat. Ale může to vést k přerůstání dostupné paměti - Zahazujte data
= o některá data přijdete zahozením některých příchozích dat, ale alespoň vám nezkolabuje celý systém.
Jakou strategii zvolit, bude záviset na aktuálním problému a budete muset přemýšlet o kompromisu mezi spotřebovanými zdroji, dobou odezvy a ztrátou dat. Je však užitečné porozumět konceptu zahlcení dat (backpreassure) a strategiím, jak to řešit, abyste dosáhly optimálního fungování systému.
DDS®
nabízí různé QoS, jako je RELIABILITY, HISTORY a RESOURCE_LIMITS, které lze vyladit tak, aby eliminovaly zahlcení konzumenta daty.
RELIABILITY řídí spolehlivost doručování dat mezi DataWriters a DataReaders. Lze ji nastavit na spolehlivost BEST_EFFORT nebo RELIABLE. BEST_EFFORT nepoužívá žádné zdroje CPU/paměť, aby bylo zajištěno spolehlivé doručení vzorků dat. RELIABLE konfigurace na druhé straně používá protokol založený na ack/nack, který spolehlivost doručení zabezpečuje.
RESOURCE_LIMITS řídí množství fyzické paměti přidělené DDS entitám. Pokud je použito nastavení BEST_EFFORT QoS, DataWriter zahodí vzorky, když se zaplní fronta na straně poskytovatele (velikost fronty je určená parametrem HISTORY a RESOURCE_LIMITS). Tato nastavení můžeme použít v případě, kdy jsou v systému pomalí konzumenti nebo poskytovatelé zapisují data velmi často a my jsme ochotni tolerovat nějakou ztrátu dat.
Existuje však jedno QoS, kterou můžeme použít na straně konzumenta pro vypořádání se s velkým množstvím dat, které nestačí konzument zpracovávat, nebo které nepotřebuje.
Jedná se o TIME_BASED_FILTER
Toto nastavení umožňuje konzumentovi určit minimální dobu mezi po sobě jdoucími vzorky dat. Vzorky, které jsou zasílány rychleji, nejsou zaslány nebo zpracovávány.
To jestli jsou data poskytovatelem zaslány závisí na nastavené spolehlivosti pro komunikaci. Pokud je komunikace spolehlivá, middleware doručí všechny vzorky bez ohledu na nastavení TIME_BASED_FILTER a filtrování probíhá na straně konzumenta.
Dále pokud k doručování dat více konzumentům použijete multicast, tak rychlost odesílání konzumentům je dána nejnižším nastaveným časem TIME_BASED_FILTER.
Tímto způsobem jsme tak schopni kontrolovat jak šířku pásma pro přenos dat, tak i paměť a výpočetní výkon použitý konzumenty.
Příkladem, kdy je tato QoS velmi užitečná, jsou pravidelné události, jako jsou například GPS data, kde si můžete dovolit ztratit některá data, protože nás zajímá hlavně poslední stav.
Pokud máte o DDS® zájem, tak mi napište, jaká je největší výzva, kterou aktuálně s DDS máte?
