A CAP tételről

A CAP tétel (vagy Brewer-tétel) az elosztott rendszerek „szentháromsága”, amiből a fizika és a hálózatok kegyetlen törvényei miatt egyszerre csak kettőt választhatsz.

Képzeld el úgy, mint a klasszikus „Olcsó, Gyors, Jó – válassz kettőt” dilemmát, csak itt adatokról és szerverekről van szó.

A három összetevő

1. Consistency (Konzisztencia) – „Mindenki ugyanazt látja” Ha írsz egy adatot az „A” szerverre, akkor az összes többi szervernek is azonnal tudnia kell róla. Ha bárki, bárhol a világon lekéri az adatot, ugyanazt a legfrissebb választ kapja. Nincs „majd frissül” vagy „még a régi árat látom”.
2. Availability (Rendelkezésre állás) – „Mindig kapsz választ” Bármelyik szerverhez fordulsz, az válaszolni fog. Nem kapsz hibaüzenetet, nem pörög a homokóra a végtelenségig. Lehet, hogy az adat, amit kapsz, már félperces (tehát nem a legfrissebb), de a rendszer „él” és működik.
3. Partition Tolerance (Hálózatkimaradás-tűrés) – „Akkor is megy, ha szakad a kábel” Ez a legfontosabb: a rendszer akkor is működik, ha a szerverek közötti kommunikációs vonal megszakad (ezt hívjuk partition-nek). Mondjuk egy tenger alatti kábel elszakad, és az amerikai szerver nem tud beszélni az európaival.

A nagy dilemma: Miért csak kettőt?

A valóságban – mivel a hálózatok néha elromlanak – a Partition Tolerance (P) nem választható, hanem kötelező. Ha elosztott rendszered van, fel kell készülnöd arra, hogy a szerverek néha nem látják egymást.

Így a valódi döntésed az, hogy mi történik egy hálózati szakadás esetén: CP vagy AP lesz az appod?

A Pizza-futár Analógia 🍕

Tegyük fel, hogy van két pizzériád (Szerver A és Szerver B), és egy közös telefonos rendelési rendszered. Elszakad a kábel a két bolt között, nem tudnak beszélni.

A) A Konzisztens választás (CP – Consistency + Partition Tolerance) Bejön egy hívás az „A” boltba: „Mennyi a maffia pizza?”. Az „A” bolt tudja, hogy reggel óta lehet, hogy változott az ár, de nem tudja megkérdezni a központot vagy a „B” boltot a szakadás miatt.

Döntés: Azt mondja a vevőnek: „Sajnos technikai hiba miatt nem tudunk rendelést felvenni.”

Eredmény: Az adatunk pontos (nem adunk el hibás áron semmit), de a rendszerünk nem áll rendelkezésre (Availability oda).

B) A Mindig elérhető választás (AP – Availability + Partition Tolerance) Bejön ugyanaz a hívás. Az „A” bolt ismeri a tegnapi árat.

Döntés: „Persze, 3000 forint, küldjük!” – közben lehet, hogy a „B” boltban már 3500-ra emelték az árat 10 perce, csak nem tudtak szólni.

Eredmény: Kiszolgáltuk a vevőt (Availability pipa), de az adatunk nem konzisztens (Consistency oda).

Hol használjuk ezeket?

Típus	Mikor válaszd?	Példa
CP	Ha az adat pontossága élet-halál kérdés.	Banki rendszerek, tőzsde, készletkezelő (ne adjunk el olyat, ami nincs).
AP	Ha fontosabb, hogy a user lásson valamit, mint hogy az tökéletes legyen.	Facebook lájkok, Twitter feed, Netflix ajánló (nem baj, ha 1 perccel későbbi a lista).

Mi a helyzet a CA-val?

A CA (Consistency + Availability) csak elméletben létezik, vagy olyan rendszerekben, ahol garantált, hogy a hálózat soha nem szakad meg. Ez a való világban (főleg mobilnetnél) fizikai képtelenség.

Összegezve

A CAP tétel arra emlékeztet, hogy nem lehetsz egyszerre tökéletesen precíz és mindig elérhető egy bizonytalan hálózatban. El kell döntened, melyik ujjadba harapsz, amikor beüt a krach.