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

Nii, kujutame ette. Toas on lukus 5 kassi, ning et minna äratama peremeest, peavad nad kõik koos omavahel kokkuleppele jõudma, sest nad saavad ust avada ainult viiekesi sellele peale vajudes. Kui üks kassidest on Schrödingeri kass ja teised kassid ei tea tema otsusest, siis tekib küsimus: "Kuidas nad seda saavad teha?"

Selles artiklis räägin ma lihtsas keeles teile teoreetilistest alustest ja põhialustest jagatud süsteemide maailmas. Samuti vaatlen pinnapealselt Paxose peamist ideed.

Kui arendajad kasutavad pilve infrastruktuure, erinevaid andmebaase ja töötavad suure arvu sõlmedega klastrites, on nad kindlad, et andmed on terviklikud, turvalised ja alati kergesti kättesaadavad. Kuid kust tulevad need garantiid?

Tegelikult, mida me usaldame – need on tarnijate garantiid. Need on dokumenteeritud umbes järgmise viisil: "See teenus on piisavalt usaldusväärne, sellel on määratud SLA, ärge muretsege, kõik töötab jaotatult nagu teie ootused on."

Kaldume uskuma parimat, sest nutikad onud suurtest ettevõtetest on meid rahustanud, et kõik läheb hästi. Me ei sea endale küsimust: miks see ometi võib töötada? Kas on olemas mingi formaalne tõend selliste süsteemide töö korrektsuse kohta?

Hiljuti käisin jagatud arvutuskohtade koolis ja olin selle teemaga väga inspireeritud. Loengud koolis meenutasid rohkem matemaatilise analüüsi tunde, kui midagi, mis on seotud arvutisüsteemidega. Kuid just nii tõestati kunagi meie igapäevaselt kasutatavaid tähtsaid algoritme, isegi sellest aimamata.

Enamikus kaasaegsetes jagatud süsteemides kasutatakse konsensuse algoritmi Paxos ja selle erinevaid varieeruvaid versioone. Kõige ägedam on see, et selle algoritmi õigustamine ja selle olemasolu võimaluse tõestamine on võimalik lihtsalt pliiatsi ja paberiga. Samas rakendatakse algoritmi praktikas suurtes süsteemides, mis töötavad tohutu hulga sõlmedega pilvedes.

Kergesti mõistetav illustratsioon sellest, millest edaspidi jutt läheb: kahe kindraliga probleemAlustuseks vaadake kahe kindraliga probleemi.

Meil on kaks armee - punane ja valge. Valged väed paiknevad piiratud linnas. Punased väed, mida juhivad kindralid A1 ja A2, asuvad linnast mõlemal poole. Punaste ülesanne on rünnata valget linna ja võita. Siiski on iga punase kindrali vägi eraldi väiksem kui valgete vägi.

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

Kokkulepeteks võivad kindralid A1 ja A2 saata omavahel sõnumitoojaid läbi valge linna teritoriumi. Sõnumitooja võib jõuda liitlase kindrali juurde või võidakse ta kinni püüda vastase poolt. Küsimus: kas on olemas selline suhtlemise järjestus punaste kindralite vahel (sõnumitoojate saatmise järjestus A1-lt A2-le ja vastupidi A2-lt A1-le), mille korral nad garantii alusel lepivad kokku rünnakus kell X. Siin mõistetakse garanteerimise all, et mõlemad kindralid saavad selge kinnituse, et liitlane (teine kindral) ründab kindlasti määratud ajal X.

Oletame, et A1 saadab A2-le sõnumitooja sõnumiga: "Ründame täna keskööl!". Kindral A1 ei saa rünnata ilma kindral A2 kinnituse. Kui sõnumitooja A1-st on kohale jõudnud, saadab kindral A2 kinnituse sõnumiga: "Jah, ründame täna valgeid." Kuid nüüd ei tea kindral A2, kas tema sõnumitooja on kohale jõudnud või mitte, tal pole garanteeringut, kas rünnak toimub samaaegselt. Nüüd vajab A2 uuesti kinnitust.

