Moderní distribuované systémy jsou o kompromisech. Výkon, spolehlivost, škálovatelnost a konzistence nejsou zadarmo – vždy někde platíte cenu. Zde přichází na řadu teorém CAP: je to výchozí bod pro pochopení nevyhnutelných kompromisů v distribuovaném návrhu.  Proč je teorém CAP pravdivý? Co to vlastně vysvětluje? A hlavně, stačí to? V tomto příspěvku prozkoumáme teorém CAP, jeho omezení, kritiku, s níž se setkal, a jak novější nápady, jako je PACELC, posouvají konverzaci kupředu. Pojďme se ponořit.  Věta CAP  První verze teorému CAP začala jako debata mezi   . Postupem času se však vyvinul, získal formální důkaz a vygradoval, aby se stal teorémem CAP, jak jej známe dnes. ACID vs. BASE  CAP teorém říká, že   : distribuovaný systém může uspokojit maximálně dvě ze tří vlastností současně   Konzistence   Dostupnost   Tolerance oddílů  Toto omezení nutí inženýry k tvrdým kompromisům v závislosti na cílech systému a realitě jejich distribuovaných prostředí.  Konzistence   Konzistence v CAP není stejná jako konzistence v   . V CAP teorému to odkazuje na   nebo   . To znamená, že   , bez ohledu na to, který uzel požadavek zpracovává. To znamená, že každá operace čtení odráží poslední zápis bez ohledu na to, na který uzel se dotazujete. ACID transakcích linearizovatelnost silnou konzistenci všechny uzly v distribuovaném systému musí vždy poskytovat jediný aktuální pohled na data  💡 Konzistence v ACID se na druhou stranu zaměřuje na zajištění toho, aby transakce přenesla databázi z jednoho platného stavu do jiného platného podle pravidel definovaných schématem databáze. Jde spíše o vynucení omezení integrity (jako jsou cizí klíče, jedinečná omezení atd.) a zajištění, aby databáze nezůstala v neplatném stavu, a to ani v případě selhání.  Dostupnost   Dostupnost v CAP znamená, že   . Jinými slovy, pokud zdravý uzel obdrží požadavek, musí jej zpracovat a odpovědět na něj. CAP však   – pouze zajišťuje, že uzel neselže tiše (například v   mohou uzly reagovat zastaralými daty během oddílu, aby byla zajištěna dostupnost ). každý neselhávající uzel musí vrátit odpověď na každý požadavek, který obdrží, bez ohledu na síťové oddíly nezaručuje, že odpověď bude vždy „správná“ nebo aktuální systému AP  💡 Eric Brewer (původní autor CAP) tuto vlastnost původně popsal trochu flexibilněji jako: "téměř všechny dotazy by měly dostat odpověď". Ve formálním důkazu CAP však byla dostupnost přísnější a vyžadovala „odpověď na každý dotaz, pokud je uzel, který jej zpracovává, zdravý“.  V praxi však dostupnost není absolutní zárukou – často závisí na omezeních specifických pro daný systém, například jak dlouho jste ochotni čekat na odpověď. U systémů v reálném světě hraje   zásadní roli při utváření vaší SLA (smlouva o úrovni služeb), i když samotná CAP nezohledňuje latenci. Více o tom v   . doba odezvy (nebo časové limity) tomto příspěvku na blogu  Tolerance rozdělení   Tolerance oddílu je o přežití selhání sítě.   K oddílu dochází, když uzly nemohou komunikovat kvůli zahozeným paketům, časovým limitům nebo rozdělením sítě. Pokud uzly nemohou komunikovat kvůli rozdělení sítě (oddílu), systém musí stále splňovat své záruky konzistence nebo dostupnosti v závislosti na volbě návrhu.  Distribuované systémy nežijí v pohádkovém světě s dokonalými sítěmi. Pakety jsou zahazovány, dochází k vypršení časového limitu a špičkám latence se nelze vyhnout. Z tohoto důvodu   – k oddílům dříve nebo později dojde, takže si nemůžete "rozhodnout" ignorovat to, bez ohledu na to, jak lákavě to může znít. je tolerance oddílů nesmlouvavá v žádném distribuovaném systému  V CAP tolerance oddílů neznamená, že systém běží, jako by se nic nestalo. Znamená to, že systém se musí rozhodnout, zda upřednostní dostupnost (AP) nebo konzistenci (CP) během rozdělení. Pokud byste ignorovali toleranci oddílů, v podstatě byste budovali nedistribuovaný monolitický systém.  CAP vysvětlil  Nejjednodušší způsob, jak porozumět CAP, je zvážit   – situaci, kdy dvě části distribuovaného systému spolu nemohou komunikovat. V takovém scénáři má systém tři možné výsledky: síťový oddíl    zatímco druhá je izolovaná, budou mít obě části nekonzistentní stavy. To má za následek ztrátu   . Pokud jedna část systému přijímá aktualizace, C (konzistence)    , musí zablokovat aktualizace v jedné nebo obou částech oddílu, aby byl zajištěn jednotný stav napříč všemi uzly. To vede ke ztrátě   protože některé požadavky budou zamítnuty nebo odloženy na neurčito. Pokud se systém rozhodne zůstat konzistentní A (Availability),    a konzistentní (C), aniž by toleroval oddíl (P), není skutečně distribuován. To by vyžadovalo, aby uzly interagovaly a sladily stav, což během rozdělení není možné. Pokud se systém rozhodne zůstat dostupný (A)    tedy může systém uspokojit pouze   . Jakmile je rozdělení vyřešeno (tj. uzly opět interagují), systém může znovu získat všechny tři vlastnosti, ale   jsou kompromisy nevyhnutelné. Během rozdělení dvě ze tří vlastností (C, A nebo P) během samotného rozdělení  Důsledky věty  Důsledkem teorému pro asynchronní systémy je, že jsou možné pouze tři kombinace konzistence, dostupnosti a tolerance oddílů:  AP (dostupnost + tolerance oddílů)  Systémy tohoto typu odpovídají na dotazy, ale vrácená data nemusí být vždy aktuální, s pomalejšími aktualizacemi dat, ale „vždy“ dostupnými. Příklady takového systému jsou DNS, DynamoDB a Cassandra.  CP (konzistence + tolerance oddílů)  Systémy tohoto typu vždy vracejí aktuální data, ale některé nebo dokonce všechny uzly v systému nemusí reagovat, pokud jsou rozděleny. Poskytuje atomické aktualizace, ale může vést k vypršení časového limitu. NoSQL databáze jako Google BigTable, MongoDB, HBase a Redis jsou systémy tohoto typu.  CA (konzistence + dostupnost)  Systémy tohoto typu vždy vracejí aktuální data, když nejsou žádné oddíly. Kvůli poslednímu omezení se takové systémy obvykle používají pouze v rámci jednoho stroje. Příkladem jsou klasické relační databáze.  Ve skutečnosti volíme mezi CP a AP, protože CA je v podstatě monolit bez oddílů. U rozsáhlých systémů nemohou návrháři opustit P, a proto mají obtížnou volbu mezi C a A.  V CA selhání uzlu znamená úplnou nedostupnost služby. To však nezakazuje škálovatelnost, protože můžeme klonovat nezávislé monolity a rozložit na ně zátěž  Kritika teorému CAP  Teorém CAP byl základním konceptem v distribuovaných systémech, ale není bez omezení. Přes veškerou svou jasnost při prezentaci myšlenky kompromisů byl teorém SZP často kritizován za přílišné zjednodušování složité reality, což vedlo k nedorozuměním a nesprávným aplikacím.  1. Kompromisy platí pouze během oddílů  Jednou z nejběžnějších kritik je, že kompromisy teorému CAP – výběr mezi   a   – platí pouze tehdy, když skutečně dojde k   . V normálním provozu, kdy je síť stabilní a neexistují žádné oddíly, neexistuje žádný vlastní kompromis mezi konzistencí a dostupností. konzistencí (C) dostupností (A) rozdělení sítě (P)  Navíc tyto kompromisy nejsou univerzální v celém systému. V rámci stejného distribuovaného systému:  Různé části systému mohou mít různé kompromisy v závislosti na kontextu (jako je poloha uživatele, typ dat).  Specifické operace mohou upřednostňovat konzistenci, zatímco jiné upřednostňují dostupnost.  Rozhodnutí se mohou za běhu lišit v závislosti na faktorech, jako je zatížení, latence nebo požadavky uživatele.  Tato nuance se často ztrácí v diskusích o CAP na vysoké úrovni, což vede k příliš zjednodušené klasifikaci systémů jako „CP“ nebo „AP“.  2. CAP Ignoruje latenci  Další důležitou kritikou je, že teorém CAP nebere v úvahu   , i když jsou latence a dělení v praxi hluboce propojeny. Například: latenci  Pomalá síť (vysoká latence) může vypadat k nerozeznání od oddílu.  Časové limity – používané k detekci poruch – jsou subjektivní a silně závisí na návrhu systému a podmínkách sítě. To, co jeden systém definuje jako „oddíl“, může být pro jiný pouze přechodné zpoždění.  V distribuovaných systémech v reálném světě, když dojde k rozdělení nebo vysoké latenci, musí systém učinit rozhodnutí během   : upřednostnit dostupnost vrácením pravděpodobně zastaralého výsledku nebo upřednostnit konzistenci delším čekáním (a potenciálně selháním odpovědi). Binární pohled CAP nezachycuje složitost těchto rozhodnutí. časového limitu  3. Vlastnosti CAP nejsou binární  Teorém CAP představuje konzistenci, dostupnost a toleranci oddílů jako binární vlastnosti – buď je máte, nebo ne. Ale v praxi   : všechny tři vlastnosti existují na spektru    není binární vlastnost „on/off“ – pohybuje se od 0 % do 100 %. Systém může například zaručit 99,99% dostupnost, ale stále to umožňuje malá období nedostupnosti. Dostupnost    má různé úrovně, od případné konzistence přes kauzální konzistenci až po silnou konzistenci. Ne každá aplikace vyžaduje plnou linearizovatelnost. Konzistence    sama o sobě není jednoznačná událost. Systémy se mohou neshodnout na tom, zda oddíl existuje (jako jeden uzel vidí vypršení časového limitu jako selhání, zatímco jiný pokračuje v normálním provozu). Tolerance oddílů  Díky této nepřetržité povaze vlastností je CAP příliš zjednodušující pro modelování složitosti moderních distribuovaných systémů.  PACELCova věta  Přestože CAP způsobila revoluci v našem chápání kompromisů v distribuovaných systémech, není to poslední slovo na toto téma.   je považována za alternativní přístup k návrhu distribuovaných systémů. Je založen na modelu CAP, ale kromě konzistence, dostupnosti a tolerance oddílů zahrnuje také latenci a logické vyloučení mezi kombinacemi těchto konceptů. PACELCova věta popsaná Danielem J. Abadim  PACELC zavádí dva odlišné režimy provozu pro distribuované systémy:    (   ): Jaký kompromis systém udělá, když dojde k rozdělení? Zde se vracíme ke klasickému kompromisu CAP mezi   a   . Režim rozdělení PAC dostupností (A) konzistencí (C)    (   ): Jaký kompromis dělá systém, když není žádný oddíl a síť funguje normálně? V tomto režimu systém čelí jinému kompromisu — mezi   a   .  Else mode ELC latencí (L) konzistencí (C)  Kompromis mezi latencí a konzistencí  Zatímco oddíly jsou v distribuovaných systémech nevyhnutelné, jsou vzácné ve srovnání s problémy, které se objevují během normálního provozu. V moderních distribuovaných systémech je   často větším úzkým hrdlem než síťové oddíly, zejména u aplikací v globálním měřítku. To je oblast, na kterou se   zaměřuje – řešením kompromisů, ke kterým dochází, když systém funguje bez oddílů. Na rozdíl od CAP, která se zaměřuje výhradně na chování během scénářů selhání, PACELC zdůrazňuje rozhodnutí, která musí architekti každý den učinit, aby vyvážili   a   : latence PACELC latenci (L) konzistenci (C)    vyžaduje koordinaci a synchronizaci mezi uzly, aby byl zachován jednotný pohled na data. Tato režie přináší zpoždění a zpomaluje dobu odezvy. Silná konzistence    (jako ty, které přijímají případnou konzistenci) upřednostňují rychlost uvolněním záruk konzistence. Tyto systémy reagují rychleji, ale občas mohou vrátit zastaralá nebo nekonzistentní data. Systémy s nízkou latencí  Rozšířením konverzace mimo oddíly tak, aby zahrnovala běžný provoz, PACELC zajišťuje, že s každodenním výkonem distribuovaných systémů bude zacházeno s takovou důležitostí, jakou si zaslouží.  Zabalit to  Formulace teorému CAP byla významnou událostí v komunitě a studie jeho dopadu na návrh distribuovaných systémů ukázaly, že návrháři distribuovaných systémů by neměli omezovat systém na dvě vlastnosti – měli by se snažit maximalizovat záruky požadované v každé z nich. konkrétní případ. Za tímto účelem je rozumné rozdělit systém na segmenty, z nichž každý má své vlastní požadavky, a navrhnout systém na základě požadavků každého ze segmentů.  Teorém CAP byl po desetiletí základním kamenem myšlení o distribuovaných systémech. Poskytlo nám to rámec pro uvažování o inherentních kompromisech konzistence, dostupnosti a tolerance rozdělení. Ale v mnoha ohledech je to zjednodušení reality, za předpokladu binárních voleb a ignorování kritických faktorů, jako je latence.  PACELC staví na CAP a uznává, že:   Kompromisy existují, i když oddíly ne.    v návrhu distribuovaných systémů. Latence je prvotřídní problém  CAP i PACELC jsou cenné nástroje, ale ani jeden z nich není receptem na budování systémů krok za krokem. Místo toho poskytují   pro vyhodnocování kompromisů a pochopení limitů distribuovaných architektur. mentální modely  Doplňkové materiály   CAP o dvanáct let později: Jak se změnila „pravidla“   Cassandra: Definitivní průvodce    a  Přestaňte prosím nazývat databáze CP nebo AP A Critique of the CAP Theorem od Martina Kleppmanna   Poznámky k distribuovaným systémům pro mladé krve   Děkuji za přečtení!   Zajímá vás něco nebo máte nápady, o které se chcete podělit? Zanechte svůj komentář níže! Podívejte se na   nebo mě sledujte přes   ,   nebo   . můj blog LinkedIn Substack Telegram

Subscribe

Buy My Book

Tento zvuk je produkován v původním jazyce příběhu!

Příliš dlouho; Číst

Make resilience your competitive advantage

Proč distribuované systémy nemohou mít všechno

About Author

KOMENTÁŘE

ZAVĚŠIT ZNAČKY

TENTO ČLÁNEK BYL PŘEDSTAVEN V

Related Stories

Coinshift Launches csUSDL, Announces Strategic Partnerships

Coinshift Launches csUSDL, Announces Strategic Partnerships

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps