🥇Schrödingeri kass ilma kastita: konsensuse probleem jaotatud süsteemides

Kujutage ette. Toas on kinni 5 kassi ja et minna äratama peremeest, peavad nad kõik koos omavahel kokku leppima, sest nad saavad ukse avada ainult siis, kui kõik viis koondavad oma jõud selle peale. Kui üks kass on Schrödingeri kass ja teised kassid ei tea tema otsusest, tekib küsimus: "Kuidas nad seda teha saavad?"

Selles artiklis selgitan lihtsas keeles ja selgelt teoreetilisi aluseid ja printsiibu, mis puudutavad jaotatud süsteeme. Samuti vaatame pinnapealselt Paxosi peamist ideed.

Kui arendajad kasutavad pilveteenuseid, erinevaid andmebaase ja töötavad suure arvu sõlmedega klastris, usuvad nad, et andmed on kogu aeg terved, ohutud ja alati kergesti kättesaadavad. Aga kust tulenevad need garantiid?

Koheselt on meil olemas olemasolevad garantiid, ning need on tarnija garantii. Need on dokumenteeritud enam-vähem järgmiselt: "See teenus on piisavalt usaldusväärne, tal on määratud SLA, ärge muretsege, kõik töötab jaotatult nagu te ootate."

Me kalduvad uskuma parimat, kuna suured ettevõtted on meid veennud, et kõik on hästi. Me ei küsige endalt: miks see üldse võiks toimida? Kas on olemas mingid formaalsed põhjendused selliste süsteemide korrektsuse jaoks?

Hiljuti käisin jaotatud arvutuste koolis ja see inspireeris mind väga. Koolis toimunud loengud meenutasid pigem matemaatilise analüüsi tunde kui midagi seoses arvutite süsteemidega. Kuid just nii on ajalooliselt tõestatud olulisi algoritme, mida me kasutame igapäevaselt, ja ei kahtle selles.

Enamikus kaasaegsetes jaotatud süsteemides on kasutusel Paxosi konsensuse algoritm ja selle erinevad modifikatsioonid. Mis on kõige huvitavam, on see, et algoritmi olemasolu ja selle õigustamine on võimalik tõestada lihtsalt pliiatsi ja paberiga. Samuti rakendatakse algoritmi praktikas suurtes süsteemides, mis töötavad tohutu arvu sõlmedega pilves.

Kerge illustratsioon sellest, millest edaspidi räägitakse: kahe kindraliga ülesanne.Alustame soojenduseks kahe kindraliga ülesande lahendamisega..

Meil on kaks armeed – punased ja valged. Valged väed asuvad piiratavas linnas. Punased väed, mida juhivad kindralid A1 ja A2, on paigutatud linna mõlemale poole. Punaste eesmärk on rünnata valget linna ja võita. Kuid iga punase kindrali vägi on eraldi väiksem valgete omast.

Punaste võidu tingimused: mõlemad kindralid peavad ründama samaaegselt, et omada ülekaalu valgete üle. Selleks peavad kindralid A1 ja A2 omavahel kokku leppima. Kui igaüks ründab eraldi, kaotavad punased.

Kokkuleppimiseks saavad kindralid A1 ja A2 saata sõnumitoojaid valge linna territooriumi kaudu. Sõnumitooja võib edukalt jõuda liitlase kindrali juurde või võib protivnik teda tabada. Küsimus: kas on selline suhtlemise järjestus punaste kindralite vahel (sõnumitoojate saatmise järjestus A1-st A2-sse ja A2-st A1-sse), millega nad garanteeritult kokku leppida rünnaku ajaks X. Siin mõistetakse garantii all, et mõlemad kindralid saavad üheselt kinnitust, et liitlane (teine kindral) ründab kindlalt määratud ajal X.

Oletame, et A1 saadab A2-le sõnumitooja, kes toob sõnumi: "Ründame täna keskööl!". Kindral A1 ei saa rünnata ilma kinnituse saanud A2-lt. Kui A1 sõnumitooja jõuab kohale, saadab kindral A2 kinnituse sõnumiga: "Jah, ründame täna valgeid". Kuid nüüd ei tea kindral A2, kas tema vasta sõnumitooja jõudis kohale või mitte, tal ei ole garanteeritud rünnaku samaaegsust. Nüüd peab üldiselt A2-le uuesti kinnitus olema.