Kui nende suhtlemist edasi lahti seletada, selgub järgnev: sõltumata sellest, kui palju sõnumite vahetamise tsükleid on, ei ole võimalik kindlalt teavitada mõlemat kindralit, et nende sõnumid on kätte saadud (tingimusel, et ükskõik milline sõnumitooja võib olla kinni peetud).

Kahe kindrali probleem on suurepärane illustreerimine väga lihtsast jaotatud süsteemist, kus on kaks sõlme ebausaldusväärse kommunikatsiooniga. See tähendab, et meil ei ole 100% garantiid, et nad sünkroniseeruvad. Sellistest probleemidest ainult suuremas ulatuses räägitakse hiljem artiklis.

Sisseviimine jaotatud süsteemide mõistet

Jaotatud süsteem on arvutite rühm (edaspidi nimetame neid sõlmedeks), mis saavad omavahel sõnumeid vahetada. Iga eraldi sõlm on mingi autonoomne entiteet. Sõlm võib iseseisvalt ülesandeid töötleda, kuid et suhelda teiste sõlmedega, peab ta saatma ja vastu võtma sõnumeid.

Kuidas sõnumid konkreetselt teostatakse, milliseid protokolle kasutatakse – see meid antud kontekstis ei huvita. Oluline on, et jaotatud süsteemi sõlmed saavad omavahel andmeid vahetada, saates sõnumeid.

Kuna määratlemine ei tundu keeruline, peame siiski arvestama, et jaotatud süsteemil on mitmeid atribuute, mis on meile olulised.

Jaotatud süsteemide atribuuti

Konkureerimine – võimalus, et süsteemis võivad tekkida samaaegsed või konkurentsivõimelised sündmused. Veelgi enam, me arvestame, et sündmused, mis toimuvad kahes erinevas sõlmes, on potentsiaalselt konkurentsivõimelised, kuni meil pole kindlat sündmuste tekkimise järjekorda. Ja reeglina pole meil seda olemas.
Globaalsete kellade puudumine. Meil pole kindlat sündmuste järjekorda, kuna puuduvad globaalne kellad. Tavalises inimmaailmas oleme harjunud, et meil on kellad ja aeg on absoluutne. Kõik muutub, kui räägime jaotatud süsteemidest. I даже сверхточные атомные часов имеют дрейф, и возможны ситуации, когда мы не можем сказать, какое из двух событий произошло раньше. Поэтому полагаться на время мы тоже не можем.
Süsteemi sõlmede sõltumatu rike. On veel üks probleem: midagi võib valesti minna lihtsalt seetõttu, et meie sõlmed ei ole igavesed. Kõvaketas võib rikkeda, pilves oleva virtuaali võib taaskäivitada, võrk võib murranguda ja sõnumid võivad kaduda. Veelgi enam, on võimalik, et sõlmed töötavad, kuid töötavad samal ajal süsteemi vastu. Viimane probleemide klass on isegi eraldi nime saanud: probleem Byzantine generaalide. Kõige populaarsem jaotatud süsteem, kus selline probleem esineb, on Blockchain. Kuid täna me ei käsitle seda erilisest probleemi klassist. Meid huvitavad olukorrad, kus lihtsalt üks või mitu sõlme võivad rikki minna.
Kommunikatsioonimudelid (sõnumite vahetamise mudelid) sõlmede vahelOleme juba välja selgitanud, et sõlmed suhtlevad omavahel sõnumite vahetamise teel. On kaks tuntud sõnumite vahetamise mudelit: sünkroonne ja asünkroonne.

Sõlmede vaheliste kommunikatsioonimudelite jagatud süsteemides

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

Asünkroonne mudel – asünkroonsetes mudelites arvame, et ooteaeg on lõplik, kuid ei eksisteeri sellist ajavahet, pärast mida saaks garanteerida, et sõlm on välja langenud. St. sõnumi ootamine ühest sõlmest võib kesta nii kaua, kui tahes. See on oluline määratlemine ja me rääkime sellest edasi.

Konsensuse mõisted jagatud süsteemides

Enne konsensuse mõiste ametlikku määratlemist vaatame näidet olukorrast, kus see on vajalik, nimelt – Oleku Masina Korrutamine.

