Jan Mikoláš
Slovník pojmů
Eventual Consistency
Výsledná neboli postupná konzistence připouští krátkodobě rozdílné pohledy na data. Jde o vědomou vlastnost s měřitelnou hranicí, nikoli o omluvu libovolně chybných dat.
Stručná definice
Změna je platná dříve, než ji uvidí všechny modely.
Aplikace může potvrdit změnu v jednom autoritativním úložišti a do dalších reprezentací ji přenést asynchronně. Po krátkou dobu pak databáze objednávek říká „zaplaceno“, zatímco reporting, fulltextový index nebo read model stále ukazuje starý stav. Pokud doručování pokračuje, chyby se opakují a nevznikají nové konfliktní zápisy, odvozené modely se nakonec s autoritou shodnou.
Eventual Consistency neříká, že všechny mezistavy jsou businessově přijatelné ani jak rychle ke shodě dojde. Každý tok proto potřebuje vlastní toleranci zpoždění: sekundy mohou být přijatelné pro report, ale nikoli pro opakované stržení platby nebo kontrolu posledního kusu skladu.
Jaký problém řeší
Distribuované části systému nemohou vždy změnit stav současně.
Síťové volání, asynchronní consumer i aktualizace indexu mají latenci a mohou dočasně selhat. Okamžitá globální shoda by často vyžadovala silnější koordinaci, nižší dostupnost nebo delší odezvu.
- read model optimalizovaný pro rychlé zobrazení objednávky se aktualizuje událostí
- Elasticsearch obdrží změnu produktu až po potvrzení primární databáze
- cache může do vypršení nebo invalidace vracet předchozí hodnotu
- reporting a datový sklad zpracovávají změny v dávkách nebo přes frontu
- samostatné služby potvrzují své lokální kroky v různých okamžicích
Praktický příklad a diagram
Zaplacená objednávka a opožděný read model
Platební callback idempotentně změní objednávku order-42 v autoritativní databázi na paid. Ve stejné spolehlivé integrační hranici vznikne zpráva PaymentConfirmed a putuje přes frontu k consumeru reportingu. API pro detail platby může číst autoritativní stav okamžitě, zatímco dashboard postavený nad read modelem ještě několik sekund ukazuje pending.
První pokus consumeru selže kvůli dočasně nedostupnému úložišti. Řízený retry zprávu zpracuje podruhé, read model se změní na paid a oba pohledy se znovu shodují. Toto okno není samo o sobě chyba. Chybou by bylo nemít limit očekávaného zpoždění, ztratit zprávu bez alertu nebo uživateli tvrdit, že starší dashboard je autoritativním potvrzením platby.
Textový diagram a jeho alternativa
Authoritative Order DB
order-42 = PAID
↓ PaymentConfirmed
Queue
↓ Consumer / retry
Reporting read model
PENDING → PAIDJak funguje
Od autoritativního zápisu k opětovné shodě
Sekvence je textovou alternativou diagramu a ukazuje jednu běžnou implementaci, nikoli jediný možný model konzistence.
- Lokální potvrzení Databázová transakce uloží změnu objednávky v systému, který je pro její stav autoritou. Kritický lokální invariant zůstává chráněný okamžitě.
- Asynchronní propagace Událost, change feed nebo plánovaná synchronizace přenáší změnu k odvozeným modelům. Zpoždění je očekávanou částí kontraktu.
- Dočasně staré čtení Read model, index nebo jiná služba může vrátit předchozí hodnotu. Rozhraní má vědět, který zdroj čte, a pro citlivé rozhodnutí případně použít autoritativní cestu.
- Opakování po chybě Retry s backoffem a idempotencí umožní consumeru dokončit stejnou změnu bez druhého businessového účinku. Trvalá chyba musí být dohledatelná.
- Konvergence Po úspěšném zpracování se reprezentace shodnou. Pokud mohou probíhat souběžné zápisy na více místech, systém navíc potřebuje pravidla pořadí a řešení konfliktů.
Hlavní části a principy
Konzistence je konkrétní kontrakt pro konkrétní data.
Jedna aplikace může současně používat silnou lokální konzistenci pro platbu a výslednou konzistenci pro vyhledávání nebo reporting.
Autoritativní zdroj
Musí být jasné, který systém rozhoduje o pravdě daného údaje. Kopie, cache a projekce se z něj opravují; dva neřízené zdroje pravdy vytvářejí konflikty, které samotná eventual consistency nevyřeší.
Bounded staleness v aplikaci
Business požadavek má vyjádřit očekávané zpoždění, například 99 % změn do pěti sekund a žádná starší než minutu bez alertu. Obecná eventual consistency sama horní mez stáří negarantuje.
Read model a projekce
Odvozený model ukládá data ve tvaru vhodném pro konkrétní dotaz. Jeho rebuild nebo opakované zpracování musí respektovat pořadí, verzi a idempotenci, aby starší událost nepřepsala novější výsledek.
Doručení a oprava
Fronta zpráv může tlumit výpadek a uchovat backlog. Nestačí však jen zprávu odeslat: systém sleduje lag, chybové zprávy, dead-letter stav a možnost kontrolovaného replaye nebo reconciliation.
Uživatelský kontrakt
UI může zobrazit stav „zpracovává se“, čas poslední aktualizace nebo optimistickou změnu s možností opravy. Read-your-writes lze někdy zajistit čtením z autority nebo dočasným přenesením právě potvrzené hodnoty.
Výhody a omezení
Menší koordinace přináší období nejistoty, které musí být viditelné.
Možné přínosy
- rychlejší potvrzení primárního zápisu bez čekání na všechny odvozené systémy
- odolnější zpracování dočasného výpadku pomocí backlogu a pozdějšího dohnání
- nezávislé škálování čtecích modelů, indexů a integračních consumerů
- modely optimalizované pro různé dotazy bez rozšíření jedné globální transakce
Omezení a časté chyby
- uživatelské rozhraní může krátce zobrazit starší data nebo dva odlišné stavy
- bez autoritativního zdroje nelze bezpečně určit, která hodnota se má prosadit
- neomezený retry může vytvářet nekonečný backlog a skrýt trvalou chybu kontraktu
- chybějící pořadí nebo verze dovolí starší zprávě přepsat novější projekci
- použití výsledné konzistence na platbu či sklad bez analýzy invariantů může způsobit skutečnou business chybu
Rozdíly proti podobným konceptům
Eventual consistency není transakce, cache ani Event Sourcing.
ACID transakce chrání související změny v podporované lokální hranici a poskytuje konkrétní izolační chování. Eventual consistency popisuje, jak se v čase srovnávají oddělené reprezentace; může následovat po lokálním ACID commitu, není jeho slabším názvem ani náhradou tam, kde invariant musí platit okamžitě napříč všemi čteními.
Cache je dočasná kopie určená zejména ke zrychlení čtení. Může vykazovat výslednou konzistenci, ale stejné chování mají i trvalé read modely, repliky a jiné služby. Invalidace cache je jeden konkrétní mechanismus, nikoli definice modelu konzistence.
Event Sourcing ukládá stav jako historii událostí. Asynchronní projekce nad touto historií bývají výsledně konzistentní, ale oba koncepty jsou nezávislé: eventual consistency může vzniknout bez event store a Event Sourcing může v jednoduchém procesu aktualizovat projekci synchronně.
Provoz a UX
Zpoždění se musí měřit, komunikovat a umět opravit.
„Nakonec“ není provozní cíl. Tým potřebuje rozpoznat běžné zpoždění od incidentu.
- definovat autoritativní zdroj a konzistenční požadavek pro každý důležitý údaj
- měřit end-to-end lag, stáří nejstarší zprávy a rozdíl mezi autoritou a projekcí
- navrhnout idempotentní consumer, pořadí a ochranu proti zastaralému zápisu
- zobrazit uživateli průběžný stav tam, kde se výsledek nemůže projevit okamžitě
- mít reconciliation nebo rebuild, který dokáže odvozený model znovu srovnat
- testovat zpoždění, duplicitu, změnu pořadí, výpadek consumeru i trvale chybnou zprávu
Časté otázky
Výsledná konzistence v praxi
Znamená Eventual Consistency, že systém vrací chybná data?
Ne nutně. Může vědomě vrátit starší, ale očekávanou reprezentaci. Chybou je porušení definovaného business pravidla, překročení tolerovaného zpoždění nebo stav, který se bez zásahu už nesrovná.
Jak dlouho může synchronizace trvat?
Samotný pojem horní mez neurčuje. Konkrétní systém ji musí stanovit podle rizika a měřit, například běžně sekundy a alert při zpoždění nad jednu minutu.
Je eventual consistency opakem ACID?
Ne. Jedna služba může změnu uložit v lokální ACID transakci a následně ji asynchronně propagovat do výsledně konzistentních modelů. Pojmy popisují jiné hranice a vlastnosti.
Je každá cache výsledně konzistentní?
Ne automaticky. Některá cache má jen TTL, jiná se invaliduje nebo zapisuje současně. Cache je druh kopie; eventual consistency popisuje očekávaný vztah a konvergenci více stavů v čase.
Co když consumer jednu změnu nikdy nezpracuje?
Pak systém nekonverguje a nejde o splněnou garanci. Potřebuje monitoring, omezený retry, dohledatelnou chybu a mechanismus opravy nebo opětovného sestavení modelu.
Jak navrhuji konzistenci
Rozlišuji okamžitá business pravidla od dat, která mohou bezpečně chvíli dobíhat.
U distribuovaných toků určuji autoritativní stav, očekávané zpoždění, chování UI i způsob obnovy po chybě consumeru.