Kui analüüsida nende suhtlust edasi, selgub midagi sellist: ükskõik, kui palju sõnumivahetus tsükleid toimub, ei ole viisi, kuidas kummagi kindrali sõnumeid garanteeritult kätte toimetada (eeldusel, et ükskõik milline sõnumitooja võib olla tabatud).

Kahe kindrali ülesanne on suurepärane illustreerimine väga lihtsast jaotatud süsteemist, kus on kaks sõlme ebausaldusväärse suhtlemisega. See tähendab, et meil ei ole 100% garantiid, et nad sünkroniseeruvad. Sellistelt probleemidelt räägitakse täiendavalt artikli suuremal hulgal.

Sissejuhatus jaotatud süsteemide mõistesse.

Jagatud süsteem on arvutite rühm (edaspidi nimetame neid sõlmedeks), mis saavad vahetada sõnumeid. Iga eraldi sõlm on autonoomne entiteet. Sõlm suudab iseseisvalt tööülesandeid täita, kuid teiste sõlmedega suhtlemiseks peab ta saatma ja vastuvõtma sõnumeid.

Kuidas sõnumid täpselt teostatakse, milliseid protokolle kasutatakse – see meid antud kontekstis ei huvita. Oluline on, et jagatud süsteemi sõlmed saavad vahetada andmeid, saates teineteisele sõnumeid.

Isegi kui määratlemine tundub lihtne, tuleb arvestada, et jagatud süsteemil on rida atribuutide, mis on meie jaoks olulised.

Jagatud süsteemide atribuudid

Samaegne töötlus – võimalus, et süsteemis esinevad samaaegsed või konkurentsed sündmused. Veelgi enam, me arvestame, et sündmused, mis toimuvad kahel erineval sõlmel, on potentsiaalselt konkurentsed, kuni meil pole selget sündmuste järjekorda. Ja tavaliselt pole meil seda.
Globaalsete kellade puudumine. Meil ei ole sündmuste selget järjekorda, kuna globaalsed kellad puuduvad. Tavalises inimestemaailmas oleme harjunud, et meil on kellad ja aeg on absoluutne. Kõik muutub, kui rääkida jagatud süsteemidest. Ieven kui supertäpsetel aatomikelladel on drift, võivad esineda olukorrad, kus me ei suuda öelda, kumb kahest sündmusest toimus esimesena. Seetõttu ei saa me ka ajale toetuda.
Sõlmede sõltumatu rike süsteemis. On veel üks probleem: midagi võib lihtsalt valesti minna, kuna meie sõlmed ei ole igavesed. Kõvaketas võib rikkuda, virtuaalkompuuter võib pilves taaskäivituda, võrk võib vahelduda ja sõnumid võivad kaduda. Veelgi enam, võivad esineda olukorrad, kus sõlmed töötavad, kuid tegutsevad süsteemi vastu. Selle viimase klassi probleem on isegi saadud eraldi nime: byzantine generaalide probleem. Kõige populaarsem näide jagatud süsteemist, kus esineb selline probleem, on Blockchain. Kuid täna me seda spetsiaalset probleemide klassi ei käsitle. Meid huvitavad olukorrad, kus lihtsalt üks või mitu sõlme võivad rikke põhjustada.
Kommunikatsioonimudelid (sõnumite vahetuse mudelid) sõlmede vahel. Oleme juba tuvastanud, et sõlmed suhtlevad sõnumite vahetamise kaudu. On kaks tuntud sõnumite vahetuse mudelit: sünkroonne ja asünkroonne.

Jagatud süsteemide sõlmede vahelised kommunikatsioonimudelid

Sünkroonne mudel – me teame täpselt, et olemas on lõplik tuntud ajavahemik, mille jooksul sõnum jõuab garantii alusel ühest sõlmest teise. Kui see aeg on möödas ja sõnum pole saabunud, saame julgelt öelda, et sõlm on välja langenud. Sellises mudelis on meil etteennustatav ooteaeg.

Asünkroonne mudel – asünkroonsetes mudelites eeldame, et ooteaeg on piiratud, kuid ei ole olemas sellist ajavahemikku, pärast mida saab garantii, et sõlm on välja langenud. See tähendab, et sõnumi ooteaeg sõlmest võib olla piiratud ajatu. See on oluline määratlemine ja me räägime sellest hiljem.

Konsensuse mõisted jagatud süsteemides

Enne kui määratleme konsensuse mõiste formaalselt, vaatame näidet olukorrast, kus see on vajalik, nimelt – State Machine Replication.

Meil on teatud jagatud logi. Me tahaksime, et see oleks järjepidev ja sisaldaks identseid andmeid kõigis jagatud süsteemi sõlmedes. Kui mõni sõlm saab teada uue väärtuse, mille ta tahab logisse kirjutada, on tema ülesanne see väärtus kõigile teistele sõlmedele ettepanekuna esitada, et logi uuendataks kõigil sõlmedel ning süsteem läheks uude järjepidevasse olekusse. Oluline on, et sõlmed oleksid omavahel kokku leppinud: kõik sõlmed on nõustunud, et ettepanek uus väärtus on õige, kõik sõlmed on selle väärtuse vastu võtnud, ja ainult sel juhul saavad kõik logisse uue väärtuse kirjutada.

Teisisõnu: ükski sõlm ei vaidanud, et tal on aktuaalsem teave ja ettepanek, et väärtus on vale. Sõlmede vaheline kokkulepe ja konsensus ühiselt aktsepteeritud väärtuste osas on see, mis on konsensus jagatud süsteemis. Edasi räägime algoritmidest, mis võimaldavad jagatud süsteemil garanteeritult konsensusele jõuda.

Rohkem formaalselt saame konsensuse algoritmi (või lihtsalt konsensuse algoritmi) määratleda kui mingit funktsiooni, mis viib jaotatud süsteemi seisundist A seisundisse B. Oluline on, et see seisund oleks kõikide sõlmede poolt aktsepteeritud ja kõik sõlmed suudaksid seda kinnitada. Nagu selgub, ei ole see ülesanne sugugi nii triviaalne, nagu esmapilgul võib paista.

Konsensuse algoritmi omadused

Konsensuse algoritmil peavad olema kolm omadust, et süsteem saaks jätkata eksisteerimist ja omada mingit progressi seisundist seisundisse liikumisel:

Leppimine – kõik õigesti töötavad sõlmed peavad aktsepteerima sama väärtust (selles artiklis nimetatakse seda omadust ka ohutuse omaduseks). Kõik sõlmed, mis praegu töötavad (ei ole rikki läinud ega kaotanud ühendust teistega) peavad omavahel leppima ja aktsepteerima mingit lõplikku ühist väärtust.
Siinkohal on oluline mõista, et sõlmedes arutletavas jaotatud süsteemis on soovi leppida kokku. Püüame rääkida süsteemidest, kus võib juhtuda, et midagi ebaõnnestub (nt mõni sõlm ebaõnnestub), kuid selles süsteemis ei ole sõlmi, mis töötavad teadlikult teiste vastu (biitantsed generaatorid). Tänu sellele omadusele jääb süsteem järjekindlaks.
Integreerimine — kui kõik õigesti töötavad sõlmed pakuvad sama väärtust v, siis peab iga õigesti töötav sõlm selle väärtuse aktsepteerima v.
Lõpetamine – kõik õigesti töötavad sõlmed lõpuks aktsepteerivad mingi väärtuse (elavuse omadus), mis võimaldab algoritmil süsteemis edeneda. Iga eraldi õigesti töötav sõlm peab mingil hetkel aktsepteerima lõpliku väärtuse ja kinnitama: „Minule – see väärtus on tõene, nõustun kogu süsteemiga.”

Konsensuse algoritmi näide

Kuna algoritmi omadused võivad esialgu olla arusaamatud, illustreerime seda kõige lihtsama konsensuse algoritmi näitega, mis läbib etappe sümpaatiliselt ülesehitatud sõnumitevahetussüsteemis, kus kõik sõlmed toimivad nagu peab, sõnumid ei kao ja mitte midagi ei riku (kas see tõesti juhtuda võib?).

Kõik algab ettepanekust (Propose). Oletame, et sõlmele nimega „Sõlm 1” on ühendatud klient, kes alustas tehingut ning edastas sõlmele uue väärtuse – O. Alates sellest punktist hakkame „Sõlme 1” nimetama proposer. Kuidas proposer, peab „Sõlm 1” nüüd teavitama kogu süsteemi, et tal on värsked andmed, ja saadab teistele sõlmedele sõnumid: „Vaadake! Mul on tulnud väärtus „O” ja ma soovin selle salvestada! Palun kinnitage, et ka teie salvestate „O” oma logisse.”
Järgmine etapp on hääletamine pakutud väärtuse üle (Voting). Miks see vajalik on? Võib juhtuda, et teistel sõlmedel on saanud värskemat teavet ja neil on selle sama tehinguga seotud andmeid.