Meil on teatud jagatud logi. Soovime, 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 plaanib logisse salvestada, on tema ülesanne pakkuda see väärtus kõigile teistele sõlmedele, et logi saaks uuendatud kõigis sõlmedes ja süsteem liiguks uude järjepidevasse olekusse. Oluline on, et sõlmed omavahel kokkulepiksid: kõik sõlmed nõustuvad, et pakutud uus väärtus on õige, kõik sõlmed aktsepteerivad selle väärtuse, ja ainult siis saavad kõik logisse kirjutada uue väärtuse.

Teisisõnu: ükski sõlm ei ole vaielnud vastu, et tal on värskemat teavet ja pakutud väärtus on vale. Sõlmedevaheline kokkulepe ja nõusolek ühtse õigesti vastuvõetud väärtuse osas ongi konsensus jagatud süsteemis. Jätkame rääkides algoritmidest, mis võimaldavad jagatud süsteemil konsensust tagada.

Rohkem formaalselt saame konsensuse saavutamise algoritmi (või lihtsalt konsensuse algoritmi) määratleda kui teatud funktsiooni, mis viib jaotatud süsteemi seisundist A seisundisse B. Samuti on see seisund kõigi sõlmede poolt tunnustatud ja kõik sõlmed saavad selle kinnitada. Kuidas selgub, on see ülesanne kaugel triviaalsest, nagu esmapilgul võib tunduda.

Konsensuse algoritmi omadused

Konsensuse algoritm peab omama kolme omadust, et süsteem jätkaks eksistentsi ja saavutaks mingit edasiminekut seisundi muutmisel:

Kokkulepe – kõik korralikult töötavad sõlmed peavad aktsepteerima sama väärtust (artiklites nimetatakse seda omadust sageli turvalisuse omaduseks). Kõik praegu toimivad sõlmed (mis ei ole rikki läinud ja ei ole kaotanud ühendust teistega) peavad saavutama kokkuleppe ja aktsepteerima mingit lõplikku ühist väärtust.
Siin on oluline mõista, et käsitletavas jaotatud süsteemis soovivad sõlmed kokkuleppele jõuda. See tähendab, et praegu räägime süsteemidest, kus midagi võib lihtsalt ebaõnnestuda (näiteks mõni sõlm võib ebaõnnestuda), kuid selles süsteemis ei ole sõlmi, mis töötavad teadlikult teiste vastu (bütsantsi kindralite probleem). Selle omaduse tõttu jääb süsteem järjepidevaks.
Integriteet – kui kõik korralikult töötavad sõlmed pakuvad sama väärtust, v, siis peab iga korralikult töötav sõlm selle väärtuse omaks võtma. v.
L lõpp – kõik korralikult töötavad sõlmed lõpuks aktsepteerivad mingit väärtust (aktiivsuse omadus), mis võimaldab algoritmil süsteemis edasiminekut. Iga üksik korralikult töötav sõlm peab varem või hiljem aktsepteerima lõpliku väärtuse ja kinnitama seda: "Minu jaoks on see väärtus tõene, ma nõustun kogu süsteemiga."

Konsensuse algoritmi töö näide

Kuna algoritmi omadused võivad olla mitte täielikult arusaadavad, illustreerime näitega, milliseid etappe läbib lihtsaim konsensuse algoritm sünkroonse sõnumivahetuse mudelis, kus kõik sõlmed töötavad nagu peab, sõnumid ei kao ja midagi ei riku (kas tõesti juhtub ka nii?).

Kõik algab käe ja südame ettepanekust (Propose). Oletame, et sõlme nimega "Sõlm 1" on ühendatud klient ja alustanud tehingut, edastades sõlmele uue väärtuse – O. Sellest hetkest alates nimetame "Sõlm 1". proposer. Nüüd peab proposer "Sõlm 1" teavitama kogu süsteemi, et tal on värskeid andmeid, ja ta saadab kõigile teistele sõlmedele sõnumid: "Vaadake! Minule on tulnud väärtus "O", ja ma tahan selle salvestada! Palun kinnitage, et te salvestate ka "O" oma logisse."
Järgmiseks staadiumiks on hääletamine ettepaneku üle (Voting). Miks see vajalik on? Võib juhtuda, et teistele sõlmedele on saadetud värskemat teavet ja neil on andmed selle sama tehingu kohta.

