Distribuované

Princíp CAP

Cap Principle



Prehľad

CAP Zásady sa tiež nazývajú CAP Veta sa v distribuovanom systéme označuje ako Consistency (konzistencia), Availability (Dostupnosť), Partition tolerance (Odolnosť voči poruchám oddielu), tri nie sú kompatibilné, nanajvýš môžu uspokojiť jeden z nich súčasne 2 Jeden.

20191212103254



  • konzistencia (Consistency）



    Majú všetky zálohy dát v distribuovanom systéme rovnakú hodnotu v rovnakom čase? (Prísna konzistencia, všetky uzly majú prístup k rovnakej kópii najnovších údajov)



  • Dostupnosť (Availability）

    Po zlyhaní niektorých uzlov v klastri, či celý klaster môže reagovať na požiadavky klienta na čítanie a zápis. (Vysoká dostupnosť pre aktualizáciu údajov nezaručuje, že získané údaje sú najnovšími údajmi, ale zaručuje konečnú konzistenciu)

  • Tolerancia chýb oddielu (Partition tolerance）



    Keď distribuovaný systém narazí na akékoľvek zlyhanie sieťového oddielu, môže stále poskytovať externé služby, ktoré zodpovedajú konzistencii a dostupnosti, pokiaľ nezlyhá celé sieťové prostredie. Ak systém nemôže dosiahnuť konzistenciu údajov v časovom limite, znamená to, že došlo k oddielu a aktuálna operácia musí byť C s A Vyberte si medzi.

Argumentácia zásadou CAP

Základná scéna

V základnom scenári CAP sú v sieti dva uzly N1 a N2. Je možné jednoducho pochopiť, že N1 a N2 sú dva počítače a sieť medzi nimi môže byť prepojená. V N1 je aplikácia A a databáza V., N2 má tiež aplikáciu B2 a databázu V. Teraz sú A a B dve časti distribuovaného systému a V sú dve poddatabázy dátového úložiska. distribuovaného systému.

20191212110038

  • Keď je splnená konzistencia, údaje v N1 a N2 sú rovnaké, V0 = V0.
  • Po dosiahnutí dostupnosti dostane užívateľ okamžitú odpoveď bez ohľadu na to, či požaduje N1 alebo N2.
  • V prípade splnenia tolerancie chyby oddielu, keď sú buď N1 a N2 nefunkčné, alebo je sieť nedostupná, nebude to mať vplyv na normálnu prevádzku N1 a N2.

Sieť funguje normálne a v skutočnosti spĺňa CAP súčasne

20191212111643

Užívateľ požaduje aktualizáciu údajov zo stroja N1 a program A aktualizuje databázu V0 na V1. Distribuovaný systém synchronizuje dáta M, synchronizuje V1 s V0 v N2, takže dáta V0 v N2 sa tiež aktualizujú na V1 a dáta v N2 reagujú na požiadavku N2.

  • Konzistencia: Či sú údaje medzi databázou V N1 a N2 úplne rovnaké.
  • Dostupnosť: Či N1 a N2 môžu normálne reagovať na externé požiadavky.
  • Tolerancia chýb oddielu: Či je sieť medzi N1 a N2 interoperabilná.

Sieť je abnormálna, CAP dokáže uspokojiť iba dve z nich súčasne

]

Za predpokladu, že keď je sieť medzi N1 a N2 odpojená, používateľ pošle požiadavku na aktualizáciu údajov na N1, potom sa údaje V0 v N1 aktualizujú na V1. Pretože je sieť odpojená, distribuovaný systém pracuje M synchrónne, takže dáta v N2 sú stále V0. V tejto chvíli užívateľ pošle požiadavku na čítanie dát do N2. Pretože dáta neboli synchronizované, aplikácia nemôže užívateľovi okamžite vrátiť najnovšie dáta V1. Čo mám robiť?
Tu sú dve možnosti:

  • Prvý: Obetujte konzistenciu údajov a zaistite dostupnosť. Odpovedajte používateľovi na staré údaje V0.
  • Druhá: Obetujte dostupnosť a zabezpečte konzistenciu údajov. Blokujte a počkajte, kým sa obnoví sieťové pripojenie a nedokončí sa operácia aktualizácie údajov M, a potom bude používateľ odpovedať na najnovšie údaje V1.

zhrnúť

V skutočnosti to pre distribuované systémy nie je CAP Môže uspokojiť iba jedného z nich 2 Ale keď je problém v sieti: pretože P Musí byť splnené, takže iba A s C Vyberte si jednu z dvoch možností.

Stratégia kompromisu

Z dôvodu CAP Môže uspokojiť najviac 2 Jeden, takže musím urobiť kompromis.

  • CA bez P

    Ak P nie je požadované (rozdelenie nie je povolené), potom je možné zaručiť C (silná konzistencia) a A (dostupnosť). Ale vzdať sa P znamená tiež vzdať sa škálovateľnosti systému, to znamená, že distribuované uzly sú obmedzené a neexistuje žiadny spôsob nasadenia podradených uzlov. To je v rozpore s pôvodným zámerom návrhu distribuovaného systému. Tradičná relačná databáza RDBMS: Oracle a MySQL sú CA.

  • CP bez A

    Ak A (k dispozícii) nie je potrebné, znamená to, že každá požiadavka musí byť medzi servermi silne konzistentná, a P (oddiel) spôsobí, že čas synchronizácie sa predĺži na neurčito (to znamená, že počkajte na dokončenie synchronizácie údajov, pred normálnym prístupom) k sieti), hneď ako dôjde k sieti V situáciách, ako je zlyhanie alebo strata správ, je potrebné obetovať používateľskú skúsenosť a počkať, kým nebudú všetky údaje konzistentné, skôr ako umožníte používateľom prístup do systému. V skutočnosti existuje veľa systémov navrhnutých ako CP, najtypickejšie sú distribuované databázy, napríklad Redis, HBase atď. Pre tieto distribuované databázy je konzistencia údajov tou najzákladnejšou požiadavkou, pretože ak nie je splnený ani tento štandard, je to lepšie priame použitie relačných databáz a na nasadenie distribuovaných databáz nie je potrebné míňať zdroje.

  • AP bez C

    Ak chcete byť vysoko dostupní a umožniť vytváranie oddielov, musíte sa vzdať konzistencie. Akonáhle dôjde k rozdeleniu, uzly môžu stratiť kontakt. Kvôli vysokej dostupnosti môže každý uzol na poskytovanie služieb používať iba miestne údaje, čo spôsobí nezrovnalosti v globálnych údajoch. Typická aplikácia je ako rýchla scéna mobilného telefónu v určitom metri. Táto stránka vás upozorní, že pri prehliadaní produktu v prvých sekundách existuje inventár. Keď vyberiete produkt a pripravíte sa na zadanie objednávky, systém vás vyzve, aby objednávka zlyhala a produkt bol vypredaný. . Ide vlastne o to, aby sa najskôr zabezpečila normálna služba systému z hľadiska A (dostupnosť), a potom sa urobilo niekoľko obetí, pokiaľ ide o konzistenciu údajov. Aj keď to do istej miery ovplyvní určitý dojem používateľa, nespôsobí to vážne blokovanie procesu nakupovania používateľa.

Ako si vybrať hlavný distribuovaný systém

Heuréka Konzul Ošetrovateľ v zoo Nacos Atď
SPP AP CP CP AP / CP CP
Konsenzusový algoritmus nie Raft ZAB (protokol podobný PAXOS) Raft Raft

pre AP V skutočnosti vás algoritmus konsenzu nemusí zaujímať, takže Eureka Na zaistenie Server nepoužíva žiadny silný algoritmus konzistencie údajov Údaje sú konzistentné a konečná konzistencia údajov registra sa dosahuje iba prostredníctvom ich kopírovania.

A ako Zookeeper Pre takéto distribuované koordinačné komponenty je konzistencia údajov ich najzákladnejšou požiadavkou. V extrémnych prostrediach teda ZooKeeper Niektoré žiadosti môžu byť vyradené a na získanie výsledkov je potrebné opätovne požiadať spotrebiteľský program. Je tiež potrebné zabezpečiť konzistenciu údajov.

Pre Nacos Povedzte, realizujte AP Zároveň sa používa konsenzusný algoritmus Raft ， Ako Nacos realizuje AP a CP súčasne 。

Ďalšie čítanie

Pre distribuovaný systém. P Je základnou požiadavkou, CAP Z týchto troch iba CA Urobte medzi nimi kompromis a vyskúšajte všetky prostriedky na zlepšenie P 。
V niektorých prípadoch AP oproti CP Môžete vidieť, ako si tieto spoločnosti vyberajú:

odkaz