Kui sõlm „Sõlm 1” saadab oma ettepaneku, siis vaatavad teised sõlmed oma logidest selle sündmuse andmeid. Kui vastuolusid ei esine, teatavad sõlmed: „Jah, minult ei tule selle sündmuse kohta teisi andmeid. Väärtus „O” on kõige värskem info, mille me oleme saanud.”
Muudel juhtudel võivad sõlmed vastata „Sõlm 1” jaoks: „Kuule! Mul on selle tehingu kohta värskemaid andmeid. Mitte „O”, vaid midagi paremat.”
Hääletuse etapis jõuavad sõlmed otsusele: kas kõik aktsepteerivad sama väärtuse või keegi neist hääletab vastu, märgides, et tal on värskemaid andmeid.
Kui hääletusvoor on õnnestunud, ja kõik olid „ja”, siis liigub süsteem järgmisse etappi – väärtuse aktsepteerimine (Accept). „Sõlm 1” kogub teiste sõlmede kõik vastused ja teatab: „Kõik on nõustunud väärtusega „O”! Nüüdsest kuulutan ma ametlikult, et „O” on meie uus väärtus, kõigi jaoks ühine! Salvestage see endale, ärge unustage. Salvestage oma logisse!”
Teised sõlmed saadavad kinnituse (Accepted), et nad on salvestanud väärtuse „O”, ei ole midagi uut sisse tulnud (omaette kahefaasiline kinnitamine). Pärast seda märkimisväärset sündmust loeme, et jaotatud tehing on täidetud.

Nii koosneb konsensuse algoritm lihtsas vormis neljast sammust: ettepanek, hääletamine, aktsepteerimine, aktsepteerimise kinnitamine.

Kui mõnes etapis ei õnnestunud jõuda konsensusele, käivitub algoritm uuesti, arvestades teavet, mida annavad sõlmed, kes ei nõustunud pakutud väärtust kinnitama.

Konsensuse algoritm asünkronses süsteemis

Kuni kõik oli sujuv, rääkisime sünkroonsest sõnumivahetusmudelile. Kuid me teame, et tänapäeva maailmas oleme kõik harjunud tegema asünkroonselt. Kuidas siis sarnane algoritm töötab süsteemis, kus on asünkroonse sõnumivahetuse mudel, kus me arvame, et vastuse ootamine sõlmele võib olla lõpmatult pikk (muide, sõlme rike võib samuti olla näide, kui sõlm võib vastata lõpmatult kaua).

Nüüd, kui me teame, kuidas põhimõtteliselt konsensusalgoritm töötab, on küsimus neile uudishimulikele lugejatele, kes on siia jõudnud: kui palju sõlmi N sõlmest asünkroonses sõnumivahetussüsteemis võib rikki minna, et süsteem saaks endiselt konsensusele jõuda?

Õige vastus ja põhjendus on spoileris.Õige vastus: 0. Kui vähemalt üks sõlm asünkroonses süsteemis rikki läheb, ei suuda süsteem konsensusele jõuda. Seda väidet tõestatakse tuntud teoreemi FLP (1985, Fischer, Lynch, Paterson) puhul, mille originaali link on artikli lõpus: "Rikkumise korral ei saa saavutada jaotatud konsensust, kui vähemalt üks sõlm on rikki läinud."

Poisid, siis on meil probleem, me oleme harjunud, et kõik on asünkroone. Ja nüüd on selline asjaolu. Kuidas edasi elada?

Me rääkisime praegu teooriast, matemaatikast. Mida tähendab "konsensus ei saa olla saavutatud", tõlkides matemaatilisest keelest meie – insenerikeelde? See tähendab, et "ei pruugi alati olla saavutatud", st on olemas selline juhtum, kus konsensus ei ole saavutatav. Mis juhtum see siis on?

See on täpselt liveness property rikkumine, mida eespool kirjeldati. Meil ei ole ühisele nõusolekule, ning süsteem ei saa edusamme teha (ei saa lõppeda piiratud ajas) juhul, kui meil ei ole kõigilt sõlmedelt vastust. Sest asünkroonses süsteemis ei ole meil ennustatavat vastusaega ja me ei saa teada, kas sõlm on rikki läinud või lihtsalt vastab pika aja jooksul.

