Moderna distribuerade system handlar om avvägningar. Prestanda, tillförlitlighet, skalbarhet och konsekvens är inte gratis – du betalar alltid ett pris någonstans. Det är där CAP-teoremet kommer in: det är utgångspunkten för att förstå de oundvikliga kompromisserna i distribuerad design.  Varför är CAP-satsen sann? Vad förklarar det egentligen? Och viktigast av allt, räcker det? I det här inlägget kommer vi att utforska CAP-satsen, dess begränsningar, kritiken den har mött och hur nyare idéer som PACELC driver konversationen framåt. Låt oss dyka in.  CAP-sats  Den första versionen av CAP-teoremet började som en debatt mellan   . Men med tiden utvecklades det, fick ett formellt bevis och tog examen för att bli CAP-teoremet som vi känner det idag. ACID vs. BASE  CAP-satsen säger att   : ett distribuerat system kan uppfylla högst två av tre egenskaper samtidigt   Konsistens   Tillgänglighet   Partitionstolerans  Denna begränsning tvingar ingenjörer att göra svåra avvägningar beroende på systemets mål och verkligheten i deras distribuerade miljöer.  Konsistens   Konsistens i CAP är inte detsamma som konsekvensen i   . I CAP-teorem hänvisar det till   eller   . Det innebär att   , oavsett vilken nod som behandlar begäran. Det betyder att varje läsoperation återspeglar den senaste skrivningen, oavsett vilken nod du frågar efter. ACID-transaktioner lineariserbarhet stark konsistens alla noder i ett distribuerat system alltid måste presentera en enda, uppdaterad vy av data  💡 Konsistens i ACID, å andra sidan, fokuserar på att säkerställa att en transaktion för databasen från ett giltigt tillstånd till ett annat giltigt tillstånd, enligt reglerna som definieras av databasschemat. Det handlar mer om att upprätthålla integritetsbegränsningar (som främmande nycklar, unika begränsningar, etc) och att se till att databasen inte lämnas i ett ogiltigt tillstånd, även inför krascher.  Tillgänglighet   Tillgänglighet i CAP innebär att   . Med andra ord, om en frisk nod får en begäran måste den bearbeta och svara på den. Men CAP   - det säkerställer bara att noden inte misslyckas tyst (till exempel i   kan noder svara med inaktuella data under en partition för att säkerställa tillgänglighet ). varje nod som inte misslyckas måste returnera ett svar för varje begäran den tar emot, oavsett nätverkspartitioner garanterar inte att svaret alltid kommer att vara "korrekt" eller uppdaterat AP-system  💡 Eric Brewer (den ursprungliga författaren till CAP) beskrev ursprungligen den här egenskapen lite mer flexibelt som: "nästan alla frågor borde få ett svar". Men i det formella beviset för CAP gjordes tillgängligheten strängare, vilket krävde att "varje fråga ska få ett svar så länge som noden som hanterar den är sund".  I praktiken är dock tillgänglighet inte en absolut garanti – det beror ofta på systemspecifika begränsningar, som hur länge du är villig att vänta på ett svar. För verkliga system spelar   en avgörande roll i utformningen av din SLA (servicenivåavtal), även om CAP själv inte direkt tar hänsyn till latens. Mer om det i   . svarstid (eller timeouts) detta blogginlägg  Partitionstolerans   Partitionstolerans handlar om att överleva nätverksfel.   En partition inträffar när noder inte kan kommunicera på grund av tappade paket, timeouts eller nätverksuppdelningar. Om noder inte kan kommunicera på grund av en nätverksdelning (partition), måste systemet fortfarande uppfylla sina garantier för konsistens eller tillgänglighet, beroende på dess designval.  Distribuerade system lever inte i en sagovärld med perfekta nätverk. Paketen tappas, timeouts inträffar och fördröjningstoppar är oundvikliga. På grund av detta   - partitioner kommer att hända förr eller senare, så du kan inte "välja" att ignorera det, oavsett hur frestande det kan låta. är partitionstolerans inte förhandlingsbar i alla distribuerade system  I CAP betyder partitionstolerans inte att systemet fortsätter att köras som om ingenting hänt. Det betyder att systemet måste bestämma om det ska prioritera tillgänglighet (AP) eller konsekvens (CP) under en partition. Om du skulle ignorera partitionstolerans, skulle du i princip bygga ett icke-distribuerat monolitiskt system.  CAP förklarade  Det enklaste sättet att förstå CAP är att överväga en   - en situation där två delar av ett distribuerat system inte kan kommunicera med varandra. I ett sådant scenario står systemet inför tre möjliga utfall: nätverkspartition    medan den andra är isolerad kommer de två delarna att ha inkonsekventa tillstånd. Detta resulterar i en förlust av   . Om en del av systemet accepterar uppdateringar C (konsistens)    måste det blockera uppdateringar i en eller båda delarna av partitionen för att säkerställa ett enhetligt tillstånd över alla noder. Detta leder till en förlust av   eftersom vissa förfrågningar kommer att nekas eller försenas på obestämd tid. Om systemet väljer att förbli konsekvent A (tillgänglighet)    och konsekvent (C) utan att tolerera partitionen (P), är det inte riktigt distribuerat. Detta skulle kräva att noderna interagerar och stämmer av tillstånd, vilket är omöjligt under en partition. Om systemet väljer att förbli tillgängligt (A)    kan systemet alltså bara uppfylla   . När partitionen är löst (dvs. noderna interagerar igen) kan systemet återfå alla tre egenskaperna, men   är avvägningar oundvikliga. Under en partition två av de tre egenskaperna (C, A eller P) under själva partitionen  Implikationer av satsen  En konsekvens av satsen för asynkrona system är att endast tre kombinationer av konsistens, tillgänglighet och partitionstolerans är möjliga:  AP (tillgänglighet + partitionstolerans)  System av den här typen svarar på frågor, men den data som returneras kanske inte alltid är uppdaterad, med långsammare uppdateringar av data men "alltid" tillgänglig. Exempel på ett sådant system är DNS, DynamoDB och Cassandra.  CP (konsistens + partitionstolerans)  System av denna typ returnerar alltid uppdaterade data, men vissa, eller till och med alla, noder i systemet kanske inte svarar om de partitioneras. Det ger atomära uppdateringar men kan leda till timeout. NoSQL-databaser som Google BigTable, MongoDB, HBase och Redis är alla system av denna typ.  CA (Konsistens + Tillgänglighet)  System av denna typ returnerar alltid uppdaterad data när det inte finns några partitioner. På grund av den sista begränsningen används sådana system vanligtvis endast inom en maskin. Exempel är klassiska relationsdatabaser.  I verkligheten väljer vi mellan CP och AP eftersom CA i grunden är en monolit utan partitioner. För storskaliga system kan konstruktörer inte överge P och har därför ett svårt val mellan C och A.  I CA betyder nodfel fullständig otillgänglighet för tjänsten. Men detta inaktiverar inte skalbarhet, eftersom vi kan klona oberoende monoliter och fördela belastningen över dem  Kritik av CAP-satsen  CAP-teoremet har varit ett grundläggande koncept i distribuerade system, men det är inte utan sina begränsningar. För all sin klarhet i att presentera idén om avvägningar, har CAP-satsen ofta kritiserats för att förenkla komplexa verkligheter, vilket har lett till missförstånd och felaktiga tillämpningar.  1. Avvägningar gäller endast under partitioner  En av de vanligaste kritikerna är att CAP-teoremets avvägningar – att välja mellan   och   – bara gäller när   faktiskt inträffar. I normal drift, när nätverket är stabilt och inga partitioner existerar, finns det ingen inneboende kompromiss mellan konsekvens och tillgänglighet. konsistens (C) tillgänglighet (A) en nätverkspartition (P)  Dessutom är dessa avvägningar inte universella över hela systemet. Inom samma distribuerade system:  Olika delar av systemet kan uppleva olika avvägningar baserat på sammanhang (som användarens plats, typ av data).  Specifika operationer kan prioritera konsekvens medan andra prioriterar tillgänglighet.  Beslut kan variera under körning beroende på faktorer som belastning, latens eller användarkrav.  Denna nyans går ofta förlorad i diskussioner på hög nivå om CAP, vilket leder till alltför förenklade klassificeringar av system som "CP" eller "AP" över hela linjen.  2. CAP ignorerar latens  En annan viktig kritik är att CAP-satsen inte tar hänsyn till   , även om latens och partitionering är djupt sammankopplade i praktiken. Till exempel: latens  Ett långsamt nätverk (hög latens) kan se omöjligt att skilja från en partition.  Timeouts – som används för att upptäcka fel – är subjektiva och starkt beroende av systemdesign och nätverksförhållanden. Vad ett system definierar som en "partition" kan bara vara en övergående fördröjning för ett annat.  I verkliga distribuerade system, när en partition eller hög latens inträffar, måste systemet fatta ett beslut inom en   : prioritera tillgänglighet genom att returnera ett eventuellt inaktuellt resultat, eller prioritera konsekvens genom att vänta längre (och eventuellt misslyckas med att svara). CAP:s binära syn fångar inte komplexiteten i dessa beslut. timeoutperiod  3. CAP-egenskaper är inte binära  CAP-satsen presenterar konsistens, tillgänglighet och partitionstolerans som binära egenskaper – antingen har du dem eller så har du inte. Men i praktiken   : existerar alla tre egenskaperna på ett spektrum    är inte en binär "på/av"-egenskap – den varierar från 0 % till 100 %. Till exempel kan ett system garantera 99,99 % tillgänglighet, men det tillåter fortfarande små perioder av otillgänglighet. Tillgänglighet    har olika nivåer, från eventuell konsistens till kausal konsistens till stark konsistens. Inte alla applikationer kräver full lineariserbarhet. Konsistens    i sig är inte en entydig händelse. System kan vara oense om huruvida en partition existerar (som att en nod ser en timeout som ett fel, medan en annan fortsätter att fungera normalt). Partitionstolerans  Denna kontinuerliga karaktär av egenskaper gör CAP alltför förenklat för att modellera komplexiteten hos moderna distribuerade system.  PACELC-satsen  Även om CAP revolutionerade vår förståelse av avvägningar i distribuerade system, är det inte det sista ordet i ämnet.   anses vara en alternativ metod för design av distribuerade system. Den är baserad på CAP-modellen, men förutom konsekvens, tillgänglighet och partitionstolerans inkluderar den även latens och logisk uteslutning mellan kombinationer av dessa koncept. PACELC-satsen som beskrivs av Daniel J. Abadi  PACELC introducerar två distinkta driftsätt för distribuerade system:    (   ): Vilken avvägning gör systemet när en partition inträffar? Här återgår vi till den klassiska CAP-avvägningen mellan   och   . Partitionsläge PAC tillgänglighet (A) konsekvens (C)    (   ): Vilken avvägning gör systemet när det inte finns någon partition och nätverket fungerar normalt? I det här läget står systemet inför en annan kompromiss - mellan   och   .  Else-läge ELC latens (L) konsistens (C)  Avvägningen mellan latens och konsistens  Även om partitioner är oundvikliga i distribuerade system är de sällsynta jämfört med de utmaningar som uppstår under normal drift. I moderna distribuerade system är   ofta en större flaskhals än nätverkspartitioner, särskilt för globala applikationer. Det är här   fokuserar - genom att ta itu med de avvägningar som uppstår när systemet fungerar utan partitioner. Till skillnad från CAP, som enbart fokuserar på beteende under felscenarier, betonar PACELC de beslut som arkitekter måste fatta varje dag för att balansera   och   : latens PACELC latens (L) konsekvens (C)    kräver koordinering och synkronisering mellan noder för att upprätthålla en enhetlig bild av data. Denna overhead introducerar förseningar, vilket saktar ner svarstiderna. Stark konsistens    (som de som antar eventuell konsistens) prioriterar hastighet genom att mildra konsistensgarantierna. Dessa system svarar snabbare men kan ibland returnera inaktuella eller inkonsekventa data. System med låg latens  Genom att utöka konversationen bortom partitioner till att omfatta normal drift, säkerställer PACELC att den dagliga prestandan för distribuerade system behandlas med den vikt den förtjänar.  Slår ihop det  Formuleringen av CAP-teoremet har varit en betydande händelse i samhället, och studier av dess inverkan på distribuerade systemdesign har visat att designers av distribuerade system inte bör begränsa systemet till två egenskaper - de bör sträva efter att maximera de garantier som krävs i varje särskilt fall. För detta ändamål är det rimligt att dela upp systemet i segment, som vart och ett har sina egna krav, och att utforma systemet utifrån kraven i vart och ett av segmenten.  CAP-satsen har varit en hörnsten i distribuerade systemtänkande i årtionden. Det gav oss ett ramverk för att resonera om de inneboende avvägningarna av konsekvens, tillgänglighet och partitionstolerans. Men på många sätt är det en förenkling av verkligheten, antar binära val och ignorerar kritiska faktorer som latens.  PACELC bygger på CAP och erkänner att:   Avvägningar finns även när partitioner inte gör det.    inom distribuerad systemdesign. Latens är ett förstklassigt problem  Både CAP och PACELC är värdefulla verktyg, men inte heller ett steg-för-steg-recept för att bygga system. Istället tillhandahåller de   för att utvärdera avvägningar och förstå gränserna för distribuerade arkitekturer. mentala modeller  Ytterligare material   CAP tolv år senare: Hur "reglerna" har förändrats   Cassandra: The Definitive Guide    och  Vänligen sluta kalla databaserna CP eller AP A Critique of the CAP Theorem av Martin Kleppmann   Anteckningar om distribuerade system för unga blod   Tack för att du läser!   Nyfiken på något eller har tankar att dela med dig av? Lämna din kommentar nedan! Kolla in   eller följ mig via   ,   eller   . min blogg LinkedIn Substack Telegram

Subscribe

Buy My Book

Det här ljudet är producerat på berättelsens originalspråk!

För länge; Att läsa

Make resilience your competitive advantage

Varför distribuerade system inte kan ha allt

About Author

KOMMENTARER

HÄNG TAGGAR

DENNA ARTIKEL PRESENTERAS I

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps