Zasíláte aktuální stav nově připojeným aplikacím automaticky?

U publish – subscribe modelu komunikace, kde jsou využívány topiky, tak v případě, že subscriber není přítomen, tak znova již data aplikace nedostanou.

Poslání posledního stavu nově připojené aplikaci je velice užitečné, protože nově připojená aplikace nemusí čekat na změnu a dozví se stav systému hned po připojení.

V tomto videu🎞️👇 se podíváme na to, jak se to řeší u technologie DDS®🌀.

Tato funkčnost je tak používaná, že jí implementují i další technologie.

👉 Například MQTT to řeší označením zprávy, že je určena k znovuposlání novým aplikacím (retained flag). Jedná se o jednu zprávu a určuje se na úrovni topiku.

👉 Technologie Apache Kafka®, šla ještě dál, ta si pamatuje všechny zprávy pro daný topik po stanovenou dobu. Consumenti si pak vyčtou co potřebují, klidně poslední uloženou zprávu daného topiku.

V kterých případech se toho dá využít?
👉 Když potřebuji mít informaci o posledním stavu, když jsou data zasílána nepravidelně, nebo konfiguraci zařízení.
👉 Když potřebuji získat data i v případě, kdy jsem byl nedostupný.

Jsem tak schopen dosáhnout volné vazby v čase (time decoupling), protože příjemce dat nemusí být spuštěn v čase, kdy jsou data zapisována. Proto ale potřebuji data někde ukládat.

V případě MQTT a Apache Kafky je to na brokeru, ale v případě DDS🌀, kdy žádný broker není je to prováděno nastavením QoS parametrů následovně.

Použitím DURABILITY QoS, která určuje životnost vzorků jednotlivých instancí v rámci daného topicu pro aplikace, které se připojí později.

Tento parametr lze nastavit tak, že data označíme jako:
1️⃣ Volatile: Data nejsou uchovávána
2️⃣ Transient Local: Data jsou uchovávána po tu dobu co existuje poskytovatel dat, který je zasílá v případě, kdy se připojí nový příjemce dat.
3️⃣ Transient: Data jsou uchovávána pomocí další služby (durability/persistance service), která se o zaslání postará, i když vypneme poskytovatele dat.
4️⃣ Persistent: Data jsou uchovávána pomocí další služby, která se o zaslání postará, ale s využitím databáze, když vypneme restartujeme vše (i když vypneme persistance servcie).

Kolik je toho ukládáno a znovu zasíláno je určeno QoS parameterem HISTORY.

Pomocí QoS parametru DURABILITY a HISTORY jsme tak schopni ovlivnit dostupnost dat. Tedy zdali nově připojená aplikace obdrží data, která již byla zaslána a kolik.

Jestli vás technologie DDS zajímá, tak si stáhněte myšlenkovou mapu o DDS ze stránky www.pavelpohanka.cz/dds, kde se dozvíte zdali je technologie vhodná pro váš systém nebo ne.

PP
Author: PP

Podobné příspěvky

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.