Zašto distribuirani sustavi ne mogu imati sve

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 KISELINE i BAZE . Ali s vremenom se razvio, dobio formalni dokaz i diplomirao da postane CAP teorem kakvog danas poznajemo.

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 ACID transakcijama . U CAP teoremu to se odnosi na linearizabilnost ili jaku konzistentnost . To znači da svi čvorovi u distribuiranom sustavu moraju uvijek predstavljati jedan, ažuran pogled na podatke , 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.

💡 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 svaki čvor koji ne kvari mora vratiti odgovor za svaki zahtjev koji primi, bez obzira na particije mreže . Drugim riječima, ako zdravi čvor dobije zahtjev, mora ga obraditi i odgovoriti na njega. Međutim, CAP ne jamči da će odgovor uvijek biti "točan" ili ažuran — on samo osigurava da čvor ne otkaže tiho (na primjer, čvorovi u AP sustavu mogu odgovoriti ustajalim podacima tijekom particije kako bi se osigurala dostupnost ).

💡 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, vrijeme odziva (ili isteci vremena) 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 ovom postu na blogu .

Tolerancija pregrada

Tolerancija particije je sve o preživljavanju mrežnih kvarova. Ako čvorovi ne mogu komunicirati zbog mrežne podjele (particije), sustav i dalje mora ispunjavati svoja jamstva dosljednosti ili dostupnosti, ovisno o izboru dizajna. Particija se događa kada čvorovi ne mogu komunicirati zbog ispuštenih paketa, isteka vremena ili mrežnih podjela.

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 se o toleranciji particije ne može raspravljati u bilo kojem distribuiranom sustavu — particije će se dogoditi prije ili kasnije, tako da ne možete "odabrati" ignorirati to, koliko god primamljivo zvučalo.

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 mrežne particije — situacije u kojoj dva dijela distribuiranog sustava ne mogu međusobno komunicirati. U takvom scenariju sustav se suočava s tri moguća ishoda:

1. Ako jedan dio sustava prihvaća ažuriranja dok je drugi izoliran, dva će dijela imati nedosljedna stanja. To rezultira gubitkom C (konzistencije) .
2. Ako sustav odluči ostati dosljedan , mora blokirati ažuriranja u jednom ili oba dijela particije kako bi osigurao jedinstveno stanje na svim čvorovima. To dovodi do gubitka A (dostupnosti) jer će neki zahtjevi biti odbijeni ili odgođeni na neodređeno vrijeme.
3. Ako sustav odluči ostati dostupan (A) 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.

Stoga, tijekom particije , sustav može zadovoljiti samo dva od tri svojstva (C, A ili P) . Nakon što je particija razriješena (tj. čvorovi ponovno komuniciraju), sustav može povratiti sva tri svojstva, ali tijekom same particije kompromisi su neizbježni.

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 dosljednosti (C) i dostupnosti (A) — primjenjuju samo kada mrežna particija (P) stvarno postoji. U normalnom radu, kada je mreža stabilna i ne postoje particije, nema inherentnog kompromisa između dosljednosti i dostupnosti.

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 latenciju , iako su latencija i particioniranje duboko povezani u praksi. Na primjer:

• 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 vremenskog razdoblja : 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.

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 :

• Dostupnost 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.
• Dosljednost ima različite razine, od eventualne dosljednosti do uzročne dosljednosti do jake dosljednosti. Ne zahtijeva svaka primjena punu mogućnost linearizacije.
• Tolerancija particije 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).

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. PACELC teorem koji je opisao Daniel J. Abadi 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 uvodi dva različita načina rada za distribuirane sustave:

1. Način particije ( PAC ): Kakav kompromis čini sustav kada dođe do particije? Ovdje ponovno razmatramo klasični CAP kompromis između dostupnosti (A) i dosljednosti (C) .
2. Drugi način rada ( ELC ): 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 kašnjenja (L) i 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 kašnjenje je često veće usko grlo od mrežnih particija, posebno za aplikacije na globalnoj razini. Ovo je mjesto na koje se PACELC 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 kašnjenje (L) i dosljednost (C) :

• Jaka dosljednost 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.
• Sustavi niske latencije (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.

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.
• Latencija je prvorazredni problem u dizajnu distribuiranog sustava.

I CAP i PACELC su vrijedni alati, ali ni jedan nije korak po korak recept za izgradnju sustava. Umjesto toga, oni pružaju mentalne modele za procjenu kompromisa i razumijevanje ograničenja distribuiranih arhitektura.

Dodatni materijali

• CAP dvanaest godina kasnije: Kako su se "pravila" promijenila
• Cassandra: Konačni vodič
• Molimo prestanite zvati baze podataka CP ili AP i 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 moj blog ili me pratite putem LinkedIna , Substacka ili Telegrama .