Kui sõlm "Sõlm 1" saadab oma ettepaneku, kontrollivad ülejäänud sõlmed oma logides selle sündmuse andmeid. Kui vastuolusid ei esine, kuulutavad sõlmed: "Jah, mul ei ole selle sündmuse kohta muid andmeid. Väärtus "O" on kõige värskem teave, mida me oleme saanud."
Mistahes muul juhul võivad sõlmed vastata "Sõlmele 1": "Kuule! Mul on selle tehingu kohta värskemaid andmeid. Ei ole "O", vaid midagi paremat."
Hääletamise staadiumis jõuavad sõlmed otsusele: kas kõik aktsepteerivad sama väärtuse või keegi neist häälestab vastu, märkides, et tal on värskemaid andmeid.
Kui hääletusvoor on läbinud edukalt ja kõik olid "poolt", liigub süsteem uude etappi – väärtuse aktsepteerimise (Accept). "Sõlm 1" kogub kõikide teiste sõlmede vastused ja teatab: "Kõik nõustusid väärtusega "O"! Nüüd kuulutan ametlikult, et "O" on meie uus väärtus, ühtne kõigile! Salvestage see oma märkmetesse, ärge unustage. Salvestage oma logisse!"
Teised sõlmed saadavad kinnituse (Accepted), et nad on salvestanud väärtuse "O", midagi uut ei ole vahepeal saabunud (teatud mõttes kahesammuline kinnitamine). Pärast seda olulist sündmust peame jaotatud tehingu läbituks.

Nii koosneb konsensuse algoritm lihtsaimal juhul neljast sammust: propose, hääletamine (voting), aktsepteerimine (accept), aktsepteerimise kinnitamine (accepted).

Kui mõnes etapis ei ole meil õnnestunud kokku leppida, käivitatakse algoritm uuesti, arvesse võttes teavet, mida esitavad sõlmed, kes keeldusid ettepaneku väärtuse kinnitamist.

Konsensusalgoritm asünkroonsetes süsteemis

Enne seda oli kõik sujuv, kuna jutt käis sünkroonsest sõnumite vahetuse mudelist. Kuid me teame, et tänapäeva maailmas oleme kõik harjunud asünkroonselt tegutsema. Kuidas siis sarnane algoritm töötab sõnumite asünkroonses vahetusmudelis, kus me arvame, et vastuse ootamine sõlme võib olla piiramatu (muide, sõlme rike on samuti juhul, kui sõlm võib vastata piiramatu aja vältel).

Nüüd, kui 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ünkroonse sõnumite mudeliga võivad välja langeda, et süsteem saaks endiselt konsensusele jõuda?

Õige vastus ja põhjendus on spoileri all.Õige vastus: 0. Kui vähemalt üks sõlm asünkroonses süsteemis välja langeb, ei suuda süsteem konsensusele jõuda. Seda väidet on tõestatud tuntud teoreemi FLP (1985, Fischer, Lynch, Paterson, original link artikli lõpus): «Konsensuse saavutamise võimatus vähemalt ühe sõlme väljalangemise korral».

Kallid, siis on meil probleem, oleme ju harjunud, et kõik on asünkroonse. Ja siin on selline olukord. Kuidas edasi elada?

Oleme just rääkinud teooriast, matematikast. Mida tähendab see «konsensus ei saa olla saavutatud», tõlgituna matemaatilisest keelest meie – inseneride keelde? See tähendab, et «ei pruugi alati olla saavutatud», st on olemas olukord, kus konsensus ei ole saavutatav. Mis see olukord siis on?

See on just nimelt elujõulisuse omaduse rikkumine, mida ülal mainiti. Meil ei ole ühist kokkulepet ja süsteem ei saa edeneda (ei saa lõppeda kindla aja jooksul), kui meil pole vastuseid kõikidelt sõlmedelt. Kuna asünkroonses süsteemis ei ole meil ettearvatavat vastusaega, ei saa me teada, kas sõlm on rikki läinud või lihtsalt vastab kaua.

Kuid praktikas saame leida lahenduse. Oletame, et meie algoritm võib töötada kaua tõrgete korral (potentsiaalselt võib töötada lõpmatuses). Kuid enamikus olukordades, kui enamus sõlmi töötab korrektselt, saame süsteemis edeneda.

