CAP-sats

Inom teoretisk datavetenskap säger CAP -satsen , även kallad Brewers teorem efter datavetaren Eric Brewer , att varje distribuerat datalager endast kan ge två av följande tre garantier:

Konsistens
Varje läsning får den senaste skrivningen eller ett fel.
Tillgänglighet
Varje förfrågan får ett (icke-fel)svar, utan garanti för att den innehåller den senaste skrivningen.
Partitionstolerans
Systemet fortsätter att fungera trots att ett godtyckligt antal meddelanden tappas (eller fördröjs) av nätverket mellan noder.

När ett nätverkspartitionsfel inträffar måste det bestämmas om man ska göra något av följande:

  • avbryta operationen och därmed minska tillgängligheten men säkerställa konsekvens
  • gå vidare med operationen och därmed tillhandahålla tillgänglighet men riskera inkonsekvens.
CAP Theorem Venn Diagram

Således, om det finns en nätverkspartition, måste man välja mellan konsistens eller tillgänglighet. Observera att konsistens enligt definitionen i CAP-satsen skiljer sig ganska mycket från konsistensen som garanteras i ACID- databastransaktioner .

Eric Brewer menar att det ofta använda "två av tre"-konceptet kan vara något missvisande eftersom systemdesigners bara behöver offra konsekvens eller tillgänglighet i närvaro av partitioner, men att partitioner i många system är sällsynta.

Förklaring

Inget distribuerat system är säkert från nätverksfel, därför måste nätverkspartitionering i allmänhet tolereras. I närvaro av en partition har man sedan två alternativ: konsistens eller tillgänglighet . När du väljer konsistens framför tillgänglighet kommer systemet att returnera ett fel eller en timeout om viss information inte kan garanteras vara uppdaterad på grund av nätverkspartitionering. När du väljer tillgänglighet framför konsekvens kommer systemet alltid att bearbeta frågan och försöka returnera den senaste tillgängliga versionen av informationen, även om det inte kan garantera att den är uppdaterad på grund av nätverkspartitionering.

I avsaknad av en partition kan både tillgänglighet och konsistens tillfredsställas.

Databassystem designade med traditionella ACID- garantier i åtanke som RDBMS väljer konsistens framför tillgänglighet, medan system designade kring BASE- filosofin, vanlig i NoSQL -rörelsen till exempel, väljer tillgänglighet framför konsekvens.

Historia

Enligt datavetaren Eric Brewer vid University of California, Berkeley, dök satsen första gången upp hösten 1998. Den publicerades som CAP-principen 1999 och presenterades som en gissning av Brewer vid 2000 års Symposium on Principles of Distributed Computing ( PODC). 2002 publicerade Seth Gilbert och Nancy Lynch från MIT ett formellt bevis på Brewers gissningar, vilket gjorde det till ett teorem .

Under 2012 klargjorde Brewer några av sina ståndpunkter, inklusive varför det ofta använda "två av tre"-konceptet kan vara något missvisande eftersom systemdesigners bara behöver offra konsekvens eller tillgänglighet i närvaro av partitioner; partitionshantering och återställningstekniker finns. Brewer noterade också den annorlunda definitionen av konsistens som används i CAP-satsen i förhållande till definitionen som används i ACID .

Ett liknande teorem som anger avvägningen mellan konsistens och tillgänglighet i distribuerade system publicerades av Birman och Friedman 1996. Birman och Friedmans resultat begränsade denna nedre gräns till icke-pendlingsoperationer.

PACELC -teoremet , som introducerades 2010, bygger på CAP genom att konstatera att även i frånvaro av partitionering finns det en annan avvägning mellan latens och konsistens. PACELC betyder att om partition (P) inträffar är avvägningen mellan tillgänglighet (A) och konsistens (C); Annars (E), är avvägningen mellan latens (L) och konsistens (C).

Blockchain-teknik offrar ofta omedelbar konsekvens för tillgänglighet och partitionstolerans. Genom att kräva ett specifikt antal "bekräftelser" reduceras Blockchain konsensusalgoritmer i princip till slutlig konsistens.

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=CAP_theorem&oldid=1128018230 "