Kuid praktikas saame lahenduse leida. Oletame, et meie algoritm võib vigastuste korral kaua töötada (potentsiaalselt võib töötada lõputult). Kuid enamikus olukordades, kus enamus sõlmi töötab tõrgeteta, saavutame süsteemis edusamme.

Praktikas puutume kokku osaliselt sünkroonsete kommunikatsioonimudelitega. Osalist sünkroonsust mõistetakse nii: tavaliselt on meil asünkroonne mudel, kuid ametlikult tuuakse sisse mingi mõiste "global stabilization time" mingist ajast.

See ajamoment võib mitte tulla lõputult kaua, kuid ühel päeval peab see kindlasti toimuma. Virtuaalne äratus heliseb ja alates sellest hetkest saame ennustada ajavahemikku, mille jooksul sõnumid kohale jõuavad. Sellest hetkest muutub asünkroonne süsteem sünkroonses süsteemiks. Praktikas puutume kokku just selliste süsteemidega.

Paxos algoritm lahendab konsensuse probleemid

Paxos – see on algoritmide perekond, mis lahendab konsensuse probleemi osaliselt sünkroonses süsteemis, eeldusel, et mõned sõlmed võivad rikki minna. Paxose autor on Leslie Lamport.Ta esitas 1989. aastal algoritmi olemasolu ja õigsuse ametliku tõestuse.

Kuid tõestamine osutus kaugel lihtsaks. Esimene publikatsioon ilmus alles 1998. aastal (33 lehekülge), kus kirjeldati algoritmi. Nagu selgus, oli see äärmiselt keeruline mõista, ja 2001. aastal ilmus artikli selgitus, mis hõivas 14 lehte. Publikatsioonide mahud on toodud selleks, et näidata, et tegelikult on konsensuse probleem üsna keeruline ning selliste algoritmide taga on tohutu töö kõige targemate inimeste poolt.

Huvitav, et Leslie Lamport ise märkis oma loengus, et teises selgitavas artiklis on üks väide, üks rida (ta ei täpsustanud, milline), mille tõlgendamine võib olla erinev. Ja seetõttu toimib suur hulk tänapäevaseid Paxose rakendusi mitte täiesti korrektselt.

Paxose toimimise üksikasjalik analüüs väärib mitut artiklit, seetõttu püüan väga lühidalt edastada algoritmi põhikontseptsiooni. Artikli lõpus leiate viiteid aine sügavamaks uurimiseks.

Rollen Paxoses

Paxose algoritmis on olemas rollide mõisted. Vaatame kolme peamist (on ka modifikatsioone, kus on lisarolle):

Proposers (võivad esineda ka terminid: liidrid või koordinaatorid).Need on inimesed, kes saavad teada mõne uuest väärtusest kasutajalt ja võtavad juhtrolli. Nende ülesanne on käivitada uue väärtuse ettepaneku voor ja koordineerida edasised toimingud sõlmedega. Paxos lubab teatud olukordades mitu liidrit.
Acceptors (Voters). Need on sõlmed, mis hääletavad, kas aktsepteerida või tagasi lükata teatud väärtus. Nende roll on väga oluline, kuna just nemad otsustavad, milliseks olekuks süsteem läheb (või ei lähe) pärast konsensuse algoritmi järgmiste etappide läbiviimist.
Kasutajad. Need on sõlmed, mis lihtsalt aktsepteerivad ja salvestavad uut aktsepteeritud väärtust, kui süsteemi olek muutub. Nad ei tee otsuseid, vaid saavad andmeid ja saavad neid edasi anda lõppkasutajale.

Üks sõlm võib erinevates olukordades täita mitmeid rolle.

Kvoorumi mõisted

Eeldame, et meie süsteem koosneb N sõlmest. Ja neist võib maksimum F sõlme minna välja. Kui F sõlme suudab halveneda, peab meie klastris olema vähemalt 2F + 1 aktsepteerijat.

See on vajalik, et meil oleks alati, isegi halvima olukorra korral, „head”, korralikult töötavad sõlmed, kes moodustavad enamuse. See tähendab, et on vähemalt F + 1 „head” sõlme, kes on selle poolt, ja lõplik väärtus võetakse vastu. Vastasel korral võib juhtuda, et meie erinevad kohalikud grupid võtavad vastu erinevaid väärtusi ja ei suuda omavahel kokku leppida. Seepärast vajame absoluutset enamust, et võita hääletusel.