Praktikas me tegeleme osaliselt sünkroonsete kommunikatsioonimudelitega. Osaline sünkroonilisus tähistab, et üldiselt on meil asünkrooniline mudel, kuid ametlikult määratakse kindlaks mõisted «global stabilization time» teatud ajahetkest.

See ajahetk ei pruugi kesta lõputult, kuid ühel päeval peab see siiski saabuma. Virtuaalne äratuskell heliseb ja alates sellest hetkest saame ennustada aega, mille jooksul sõnumid kohale jõuavad. Sellest hetkest muutub süsteem asünkroonilisest sünkroonseks. Praktikas tegeleme just selliste süsteemidega.

Paxose algoritm lahendab konsensuse probleeme.

Paxos See on algoritmide perekond, mis lahendab konsensuse probleemi osaliselt sünkroonsetes süsteemides, eeldusel, et mõned sõlmed võivad välja langeda. Paxose autori nimi on Leslie Lamport. Ta pakkus 1989. aastal välja algoritmi olemasolu ja õigsuse ametliku tõestuse.

Kuid tõestamine osutus kaugel sellest, et oleks triviaalne. Esimene publikatsioon ilmus alles 1998. aastal (33 lehekülge) algoritmi kirjeldusega. Selgus, et see oli äärmiselt keeruline mõistetavaks ja 2001. aastal avaldati artikli selgitus, mis hõlmas 14 lehekülge. Avalduste maht on toodud selleks, et näidata, et konsensuse probleem on tegelikult väga keeruline ja selliste algoritmide taga on tohutu töö tarkade inimeste seas.

Huvitav on see, et Leslie Lamport ise märkis oma loengus, et teises selgitavas artiklis on üks väide, üks lause (mida ta ei täpsustanud), mida võib tõlgendada erinevalt. Selle tõttu töötab suur hulk tänapäevaseid Paxose rakendusi mitte täiesti korrektselt.

Paxose toimimise üksikasjalik analüüs ei mahu ühte artiklisse, seega püüan ma väga lühidalt edastada algoritmi põhikomplekti. Artikli lõpus leiate viidatud materjalid selle teema sügavamaks uurimiseks.

Rollid Paxoses

Paxose algoritmis on rollide mõisted. Vaatame kolme peamist (on olemas modifikatsioone, kus on täiendavad rollid):

Proposers (võib kohata ka termineid: juhid või koordinaatorid)Need on inimesed, kes saavad kasutajalt uut väärtust ja võtavad juhtrolli. Nende ülesanne on alustada vooru uue väärtuse esitamiseks ja koordineerida edasisi samme sõlmedes. Paxos lubab teatud olukordades mitme juhi olemasolu.
Aktseptorid (Valijad)Need on sõlmed, mis hääletavad ühe või teise väärtuse vastuvõtmise või tagasi lükkamise üle. Nende roll on väga oluline, sest just nemad otsustavad, millisesse olekusse (või mitte) süsteem pärast konsensusalgoritmi järgmist etappi liigub.
ÕppijadNeed on sõlmed, mis lihtsalt vastu võtavad ja salvestavad uut vastuvõetud väärtust, kui süsteemi olek on muutunud. Nad ei tee otsuseid, nad lihtsalt saavad andmeid ja võivad neid edastada lõppkasutajale.

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

Kvoorumi mõisted

Eeldame, et meil on süsteem, mis koosneb N sõlmest. Ja neist võib maksimaalselt F sõlme väljuda. Kui F sõlme väljuda, peab meie klastris olema vähemalt 2F + 1 aktseptorit.

See on vajalik, et meil oleks alati, isegi halvimates olukordades, „head“, korrektselt toimivad sõlmed, kes omavad enamust. See tähendab, et meil on F + 1 „head“ sõlme, kes nõustusid, ja lõplik väärtus võetakse vastu. Vastupidisel juhul võib esineda olukord, kus erinevad kohalikud grupid aktsepteerivad erinevaid väärtusi ja ei suuda omavahel kokku leppida. Seetõttu on vajalik absoluutne enamus, et hääletuses võita.

