Moderne verspreide stelsels gaan alles oor afwykings. Werkverrigting, betroubaarheid, skaalbaarheid en konsekwentheid kom nie gratis nie - jy betaal altyd iewers 'n prys. Dit is waar die CAP-stelling inkom: dit is die beginpunt om die onvermydelike kompromieë in verspreide ontwerp te verstaan.  Hoekom is die CAP-stelling waar? Wat verklaar dit eintlik? En, die belangrikste, is dit genoeg? In hierdie pos sal ons die CAP-stelling ondersoek, die beperkings daarvan, die kritiek wat dit in die gesig gestaar het en hoe nuwer idees soos PACELC die gesprek vorentoe stoot. Kom ons duik in.  CAP Stelling  Die eerste weergawe van die CAP-stelling het begin as 'n debat tussen   . Maar met verloop van tyd het dit ontwikkel, 'n formele bewys gekry en gegradueer om die CAP-stelling te word soos ons dit vandag ken. ACID vs. BASE  Die CAP-stelling stel dat   : 'n verspreide sisteem hoogstens twee uit drie eienskappe gelyktydig kan bevredig   Konsekwentheid   Beskikbaarheid   Partisie Toleransie  Hierdie beperking dwing ingenieurs om moeilike afwegings te maak, afhangende van die stelsel se doelwitte en die realiteite van hul verspreide omgewings.  Konsekwentheid   Konsekwentheid in CAP is nie dieselfde as die konsekwentheid in   . In CAP-stelling verwys dit na   of   . Dit beteken dat   , ongeag watter nodus die versoek verwerk. Dit beteken dat elke leesbewerking die mees onlangse skryf weerspieël, maak nie saak watter nodus jy navraag doen nie. ACID-transaksies nie lineariseerbaarheid sterk konsekwentheid alle nodusse in 'n verspreide stelsel altyd 'n enkele, bygewerkte aansig van die data moet aanbied  💡 Konsekwentheid in ACID, aan die ander kant, fokus daarop om te verseker dat 'n transaksie die databasis van een geldige toestand na 'n ander geldige toestand bring, volgens die reëls wat deur die databasisskema gedefinieer word. Dit gaan meer daaroor om integriteitsbeperkings af te dwing (soos vreemde sleutels, unieke beperkings, ens.) en om te verseker dat die databasis nie in 'n ongeldige toestand gelaat word nie, selfs in die lig van ineenstortings.  Beskikbaarheid   Beskikbaarheid in CAP beteken dat   . Met ander woorde, as 'n gesonde nodus 'n versoek kry, moet dit verwerk en daarop reageer. CAP   - dit verseker net dat die nodus nie stilweg misluk nie (byvoorbeeld, in   kan nodusse reageer met verouderde data tydens 'n partisie om beskikbaarheid te verseker ). elke nie-falende nodus 'n antwoord moet gee vir elke versoek wat dit ontvang, ongeag netwerkpartisies waarborg egter nie dat die antwoord altyd "korrek" of op datum sal wees nie AP-stelsel  💡 Eric Brewer (die oorspronklike skrywer van CAP) het hierdie eiendom oorspronklik 'n bietjie meer buigsaam beskryf as: "byna alle navrae behoort 'n antwoord te kry". In die formele bewys van CAP is beskikbaarheid egter strenger gemaak, wat vereis het dat "elke navraag 'n antwoord ontvang solank die nodus wat dit hanteer, gesond is".  In die praktyk is beskikbaarheid egter nie 'n absolute waarborg nie - dit hang dikwels af van stelselspesifieke beperkings, soos hoe lank jy bereid is om te wag vir 'n antwoord. Vir werklike wêreldstelsels speel   'n kritieke rol in die vorming van jou SLA (diensvlakooreenkoms), alhoewel CAP self nie regstreeks rekening hou met latensie nie. Meer daaroor in   . reaksietyd (of time-outs) hierdie blogpos  Partisieverdraagsaamheid   Partisieverdraagsaamheid gaan alles daaroor om netwerkfoute te oorleef.   'n Partisie vind plaas wanneer nodusse nie kan kommunikeer nie weens pakkies wat gedaal is, uitteltyd of netwerkverdelings. As nodusse nie kan kommunikeer nie as gevolg van 'n netwerkverdeling (partisie), moet die stelsel steeds aan sy konsekwentheids- of beskikbaarheidswaarborge voldoen, afhangende van sy ontwerpkeuses.  Verspreide stelsels leef nie in 'n sprokieswêreld met perfekte netwerke nie. Pakkies word laat val, time-outs vind plaas en vertragingspieke is onvermydelik. As gevolg hiervan   - partisies sal vroeër of later plaasvind, so jy kan nie "kies" om dit te ignoreer nie, maak nie saak hoe aanloklik dit mag klink nie. is partisieverdraagsaamheid ononderhandelbaar in enige verspreide stelsel  In CAP beteken partisietoleransie nie dat die stelsel aanhou loop asof niks gebeur het nie. Dit beteken dat die stelsel moet besluit of om beskikbaarheid (AP) of konsekwentheid (CP) tydens 'n partisie te prioritiseer. As jy partisietoleransie sou ignoreer, sou jy in wese 'n nie-verspreide monolitiese stelsel bou.  CAP verduidelik  Die maklikste manier om CAP te verstaan, is om 'n   te oorweeg - 'n situasie waar twee dele van 'n verspreide stelsel nie met mekaar kan kommunikeer nie. In so 'n scenario staar die stelsel drie moontlike uitkomste in die gesig: netwerkpartisie    terwyl die ander geïsoleer is, sal die twee dele inkonsekwente toestande hê. Dit lei tot 'n verlies van   . As een deel van die stelsel opdaterings aanvaar C (Konsekwentheid)    , moet dit opdaterings in een of albei dele van die partisie blokkeer om 'n verenigde toestand oor alle nodusse te verseker. Dit lei tot 'n verlies van   omdat sommige versoeke vir 'n onbepaalde tyd geweier of vertraag sal word. As die stelsel kies om konsekwent te bly A (Beskikbaarheid)    sonder om die partisie (P) te verdra, word dit nie werklik versprei nie. Dit sal vereis dat die nodusse interaksie moet hê en toestand moet versoen, wat onmoontlik is tydens 'n partisie. As die stelsel kies om beskikbaar (A) en konsekwent (C) te bly  Dus,   , kan die stelsel slegs   bevredig. Sodra die partisie opgelos is (dws die nodusse weer in wisselwerking tree), kan die stelsel al drie eienskappe herwin, maar   is afwykings onvermydelik. tydens 'n partisie twee van die drie eienskappe (C, A of P) tydens die partisie self  Implikasies van die stelling  'n Gevolg van die stelling vir asinchrone stelsels is dat slegs drie kombinasies van konsekwentheid, beskikbaarheid en partisietoleransie moontlik is:  AP (beskikbaarheid + partisietoleransie)  Stelsels van hierdie tipe reageer op navrae, maar die data wat teruggestuur word, is dalk nie altyd op datum nie, met stadiger opdaterings van die data, maar "altyd" beskikbaar. Voorbeelde van so 'n stelsel is DNS, DynamoDB en Cassandra.  CP (Konsekwentheid + Partisie Toleransie)  Stelsels van hierdie tipe gee altyd bygewerkte data terug, maar sommige, of selfs al, nodusse in die stelsel sal dalk nie reageer as dit gepartisioneer word nie. Dit gee atoomopdaterings, maar kan lei tot uitteltyd. NoSQL-databasisse soos Google BigTable, MongoDB, HBase en Redis is almal stelsels van hierdie tipe.  CA (Konsekwentheid + Beskikbaarheid)  Stelsels van hierdie tipe gee altyd bygewerkte data terug wanneer daar geen partisies is nie. As gevolg van die laaste beperking word sulke stelsels gewoonlik net binne een masjien gebruik. Voorbeelde is klassieke relasionele databasisse.  In werklikheid kies ons tussen CP en AP, want CA is basies 'n monoliet sonder partisies. Vir grootskaalse stelsels kan ontwerpers nie P laat vaar nie en het hulle dus 'n moeilike keuse tussen C en A.  In CA beteken knooppuntfout volledige onbeskikbaarheid van die diens. Maar dit deaktiveer nie skaalbaarheid nie, aangesien ons onafhanklike monoliete kan kloon en die las daaroor kan versprei  Kritiek op die GLB-stelling  Die CAP-stelling was 'n fundamentele konsep in verspreide stelsels, maar dit is nie sonder sy beperkings nie. Vir al sy duidelikheid in die aanbieding van die idee van afwykings, is die CAP-stelling dikwels gekritiseer vir die oorvereenvoudiging van komplekse realiteite, wat gelei het tot misverstande en verkeerde toepassings.  1. Afwykings is slegs van toepassing tydens partisies  Een van die mees algemene kritiek is dat die CAP-stelling se afwykings - die keuse tussen   en   - slegs van toepassing is wanneer   werklik voorkom. In normale werking, wanneer die netwerk stabiel is en geen partisies bestaan nie, is daar geen inherente afweging tussen konsekwentheid en beskikbaarheid nie. konsekwentheid (C) beskikbaarheid (A) 'n netwerkpartisie (P)  Verder is hierdie afwykings nie universeel oor die hele stelsel nie. Binne dieselfde verspreide stelsel:  Verskillende dele van die stelsel kan verskillende afwykings ervaar op grond van konteks (soos gebruikerligging, tipe data).  Spesifieke bedrywighede kan konsekwentheid prioritiseer terwyl ander beskikbaarheid prioritiseer.  Besluite kan tydens looptyd wissel na gelang van faktore soos vrag, vertraging of gebruikervereistes.  Hierdie nuanse gaan dikwels verlore in hoëvlakbesprekings van CAP, wat lei tot oorvereenvoudigde klassifikasies van stelsels as "CP" of "AP" oor die algemeen.  2. CAP Ignoreer Latency  Nog 'n belangrike kritiek is dat die CAP-stelling nie rekening hou met   nie, alhoewel latency en partisionering in die praktyk diep verbind is. Byvoorbeeld: latency  'n Stadige netwerk (hoë latensie) lyk dalk ononderskeibaar van 'n partisie.  Time-outs—wat gebruik word om foute op te spoor—is subjektief en sterk afhanklik van stelselontwerp en netwerktoestande. Wat een stelsel definieer as 'n "partisie" kan dalk net 'n verbygaande vertraging vir 'n ander wees.  In werklike verspreide stelsels, wanneer 'n partisie of hoë latensie plaasvind, moet die stelsel 'n besluit neem binne 'n   : prioritiseer beskikbaarheid deur 'n moontlik verouderde resultaat terug te gee, of prioritiseer konsekwentheid deur langer te wag (en moontlik nie te reageer nie). CAP se binêre siening vang nie die kompleksiteit van hierdie besluite vas nie. uittelperiode  3. CAP-eienskappe is nie binêr nie  Die CAP-stelling bied konsekwentheid, beskikbaarheid en partisietoleransie as binêre eienskappe aan - jy het dit of jy het dit nie. Maar in die praktyk   : bestaan al drie eienskappe op 'n spektrum    is nie 'n binêre "aan/af"-eienskap nie - dit wissel van 0% tot 100%. Byvoorbeeld, 'n stelsel kan 99,99% beskikbaarheid waarborg, maar dit maak steeds voorsiening vir klein tydperke van onbeskikbaarheid. Beskikbaarheid    het verskillende vlakke, van uiteindelike konsekwentheid tot oorsaaklike konsekwentheid tot sterk konsekwentheid. Nie elke toepassing vereis volle lineariseerbaarheid nie. Konsekwentheid    self is nie 'n duidelike gebeurtenis nie. Stelsels mag verskil of 'n partisie bestaan (soos een nodus 'n time-out as 'n mislukking sien, terwyl 'n ander normaalweg voortgaan). Partisieverdraagsaamheid  Hierdie deurlopende aard van die eienskappe maak CAP te simplisties vir die modellering van die kompleksiteite van moderne verspreide stelsels.  PACELC Stelling  Terwyl CAP ons begrip van afwykings in verspreide stelsels omskep het, is dit nie die laaste woord oor die onderwerp nie.   word beskou as 'n alternatiewe benadering tot die ontwerp van verspreide stelsels. Dit is gebaseer op die CAP-model, maar benewens konsekwentheid, beskikbaarheid en partisietoleransie sluit dit ook latensie en logiese uitsluiting tussen kombinasies van hierdie konsepte in. Die PACELC-stelling wat deur Daniel J. Abadi beskryf word,  PACELC stel twee afsonderlike werkswyses vir verspreide stelsels bekend:    (   ): Watter afweging maak die stelsel wanneer 'n partisie plaasvind? Hier kyk ons weer na die klassieke GLB-afweging tussen   en   . Partisiemodus PAC beskikbaarheid (A) konsekwentheid (C)    (   ): Watter afweging maak die stelsel as daar geen partisie is nie, en die netwerk normaal funksioneer? In hierdie modus staar die stelsel 'n ander afweging in die gesig - tussen   en   .  Else-modus ELC latensie (L) konsekwentheid (C)  Die vertraging-konsekwentheid-afruiling  Alhoewel partisies onvermydelik is in verspreide stelsels, is dit skaars in vergelyking met die uitdagings wat tydens normale werking ontstaan. In moderne verspreide stelsels is   dikwels 'n groter bottelnek as netwerkpartisies, veral vir toepassings op wêreldwye skaal. Dit is waar   fokus - deur die afwykings aan te spreek wat plaasvind wanneer die stelsel sonder partisies werk. Anders as CAP, wat uitsluitlik op gedrag tydens mislukkingscenario's fokus, beklemtoon PACELC die besluite wat argitekte elke dag moet neem om   en   te balanseer: latency PACELC latensie (L) konsekwentheid (C)    vereis koördinasie en sinchronisasie tussen nodusse om 'n verenigde siening van die data te handhaaf. Hierdie oorhoofse koste lei tot vertragings, wat reaksietye vertraag. Sterk konsekwentheid    (soos dié wat uiteindelike konsekwentheid aanneem) prioritiseer spoed deur konsekwentheidswaarborge te verslap. Hierdie stelsels reageer vinniger, maar kan soms verouderde of inkonsekwente data terugstuur. Stelsels met lae latensie  Deur die gesprek verder as partisies uit te brei om normale werking in te sluit, verseker PACELC dat die alledaagse werkverrigting van verspreide stelsels met die belangrikheid behandel word wat dit verdien.  Om dit toe te draai  Die formulering van die CAP-stelling was 'n belangrike gebeurtenis in die gemeenskap, en studies van die impak daarvan op verspreide stelselontwerp het getoon dat ontwerpers van verspreide stelsels nie die stelsel tot twee eienskappe moet beperk nie - hulle moet daarna streef om die waarborge wat in elkeen vereis word, te maksimeer. besondere geval. Vir hierdie doel is dit redelik om die stelsel in segmente te verdeel, wat elkeen sy eie vereistes het, en om die stelsel te ontwerp op grond van die vereistes van elk van die segmente.  Die CAP-stelling is al dekades lank 'n hoeksteen van verspreide sisteemdenke. Dit het ons 'n raamwerk gegee om te redeneer oor die inherente afwykings van konsekwentheid, beskikbaarheid en partisieverdraagsaamheid. Maar in baie opsigte is dit 'n vereenvoudiging van die werklikheid, deur binêre keuses te aanvaar en kritieke faktore soos latency te ignoreer.  PACELC bou voort op CAP, en erken dat:   Afwykings bestaan selfs wanneer partisies dit nie doen nie.    in verspreide stelselontwerp. Latency is 'n eersteklas bekommernis  Beide CAP en PACELC is waardevolle gereedskap, maar ook nie 'n stap-vir-stap resep vir die bou van stelsels nie. In plaas daarvan bied hulle   om afwykings te evalueer en die grense van verspreide argitekture te verstaan. verstandelike modelle  Bykomende materiaal   CAP Twaalf jaar later: hoe die "reëls" verander het   Cassandra: Die definitiewe gids    en   te noem Hou asseblief op om databasisse CP of AP A Critique of the CAP Theorem deur Martin Kleppmann   Notas oor verspreide stelsels vir jong bloed   Dankie dat jy gelees het!   Is jy nuuskierig oor iets of het jy gedagtes om te deel? Los jou kommentaar hieronder! Kyk na   of volg my via   ,   of   . my blog LinkedIn Substack Telegram

Subscribe

Buy My Book

Hierdie oudio word in die oorspronklike taal van die storie vervaardig!

Waarom verspreide stelsels nie alles kan hê nie

About Author

KOMMENTAAR

HANG TAGS

HIERDIE ARTIKEL IS AANGEBIED IN

Related Stories

The #decentralize-ai Writing Contest by ICP and HackerNoon: Results Announcement 🎉

Top Actionable Tips to Grow a Community: More Tips to Monetize

Thrilled to be Recognized as Startup of the Year in New York City

The #bitcoin Writing Contest by Rootstock and HackerNoon: Round 2 Results 🎉

The #decentralize-ai Writing Contest by ICP and HackerNoon: Results Announcement 🎉

Top Actionable Tips to Grow a Community: More Tips to Monetize

Thrilled to be Recognized as Startup of the Year in New York City

The #bitcoin Writing Contest by Rootstock and HackerNoon: Round 2 Results 🎉

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps