Waarom verspreide stelsels nie alles kan hê nie

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 ACID vs. BASE . 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.

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 ACID-transaksies nie . In CAP-stelling verwys dit na lineariseerbaarheid of sterk konsekwentheid . Dit beteken dat alle nodusse in 'n verspreide stelsel altyd 'n enkele, bygewerkte aansig van die data moet aanbied , 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.

💡 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 elke nie-falende nodus 'n antwoord moet gee vir elke versoek wat dit ontvang, ongeag netwerkpartisies . Met ander woorde, as 'n gesonde nodus 'n versoek kry, moet dit verwerk en daarop reageer. CAP waarborg egter nie dat die antwoord altyd "korrek" of op datum sal wees nie - dit verseker net dat die nodus nie stilweg misluk nie (byvoorbeeld, in AP-stelsel kan nodusse reageer met verouderde data tydens 'n partisie om beskikbaarheid te verseker ).

💡 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 reaksietyd (of time-outs) 'n kritieke rol in die vorming van jou SLA (diensvlakooreenkoms), alhoewel CAP self nie regstreeks rekening hou met latensie nie. Meer daaroor in hierdie blogpos .

Partisieverdraagsaamheid

Partisieverdraagsaamheid gaan alles daaroor om netwerkfoute te oorleef. 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. 'n Partisie vind plaas wanneer nodusse nie kan kommunikeer nie weens pakkies wat gedaal is, uitteltyd of netwerkverdelings.

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 is partisieverdraagsaamheid ononderhandelbaar in enige verspreide stelsel - 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.

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 netwerkpartisie 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:

1. As een deel van die stelsel opdaterings aanvaar terwyl die ander geïsoleer is, sal die twee dele inkonsekwente toestande hê. Dit lei tot 'n verlies van C (Konsekwentheid) .
2. As die stelsel kies om konsekwent te bly , 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 A (Beskikbaarheid) omdat sommige versoeke vir 'n onbepaalde tyd geweier of vertraag sal word.
3. As die stelsel kies om beskikbaar (A) en konsekwent (C) te bly 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.

Dus, tydens 'n partisie , kan die stelsel slegs twee van die drie eienskappe (C, A of P) bevredig. Sodra die partisie opgelos is (dws die nodusse weer in wisselwerking tree), kan die stelsel al drie eienskappe herwin, maar tydens die partisie self is afwykings onvermydelik.

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 konsekwentheid (C) en beskikbaarheid (A) - slegs van toepassing is wanneer 'n netwerkpartisie (P) 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.

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 latency nie, alhoewel latency en partisionering in die praktyk diep verbind is. Byvoorbeeld:

• '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 uittelperiode : 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.

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 :

• Beskikbaarheid 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.
• Konsekwentheid het verskillende vlakke, van uiteindelike konsekwentheid tot oorsaaklike konsekwentheid tot sterk konsekwentheid. Nie elke toepassing vereis volle lineariseerbaarheid nie.
• Partisieverdraagsaamheid 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).

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. Die PACELC-stelling wat deur Daniel J. Abadi beskryf word, 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.

PACELC stel twee afsonderlike werkswyses vir verspreide stelsels bekend:

1. Partisiemodus ( PAC ): Watter afweging maak die stelsel wanneer 'n partisie plaasvind? Hier kyk ons weer na die klassieke GLB-afweging tussen beskikbaarheid (A) en konsekwentheid (C) .
2. Else-modus ( ELC ): 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 latensie (L) en 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 latency dikwels 'n groter bottelnek as netwerkpartisies, veral vir toepassings op wêreldwye skaal. Dit is waar PACELC 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 latensie (L) en konsekwentheid (C) te balanseer:

• Sterk konsekwentheid 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.
• Stelsels met lae latensie (soos dié wat uiteindelike konsekwentheid aanneem) prioritiseer spoed deur konsekwentheidswaarborge te verslap. Hierdie stelsels reageer vinniger, maar kan soms verouderde of inkonsekwente data terugstuur.

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.
• Latency is 'n eersteklas bekommernis in verspreide stelselontwerp.

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 verstandelike modelle om afwykings te evalueer en die grense van verspreide argitekture te verstaan.

Bykomende materiaal

• CAP Twaalf jaar later: hoe die "reëls" verander het
• Cassandra: Die definitiewe gids
• Hou asseblief op om databasisse CP of AP en A Critique of the CAP Theorem deur Martin Kleppmann te noem
• 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 my blog of volg my via LinkedIn , Substack of Telegram .