Paxose konsensusalgoritmi üldine idee

Paxose algoritm eeldab kahte suurt etappi, mis jagunevad omakorda kaheks sammuks:

Faas 1a: Valmistamine. Eeln Preparation, esindaja (proposer) teatab kõigile sõlmedele: "Alustame uut hääletusfaasi. Meil on uus voor. Selle vooru number on n. Nüüd hakkame hääletama." Praegu teavitab ta lihtsalt uue tsükli algusest, kuid ei edasta uut väärtust. Selle etapi ülesanne on algatada uus voor ja teavitada kõiki selle ainulaadsest numbrist. Vooru number on oluline, see peab olema suurem kui kõik varasemad hääletusnumbrid kõigilt varasematelt esindajatelt. Just tänu vooru numbrile saab süsteemi teised sõlmed aru, kui värsked on esindaja andmed. Tõenäoliselt on teistel sõlmedel juba olemas hääletustulemused palju hilisemast voorust ja nad lihtsalt ütlevad esindajale, et ta on ajast maas.
Faas 1b: Lubadus. Kui acceptor-sõlmed on saanud uue hääletusfaasi numbri, on võimalik kaks tulemust:
- Uue hääletuse number n on suurem kui ükskõik milline eelneva hääletuse number, milles acceptor osales. Siis saadab acceptor esindajale lubaduse, et ta ei osale enam üheski hääletuses, mille number on väiksem kui n. Kui acceptor on juba millegi poolt hääletanud (st ta on juba teises faasis mingit väärtust vastu võtnud), siis lisab ta oma lubadusele vastu võetud väärtuse ja hääletuse numbri, milles ta osales.
- Teiselt poolt, kui acceptor teab juba suurema numbriga hääletusest, võib ta lihtsalt ettevalmistusetapi ignoreerida ja mitte esindajale vastata.
Faas 2a: Aktsepteerimine. Esindaja peab ootama vastust kvorumilt (enamuses sõlmedest süsteemis) ja kui vajalikud vastused on saadud, on tal kaks arenguteed:
- Mõned acceptorid saatsid väärtusi, mille poolt nad juba hääletasid. Sellisel juhul valib esindaja hääletuse maksimaalse numbri väärtuse. Nimetame seda väärtuseks x ja saadame kõigile sõlmedele sõnumi vormis: "Accept (n, x)", kus esimene väärtus on hääletuse number tema enda Propose sammus ja teine väärtus on see, millega kõik kokku tulid, st väärtus, mille poolt tegelikult hääletatakse.
- Kui ükski acceptor ei ole saadnud mingeid väärtusi ega ka lubanud hääletada käesolevas voorus, võib juht pakkuda neile hääletada oma väärtuse poolt, mille pärast ta üldse juht tuli. Nimeta seda y-ks. Ta saadab kõigile sõlmedele sõnumi vormis: «Accept (n, y)», sarnaselt eelnevale tulemile.
Faas 2b: Vastuvõetud. Edasi, acceptor-sõlmed, saades sõnumi «Accept(…)» juhilt, nõustuvad temaga (saadavad kõigile sõlmedele kinnituse, et nad nõustuvad uue väärtusega) ainult juhul, kui nad ei ole lubanud mingile (teisele) juhile osaleda voorude hääletustes numbriga n’ > n, vastasel juhul ignoreerivad nad kinnituse taotlust.
Kui juhile on vastanud enamus sõlmi ja kõik nad on kinnitanud uue väärtuse, siis loetakse uus väärtus heakskiidetuks. Hurraa! Kui enamus ei ole saavutatud või on sõlmed, kes on keeldunud uut väärtust vastu võtma, siis algab kõik alates algusest.

Nii töötab Paxos algoritm. Igal sellel etapil on palju nüansse, me ei ole praktiliselt käsitlenud erinevaid tõrkeid, mitme juhi probleeme ja palju muud, kuid selle artikli eesmärk on lihtsalt kõrgtaseme tutvustada lugejat jagatud arvutuste maailma.

Samuti tasub märkida, et Paxos ei ole ainus selline, olemas on ka teised algoritmid, näiteks Rafti, kuid see on juba teine artikkel.