Paxos konsensuse algoritmi üldine idee

Paxose algoritm koosneb kahest suurest faasist, mis jagunevad omakorda kaheks samaksmiseks:

Faas 1a: Ettevalmistamine. Ettevalmistuse etapis teatab liider (proposser) kõikidele sõlmedele: „Alustame uut hääletusfaasi. Meil on uus voor. Selle vooru number on n. Nüüd hakkame hääletama”. Praegu teatab ta lihtsalt uue tsükli algusest, kuid ei ava uut väärtust. Loomise ülesanne on alustada uut vooru ja anda kõigile selle unikaalne number. Vooru number on oluline, see peab olema suurem kui kõik eelnevad hääletusnumbrid kõigilt eelnevatelt liidritelt. Just tänu vooru numbrile mõistavad teised süsteemi loksud, kui värsked andmed liider on. Tõenäoliselt on teistel sõlmedel juba hilisema vooru hääletamise tulemused ja nad teatavad lihtsalt liidrile, et ta on maha jäänud.
Faas 1b: Lubadus. Kui aktsepteerivad sõlmed on saanud uue hääletusfaasi numbri, on kaks võimalikku tulemust:
- Uue hääletuse number n on suurem kui ükskõik milline eelnevate hääletuste number, milles aktsepteerija osales. Siis saadab aktsepteerija liidri lubaduse, et ta ei osale enam hääletustes, kus numbri väärtus on väiksem kui n. Kui aktsepteerija on juba millegi poolt hääletanud (st on juba teises faasis mingit väärtust aktsepteerinud), siis lisab ta oma lubadusele aktsepteeritud väärtuse ja hääletuse numbri, milles ta osales.
- Teisest küljest, kui aktsepteerija teab hääletusest, mille number on suurem, võib ta lihtsalt ettevalmistuse etapi ignoreerida ning liidri küsimusele ei vasta.
Faas 2a: Aktsepteerimine. Liider peab ootama kvora (süsteemis olevate sõlmede enamuse) vastust ja, kui vajalik number vastuseid on saadud, on tal kaks võimalikku väljundit:
- Mõned aktsepteerijad saatsid väärtusi, mille poolt nad juba hääletasid. Sellisel juhul valib liider väärtuse hääletusest, mille number on suurim. Nimega x, ja saadab kõikidele sõlmedele sõnumit kujul: „Aktsepteeri (n, x)”, kus esimene väärtus on hääletuse number oma sama Propose'i etapist, ja teine väärtus on see, mille pärast kõik kokku tulid, st väärtus, mille kohta hääletatakse.
- Kui ükski aktsepteerija ei saatnud mingeid väärtusi, vaid lihtsalt lubasid hääletada selle vooru jooksul, võib liider neile pakkuda hääletada oma väärtuse üle, selle üle, mille pärast ta isegi liider sai. Nimega y. Ta saadab kõikidele sõlmedele sõnumit kujul: „Aktsepteeri (n, y)”, sarnaselt eelmistele väljunditele.
Faas 2b: Aktsepteeritud. Edasi, aktsepteerivad sõlmed, saadud sõnumiga „Aktsepteeri(…)” liiderelt nõustuvad temaga (saadavad kõigile sõlmedele kinnituse, et nad on uue väärtusega nõus) ainult siis, kui nad ei ole lubanud mingile (teisele) liidrile osaleda hääletustes, mille vooru number n’ > n, vastasel juhul ignoreerivad nad kinnituse päringut.
Kui liidrile on vastanud enamuse sõlmedest, ja kõik nad on uut väärtust kinnitanud, loetakse uus väärtus aktsepteerituks. Hurraa! Kui aga enamust ei saavutata või on sõlmed, kes keeldusid uue väärtuse vastuvõtmisest, algab kõik uuesti.

Nii töötab Paxose algoritm. Igal neist etappidest on palju nüansse, me ei käsitlenud praktiliselt erinevaid rikke tüüpe, mitmerealise liidri probleeme ja palju muud, kuid selle artikli eesmärk on tutvustada lugejat jagatud arvutuse maailma pealiskaudselt.

Oluline on märkida, et Paxos ei ole ainus oma liigis, on ka teisi algoritme, näiteks Raft, kuid see on juba teema teiseks artikliks.