Suvremeni distribuirani sustavi sve su o kompromisima. Performanse, pouzdanost, skalabilnost i dosljednost ne dolaze besplatno — uvijek negdje plaćate cijenu. Tu dolazi CAP teorem: to je početna točka za razumijevanje neizbježnih kompromisa u distribuiranom dizajnu.  Zašto je CAP teorem točan? Što zapravo objašnjava? I, što je najvažnije, je li dovoljno? U ovom ćemo postu istražiti CAP teorem, njegova ograničenja, kritike s kojima se suočava i kako novije ideje poput PACELC-a guraju razgovor naprijed. Zaronimo.  CAP teorem  Prva verzija CAP teorema započela je kao rasprava između   . Ali s vremenom se razvio, dobio formalni dokaz i diplomirao da postane CAP teorem kakvog danas poznajemo. KISELINE i BAZE  CAP teorem kaže da   : distribuirani sustav može zadovoljiti najviše dva od tri svojstva istovremeno   Dosljednost   Dostupnost   Tolerancija particije  Ovo ograničenje tjera inženjere na teške kompromise ovisno o ciljevima sustava i stvarnosti njihovih distribuiranih okruženja.  Dosljednost   Dosljednost u CAP-u nije isto što i dosljednost u   . U CAP teoremu to se odnosi na   ili   . To znači da   , bez obzira na to koji čvor obrađuje zahtjev. To znači da svaka operacija čitanja odražava najnovije pisanje, bez obzira koji čvor postavljate upit. ACID transakcijama linearizabilnost jaku konzistentnost svi čvorovi u distribuiranom sustavu moraju uvijek predstavljati jedan, ažuran pogled na podatke  💡 Dosljednost u ACID-u, s druge strane, fokusira se na osiguravanje da transakcija dovodi bazu podataka iz jednog važećeg stanja u drugo važeće stanje, slijedeći pravila definirana shemom baze podataka. Više se radi o nametanju ograničenja integriteta (kao što su strani ključevi, jedinstvena ograničenja itd.) i osiguravanju da baza podataka ne ostane u nevažećem stanju, čak i u slučaju padova.  Dostupnost   Dostupnost u CAP-u znači da   . Drugim riječima, ako zdravi čvor dobije zahtjev, mora ga obraditi i odgovoriti na njega. Međutim, CAP   — on samo osigurava da čvor ne otkaže tiho (na primjer, čvorovi u   mogu odgovoriti ustajalim podacima tijekom particije kako bi se osigurala dostupnost ). svaki čvor koji ne kvari mora vratiti odgovor za svaki zahtjev koji primi, bez obzira na particije mreže ne jamči da će odgovor uvijek biti "točan" ili ažuran AP sustavu  💡 Eric Brewer (izvorni autor CAP-a) izvorno je opisao ovo svojstvo malo fleksibilnije kao: "gotovo svi upiti trebaju dobiti odgovor". Međutim, u formalnom dokazu CAP-a, dostupnost je postrožena, zahtijevajući da "svaki upit dobije odgovor sve dok je čvor koji njime rukuje ispravan".  U praksi, međutim, dostupnost nije apsolutno jamstvo — često ovisi o ograničenjima specifičnim za sustav, poput toga koliko dugo ste spremni čekati na odgovor. Za sustave u stvarnom svijetu,   igra ključnu ulogu u oblikovanju vašeg SLA (ugovora o razini usluge), iako sam CAP izravno ne uzima u obzir kašnjenje. Više o tome u   . vrijeme odziva (ili isteci vremena) ovom postu na blogu  Tolerancija pregrada   Tolerancija particije je sve o preživljavanju mrežnih kvarova.   Particija se događa kada čvorovi ne mogu komunicirati zbog ispuštenih paketa, isteka vremena ili mrežnih podjela. Ako čvorovi ne mogu komunicirati zbog mrežne podjele (particije), sustav i dalje mora ispunjavati svoja jamstva dosljednosti ili dostupnosti, ovisno o izboru dizajna.  Distribuirani sustavi ne žive u svijetu bajke sa savršenim mrežama. Paketi se ispuštaju, događaju se vremenski prekidi i skokovi kašnjenja su neizbježni. Zbog toga   — particije će se dogoditi prije ili kasnije, tako da ne možete "odabrati" ignorirati to, koliko god primamljivo zvučalo. se o toleranciji particije ne može raspravljati u bilo kojem distribuiranom sustavu  U CAP-u, tolerancija particije ne znači da sustav nastavlja raditi kao da se ništa nije dogodilo. To znači da sustav mora odlučiti hoće li dati prioritet dostupnosti (AP) ili dosljednosti (CP) tijekom particije. Ako biste zanemarili toleranciju particije, u biti biste gradili nedistribuirani monolitni sustav.  CAP objašnjeno  Najlakši način za razumijevanje CAP-a je razmatranje   — situacije u kojoj dva dijela distribuiranog sustava ne mogu međusobno komunicirati. U takvom scenariju sustav se suočava s tri moguća ishoda: mrežne particije    dok je drugi izoliran, dva će dijela imati nedosljedna stanja. To rezultira gubitkom   . Ako jedan dio sustava prihvaća ažuriranja C (konzistencije)    , mora blokirati ažuriranja u jednom ili oba dijela particije kako bi osigurao jedinstveno stanje na svim čvorovima. To dovodi do gubitka   jer će neki zahtjevi biti odbijeni ili odgođeni na neodređeno vrijeme. Ako sustav odluči ostati dosljedan A (dostupnosti)    i dosljedan (C) bez toleriranja particije (P), on nije istinski distribuiran. To bi zahtijevalo interakciju čvorova i usklađivanje stanja, što je nemoguće tijekom particije. Ako sustav odluči ostati dostupan (A)  Stoga,   , sustav može zadovoljiti samo   . Nakon što je particija razriješena (tj. čvorovi ponovno komuniciraju), sustav može povratiti sva tri svojstva, ali   kompromisi su neizbježni. tijekom particije dva od tri svojstva (C, A ili P) tijekom same particije  Implikacije teorema  Posljedica teorema za asinkrone sustave je da su moguće samo tri kombinacije dosljednosti, dostupnosti i tolerancije particije:  AP (dostupnost + tolerancija particije)  Sustavi ove vrste odgovaraju na upite, ali vraćeni podaci možda neće uvijek biti ažurni, sa sporijim ažuriranjem podataka, ali "uvijek" dostupnim. Primjeri takvog sustava su DNS, DynamoDB i Cassandra.  CP (konzistentnost + tolerancija particije)  Sustavi ove vrste uvijek vraćaju ažurne podatke, ali neki ili čak svi čvorovi u sustavu možda neće odgovoriti ako su particionirani. Daje atomska ažuriranja, ali može dovesti do vremenskog ograničenja. NoSQL baze podataka kao što su Google BigTable, MongoDB, HBase i Redis svi su sustavi ove vrste.  CA (dosljednost + dostupnost)  Sustavi ove vrste uvijek vraćaju ažurne podatke kada nema particija. Zbog posljednjeg ograničenja, obično se takvi sustavi koriste samo unutar jednog stroja. Primjeri su klasične relacijske baze podataka.  U stvarnosti biramo između CP i AP jer je CA u osnovi monolit bez particija. Za sustave velikih razmjera dizajneri ne mogu napustiti P i stoga imaju težak izbor između C i A.  U CA-u kvar čvora znači potpunu nedostupnost usluge. Ali to ne onemogućuje skalabilnost, budući da možemo klonirati neovisne monolite i rasporediti opterećenje preko njih  Kritika CAP teorema  CAP teorem je bio temeljni koncept u distribuiranim sustavima, ali nije bez svojih ograničenja. Uza svu svoju jasnoću u predstavljanju ideje kompromisa, CAP teorem često je kritiziran zbog pretjeranog pojednostavljivanja složenih stvarnosti, što je dovelo do nesporazuma i pogrešne primjene.  1. Ustupci se primjenjuju samo tijekom particija  Jedna od najčešćih kritika je da se kompromisi teorema CAP-a — odabir između   i   — primjenjuju samo kada   stvarno postoji. U normalnom radu, kada je mreža stabilna i ne postoje particije, nema inherentnog kompromisa između dosljednosti i dostupnosti. dosljednosti (C) dostupnosti (A) mrežna particija (P)  Nadalje, ti kompromisi nisu univerzalni za cijeli sustav. Unutar istog distribuiranog sustava:  Različiti dijelovi sustava mogu imati različite kompromise na temelju konteksta (kao što je lokacija korisnika, vrsta podataka).  Specifične operacije mogu dati prednost dosljednosti, dok druge daju prednost dostupnosti.  Odluke se mogu razlikovati tijekom izvođenja ovisno o čimbenicima kao što su opterećenje, latencija ili zahtjevi korisnika.  Ova se nijansa često gubi u raspravama na visokoj razini o CAP-u, što dovodi do pretjerano pojednostavljenih klasifikacija sustava kao "CP" ili "AP" u cijelosti.  2. CAP zanemaruje kašnjenje  Druga važna kritika je da CAP teorem ne uzima u obzir   , iako su latencija i particioniranje duboko povezani u praksi. Na primjer: latenciju  Spora mreža (visoka latencija) može se činiti nerazlučivom od particije.  Vremenska ograničenja—koja se koriste za otkrivanje kvarova—su subjektivna i uvelike ovise o dizajnu sustava i mrežnim uvjetima. Ono što jedan sustav definira kao "particiju" može biti samo prolazna odgoda za drugi.  U distribuiranim sustavima u stvarnom svijetu, kada se dogodi particija ili velika latencija, sustav mora donijeti odluku unutar   : dati prioritet dostupnosti vraćanjem moguće zastarjelog rezultata ili dati prioritet dosljednosti tako što će čekati duže (i potencijalno ne odgovoriti). CAP-ov binarni prikaz ne obuhvaća složenost ovih odluka. vremenskog razdoblja  3. CAP svojstva nisu binarna  CAP teorem predstavlja dosljednost, dostupnost i toleranciju particije kao binarna svojstva - ili ih imate ili nemate. Ali u praksi,   : sva tri svojstva postoje u spektru    nije binarno svojstvo "uključeno/isključeno" — kreće se od 0% do 100%. Na primjer, sustav može jamčiti 99,99% dostupnosti, ali to još uvijek dopušta mala razdoblja nedostupnosti. Dostupnost    ima različite razine, od eventualne dosljednosti do uzročne dosljednosti do jake dosljednosti. Ne zahtijeva svaka primjena punu mogućnost linearizacije. Dosljednost    sama po sebi nije jasan događaj. Sustavi se mogu ne slagati oko toga postoji li particija (kao što jedan čvor vidi istek vremena kao kvar, dok drugi nastavlja raditi normalno). Tolerancija particije  Ova kontinuirana priroda svojstava čini CAP previše pojednostavljenim za modeliranje složenosti modernih distribuiranih sustava.  PACELC teorem  Iako je CAP revolucionirao naše razumijevanje kompromisa u distribuiranim sustavima, to nije posljednja riječ o toj temi.   smatra se alternativnim pristupom dizajnu distribuiranih sustava. Temelji se na CAP modelu, ali uz dosljednost, dostupnost i toleranciju particije također uključuje kašnjenje i logičko isključivanje između kombinacija ovih koncepata. PACELC teorem koji je opisao Daniel J. Abadi  PACELC uvodi dva različita načina rada za distribuirane sustave:    (   ): Kakav kompromis čini sustav kada dođe do particije? Ovdje ponovno razmatramo klasični CAP kompromis između   i   . Način particije PAC dostupnosti (A) dosljednosti (C)    (   ): Koje kompromise sustav čini kada nema particije, a mreža funkcionira normalno? U ovom načinu rada sustav se suočava s drugačijim kompromisom — između   i   .  Drugi način rada ELC kašnjenja (L) dosljednosti (C)  Kompromis kašnjenja i dosljednosti  Iako su particije neizbježne u distribuiranim sustavima, one su rijetke u usporedbi s izazovima koji se javljaju tijekom normalnog rada. U modernim distribuiranim sustavima   je često veće usko grlo od mrežnih particija, posebno za aplikacije na globalnoj razini. Ovo je mjesto na koje se   fokusira — rješavanjem kompromisa koji se javljaju kada sustav radi bez particija. Za razliku od CAP-a, koji se fokusira isključivo na ponašanje tijekom scenarija kvara, PACELC naglašava odluke koje arhitekti moraju donositi svaki dan kako bi uravnotežili   i   : kašnjenje PACELC kašnjenje (L) dosljednost (C)    zahtijeva koordinaciju i sinkronizaciju između čvorova kako bi se održao jedinstveni prikaz podataka. Ovo opterećenje dovodi do kašnjenja, usporavajući vrijeme odgovora. Jaka dosljednost    (poput onih koji usvajaju konačnu dosljednost) daju prioritet brzini opuštajućim jamstvima dosljednosti. Ovi sustavi reagiraju brže, ali povremeno mogu vratiti ustajale ili nedosljedne podatke. Sustavi niske latencije  Proširujući razgovor izvan particija kako bi uključio normalan rad, PACELC osigurava da se svakodnevna izvedba distribuiranih sustava tretira s važnošću koju zaslužuje.  Zamotavanje  Formulacija CAP teorema je značajan događaj u zajednici, a studije o njegovom utjecaju na dizajn distribuiranih sustava pokazale su da projektanti distribuiranih sustava ne bi trebali ograničiti sustav na dva svojstva - oni bi trebali nastojati maksimizirati jamstva potrebna u svakom poseban slučaj. U tu svrhu razumno je sustav podijeliti na segmente od kojih svaki ima svoje zahtjeve te projektirati sustav na temelju zahtjeva svakog od segmenata.  CAP teorem bio je kamen temeljac razmišljanja o distribuiranim sustavima desetljećima. Dao nam je okvir za razmišljanje o inherentnim kompromisima dosljednosti, dostupnosti i tolerancije particije. Ali na mnogo načina, to je pojednostavljenje stvarnosti, pretpostavljajući binarni izbor i ignorirajući kritične čimbenike poput latencije.  PACELC se oslanja na CAP, priznajući da:   Ustupci postoje čak i kada particije ne postoje.    u dizajnu distribuiranog sustava. Latencija je prvorazredni problem  I CAP i PACELC su vrijedni alati, ali ni jedan nije korak po korak recept za izgradnju sustava. Umjesto toga, oni pružaju   za procjenu kompromisa i razumijevanje ograničenja distribuiranih arhitektura. mentalne modele  Dodatni materijali   CAP dvanaest godina kasnije: Kako su se "pravila" promijenila   Cassandra: Konačni vodič    i  Molimo prestanite zvati baze podataka CP ili AP Kritika CAP teorema Martina Kleppmanna   Bilješke o distribuiranim sustavima za mladu krv   Hvala vam na čitanju!   Zanima vas nešto ili želite podijeliti svoje mišljenje? Ostavite svoj komentar ispod! Provjerite   ili me pratite putem   ,   ili   . moj blog LinkedIna Substacka Telegrama

Subscribe

Buy My Book

Ovaj zvuk je proizveden na izvornom jeziku priče!

Predugo; Čitati

Make resilience your competitive advantage

Zašto distribuirani sustavi ne mogu imati sve

About Author

KOMENTARI

VIJESI OZNAKE

OVAJ ČLANAK JE PREDSTAVLJEN U

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps