Valdoma paskirstytoji konsensuso: nuodugni „Raft“ algoritmo implementacija pasaulinėms sistemoms

Vis labiau tarpusavyje susietame pasaulyje paskirstytosios sistemos yra beveik kiekvienos skaitmeninės paslaugos pagrindas, pradedant elektroninės komercijos platformomis ir finansų įstaigomis, baigiant debesų kompiuterijos infrastruktūra ir realaus laiko komunikacijos įrankiais. Šios sistemos suteikia neprilygstamą mastelio keitimą, prieinamumą ir atsparumą, paskirstydamos darbo krūvius ir duomenis tarp daugelio mašinų. Tačiau ši galia kelia didelį iššūkį: užtikrinti, kad visi komponentai sutartų dėl sistemos būsenos, net ir esant tinklo vėlavimams, mazgų gedimams ir lygiagrečioms operacijoms. Ši pagrindinė problema žinoma kaip paskirstytasis konsensusas.

Konsensuso pasiekimas asinkroninėje, gedimams jautrioje paskirstytoje aplinkoje yra itin sudėtingas. Dešimtmečius „Paxos“ buvo dominuojantis algoritmas šiam iššūkiui spręsti, gerbiamas dėl savo teorinio tvirtumo, tačiau dažnai kritikuojamas dėl sudėtingumo ir sunkumų įgyvendinant. Tada atsirado „Raft“, algoritmas, sukurtas su pagrindiniu tikslu: suprantamumas. „Raft“ siekia būti lygiavertis „Paxos“ atsparumo gedimams ir našumo požiūriu, tačiau struktūruotas taip, kad jį būtų daug lengviau suprasti ir plėtoti.

Šiame išsamiame vadove gilinamasi į „Raft“ algoritmą, nagrinėjami jo pagrindiniai principai, veikimo mechanizmai, praktiniai įgyvendinimo aspektai ir jo svarbus vaidmuo kuriant tvirtas, pasauliniu mastu paskirstytas programas. Nesvarbu, ar esate patyręs architektas, paskirstytųjų sistemų inžinierius, ar programuotojas, siekiantis kurti aukšto prieinamumo paslaugas, suprasti „Raft“ yra esminis žingsnis siekiant įsisavinti šiuolaikinės kompiuterijos sudėtingumą.

Būtinas paskirstytojo konsensuso poreikis šiuolaikinėse architektūrose

Įsivaizduokite pasaulinę elektroninės komercijos platformą, per sekundę apdorojančią milijonus operacijų. Klientų duomenys, atsargų lygis, užsakymų būsenos – visa tai turi išlikti nuoseklu daugybėje duomenų centrų, esančių per žemynus. Banko sistemos registras, išsklaidytas keliuose serveriuose, negali sau leisti net trumpalaikio nesutarimo dėl sąskaitos likučio. Šie scenarijai pabrėžia kritinę paskirstytojo konsensuso svarbą.

Natūralūs paskirstytųjų sistemų iššūkiai

Paskirstytosios sistemos savo pobūdžiu sukuria daugybę iššūkių, kurių nėra monolitiniuose programose. Šių iššūkių supratimas yra itin svarbus norint įvertinti „Raft“ tipo algoritmų eleganciją ir būtinybę:

• Dalinis gedimas: Skirtingai nei vienas serveris, kuris arba veikia, arba visiškai sužlunga, paskirstytoji sistema gali turėti keletą nesėkmingų mazgų, o kiti veikia toliau. Serveris gali sudužti, jo tinklo ryšys gali nutrūkti, arba jo diskas gali sugesti, o likęs klasteris veikia nepakitęs. Sistema turi toliau tinkamai veikti nepaisant šių dalinių gedimų.
• Tinklo skaidymas: Mazgus jungiantis tinklas ne visada yra patikimas. Tinklo skaidymas įvyksta, kai nutrūksta ryšys tarp mazgų pogrupių, dėl ko atrodo, kad tam tikri mazgai sugedo, nors jie vis dar veikia. Šių „suskaidyto smegenų“ scenarijų sprendimas, kai skirtingos sistemos dalys veikia nepriklausomai remdamosi pasenusia ar nuoseklia informacija, yra pagrindinė konsensuso problema.
• Asinkroninis bendravimas: Pranešimai tarp mazgų gali vėluoti, persirikiuoti arba visai dingti. Nėra pasaulinio laikrodžio ar garantijos dėl pranešimų pristatymo laiko, todėl sunku nustatyti nuoseklią įvykių tvarką arba galutinę sistemos būseną.
• Lygiagretumas: Daugelis mazgų gali bandyti vienu metu atnaujinti tą pačią duomenų dalį arba inicijuoti veiksmus. Be koordinavimo mechanizmo, konfliktai ir nesuderinamumai yra neišvengiami.
• Nenuspėjamas vėlavimas: Ypač pasauliniu mastu paskirstytuose diegimuose tinklo vėlavimas gali labai skirtis. Operacijos, kurios viename regione yra greitos, kitame regione gali būti lėtos, paveikdamos sprendimų priėmimo procesus ir koordinavimą.

Kodėl konsensusas yra patikimumo kertinis akmuo

Konsensuso algoritmai suteikia pagrindinį statybinį bloką šiems iššūkiams spręsti. Jie leidžia nepatikimų komponentų rinkiniui kolektyviai veikti kaip vieningam, labai patikimam ir nuosekliam vienetui. Konkrečiai, konsensusas padeda pasiekti:

• Būsenos mašinos replikavimas (SMR): Pagrindinė idėja, slypinti daugelyje atsparių gedimams paskirstytųjų sistemų. Jei visi mazgai sutinka dėl operacijų tvarkos, ir jei kiekvienas mazgas pradeda nuo tos pačios pradinės būsenos ir vykdo tas operacijas ta pačia tvarka, visi mazgai pasieks tą pačią galutinę būseną. Konsensusas yra mechanizmas, kuriuo sutariama dėl šios pasaulinės operacijų tvarkos.
• Didelis prieinamumas: Leisdama sistemai toliau veikti net ir nedideliam dalies mazgų gedimui, konsensusas užtikrina, kad paslaugos išliktų pasiekiamos ir veikiančios, minimalizuojant prastovas.
• Duomenų nuoseklumas: Jis garantuoja, kad visi duomenų dublikatai išliktų sinchronizuoti, užkertant kelią prieštaringiems naujiniams ir užtikrinant, kad klientai visada skaitytų naujausią ir teisingą informaciją.
• Atsparumas gedimams: Sistema gali toleruoti tam tikrą skaičių bet kokių mazgų gedimų (dažniausiai kritimo gedimų) ir toliau daryti pažangą be žmogaus įsikišimo.

Pristatome „Raft“: suprantamas konsensuso metodas

„Raft“ atsirado iš akademinio pasaulio su aiškiu tikslu: padaryti paskirstytąjį konsensusą prieinamą. Jo autoriai, Diego Ongaro ir John Ousterhout, aiškiai suprojektavo „Raft“ suprantamumui, siekdami leisti plačiau naudoti ir teisingai įgyvendinti konsensuso algoritmus.

„Raft“ pagrindinė dizaino filosofija: suprantamumas pirmiausia

„Raft“ suskaido sudėtingą konsensuso problemą į kelias gana nepriklausomas problemas, kurių kiekviena turi savo konkrečias taisykles ir elgsenas. Ši modulinė struktūra žymiai padeda suprasti. Pagrindiniai dizaino principai apima:

• Lyderiui centrinis metodas: Skirtingai nuo kai kurių kitų konsensuso algoritmų, kur visi mazgai lygiai dalyvauja priimant sprendimus, „Raft“ skiria vieną lyderį. Lyderis yra atsakingas už replikuoto žurnalo valdymą ir visų klientų užklausų koordinavimą. Tai supaprastina žurnalo valdymą ir sumažina mazgų sąveikos sudėtingumą.
• Stiprus lyderis: Lyderis yra galutinė institucija, siūlanti naujus žurnalo įrašus ir nustatanti, kada jie yra užfiksuoti. Sekėjai pasyviai replikuoja lyderio žurnalą ir reaguoja į lyderio užklausas.
• Deterministiniai rinkimai: „Raft“ naudoja atsitiktinį rinkimų laikmatį, siekdama užtikrinti, kad paprastai tik vienas kandidatas iškiltų kaip lyderis per tam tikrą rinkimų terminą.
• Žurnalo nuoseklumas: „Raft“ taiko stiprias nuoseklumo nuosavybes savo replikuojamam žurnalui, užtikrinant, kad užfiksuoti įrašai niekada nebūtų grąžinti atgal ir kad visi užfiksuoti įrašai galiausiai pasirodytų visuose pasiekiamuose mazguose.

Trumpas palyginimas su „Paxos“

Prieš „Raft“, „Paxos“ buvo faktinis paskirstytojo konsensuso standartas. Nors ir galingas, „Paxos“ yra sunkiai suprantamas ir teisingai įgyvendinamas. Jo dizainas, kuris atskiria vaidmenis (siūlytojas, priimantis, besimokantis) ir leidžia tuo pačiu metu egzistuoti keliems lyderiams (nors tik vienas gali užfiksuoti vertę), gali lemti sudėtingas sąveikas ir kraštinius atvejus.

„Raft“, priešingai, supaprastina būsenos erdvę. Jis taiko stiprų lyderio modelį, kuriame lyderis yra atsakingas už visus žurnalo pakeitimus. Jis aiškiai apibrėžia vaidmenis (Lyderis, Sekėjas, Kandidatas) ir perėjimus tarp jų. Ši struktūra daro „Raft“ elgseną intuityvesnę ir lengviau suprantamą, mažiau diegimo klaidų ir greitesnius plėtros ciklus. Daugelis realaus pasaulio sistemų, kurios iš pradžių susidūrė su „Paxos“, sėkmingai pritaikė „Raft“.

Trys pagrindiniai „Raft“ vaidmenys

Bet kuriuo metu kiekvienas „Raft“ klasterio serveris yra vienoje iš trijų būsenų: Lyderis, Sekėjas arba Kandidatas. Šie vaidmenys yra išskirtiniai ir dinamiški, serveriai pereina tarp jų remdamiesi konkrečiomis taisyklėmis ir įvykiais.

1. Sekėjas

• Pasyvus vaidmuo: Sekėjai yra pasyviausia būsena „Raft“. Jie tiesiog reaguoja į lyderių ir kandidatų užklausas.
• Širdies plakimų priėmimas: Sekėjas tikisi reguliariai gauti širdies plakimus (tuščius „AppendEntries“ RPC) iš lyderio. Jei sekėjas negauna širdies plakimo ar „AppendEntries“ RPC per tam tikrą rinkimų laikmatį, jis daro prielaidą, kad lyderis sugedo, ir pereina į kandidato būseną.
• Balsavimas: Rinkimų metu sekėjas balsuos ne daugiau kaip už vieną kandidatą per terminą.
• Žurnalo replikavimas: Sekėjai prideda žurnalo įrašus prie savo vietinio žurnalo, kaip nurodė lyderis.

2. Kandidatas

• Rinkimų inicijavimas: Kai sekėjas laiku nesureaguoja (negirdi iš lyderio), jis pereina į kandidato būseną, kad inicijuotų naujus rinkimus.
• Savęs balsavimas: Kandidatas padidina savo dabartinį terminą, balsuoja už save ir siunčia RequestVote RPC visiems kitiems klasterio serveriams.
• Rinkimų laimėjimas: Jei kandidatas gauna balsus iš daugumos klasterio serverių tame pačiame termine, jis pereina į lyderio būseną.
• Pasitraukimas: Jei kandidatas aptinka kitą serverį su aukštesniu terminu, arba jei jis gauna „AppendEntries“ RPC iš teisėto lyderio, jis grįžta į sekėjo būseną.

3. Lyderis

• Vienintelė institucija: Bet kuriuo metu „Raft“ klasteryje (tam tikram terminui) yra tik vienas lyderis. Lyderis yra atsakingas už visą klientų sąveiką, žurnalo replikavimą ir nuoseklumo užtikrinimą.
• Širdies plakimų siuntimas: Lyderis periodiškai siunčia AppendEntries RPC (širdies plakimus) visiems sekėjams, kad išlaikytų savo autoritetą ir užkirstų kelią naujiems rinkimams.
• Žurnalo valdymas: Lyderis priima klientų užklausas, prideda naujus žurnalo įrašus prie savo vietinio žurnalo, o tada replikuoja šiuos įrašus visiems sekėjams.
• Užfiksavimas: Lyderis nusprendžia, kada įrašas yra saugiai replikuotas daugumai serverių ir gali būti užfiksuotas būsenos mašinoje.
• Pasitraukimas: Jei lyderis aptinka serverį su aukštesniu termo, jis nedelsdamas pasitraukia ir grįžta į sekėjo būseną. Tai užtikrina, kad sistema visada daro pažangą su aukščiausiu žinomu termu.

„Raft“ veiklos fazės: nuodugnus apžvalga

„Raft“ veikia per nuolatinį lyderio rinkimų ir žurnalo replikavimo ciklą. Šie du pagrindiniai mechanizmai, kartu su svarbiomis saugos savybėmis, užtikrina klasterio nuoseklumą ir atsparumą gedimams.

1. Lyderio rinkimai

Lyderio rinkimo procesas yra „Raft“ veikimo pagrindas, užtikrinantis, kad klasteris visada turėtų vieną autoritetingą mazgą veiksmų koordinavimui.

• Rinkimų laikmatis: Kiekvienas sekėjas palaiko atsitiktinį rinkimų laikmatį (paprastai 150–300 ms). Jei sekėjas negauna jokio ryšio (širdies plakimo ar „AppendEntries“ RPC) iš dabartinio lyderio per šį laikmačio laikotarpį, jis daro prielaidą, kad lyderis sugedo arba įvyko tinklo skaidymas.
• Perėjimas į Kandidatą: Pasibaigus laikmačiui, sekėjas pereina į Kandidatas būseną. Jis padidina savo dabartinį terminą, balsuoja už save ir nustato savo rinkimų laikmatį iš naujo.
• RequestVote RPC: Kandidatas tuomet siunčia RequestVote RPC visiems kitiems klasterio serveriams. Šis RPC apima kandidato dabartinį terminą, jo kandidato ID, ir informaciją apie jo paskutinį žurnalo indeksą ir paskutinį žurnalo terminą (apie tai vėliau, kodėl tai svarbu saugumui).
• Balsavimo taisyklės: Serveris suteiks savo balsą kandidatui, jei:
  1. Jo dabartinis terminas yra mažesnis arba lygus kandidato terminui.
  2. Jis dar nebalsojo už kitą kandidatą tame pačiame termine.
  3. Kandidato žurnalas yra bent jau toks pat atnaujintas kaip jo. Tai nustatoma lyginant paskutinį žurnalo terminą pirmiausia, tada paskutinį žurnalo indeksą, jei terminai sutampa. Kandidatas yra „atnaujintas“, jei jo žurnalas yra visi užfiksuoti įrašai, kuriuos turi kandidato žurnalas. Tai žinoma kaip rinkimų apribojimas ir yra kritinė saugumui.
• Rinkimų laimėjimas: Kandidatas tampa nauju lyderiu, jei jis gauna balsus iš daugumos klasterio serverių tame pačiame termine. Gavęs rinkimus, naujasis lyderis nedelsdamas siunčia AppendEntries RPC (širdies plakimus) visiems kitiems serveriams, kad patvirtintų savo autoritetą ir užkirstų kelią naujiems rinkimams.
• Balsų perskirstymas ir pakartojimai: Gali būti, kad keli kandidatai atsiras tuo pačiu metu, todėl bus perskirstyti balsai, kai joks kandidatas negaus daugumos. Kad tai išspręstų, kiekvienas kandidatas turi atsitiktinį rinkimų laikmatį. Jei kandidato laikmatis pasibaigia, nelaimėjus rinkimų ar negavus informacijos iš naujo lyderio, jis padidina terminą ir pradeda naujus rinkimus. Atsitiktinumas padeda užtikrinti, kad balsų perskirstymas būtų retas ir greitai išsprendžiamas.
• Aukštesnių terminų aptikimas: Jei kandidatas (arba bet kuris serveris) gauna RPC su termo, didesniu nei jo dabartinis terminas, jis nedelsdamas atnaujina savo dabartinį terminą iki aukštesnės vertės ir grįžta į sekėjo būseną. Tai užtikrina, kad serveris su pasenusia informacija niekada nebandys tapti lyderiu ar sutrikdyti teisėto lyderio.

2. Žurnalo replikavimas

Kai lyderis yra išrinktas, jo pagrindinė atsakomybė yra valdyti replikuotą žurnalą ir užtikrinti nuoseklumą visame klasteryje. Tai apima klientų komandų priėmimą, jų pridėjimą prie savo žurnalo ir jų replikavimą sekėjams.

• Klientų užklausos: Visos klientų užklausos (komandos, kurias turi vykdyti būsenos mašina) nukreipiamos į lyderį. Jei klientas susisiekia su sekėju, sekėjas nukreipia užklausą į dabartinį lyderį.
• Pridėjimas prie lyderio žurnalo: Kai lyderis gauna klientų komandą, jis prideda komandą kaip naują žurnalo įrašą prie savo vietinio žurnalo. Kiekvienas žurnalo įrašas yra pats komandos, termo, kuriame ji buvo gauta, ir jos žurnalo indekso.
• AppendEntries RPC: Lyderis tada siunčia AppendEntries RPC visiems sekėjams, prašydamas jų pridėti naują žurnalo įrašą (arba įrašų paketą) prie savo žurnalų. Šie RPC apima:
  • term: Lyderio dabartinis terminas.
  • leaderId: Lyderio ID (sekėjams, kad nukreiptų klientus).
  • prevLogIndex: Žurnalo įrašo indeksas, kuris iš karto yra prieš naujus įrašus.
  • prevLogTerm: prevLogIndex įrašo terminas. Šie du (prevLogIndex, prevLogTerm) yra kritiniai žurnalo atitikimo savybei.
  • entries[]: Saugojami žurnalo įrašai (tušti širdies plakimams).
  • leaderCommit: Lyderio commitIndex (aukščiausio žurnalo įrašo, žinomo kaip užfiksuotas, indeksas).
• Nuoseklumo patikrinimas (žurnalo atitikimo ypatybė): Kai sekėjas gauna AppendEntries RPC, jis atlieka nuoseklumo patikrinimą. Jis patikrina, ar jo žurnale yra įrašas prevLogIndex su terminu, atitinkančiu prevLogTerm. Jei šis patikrinimas nepavyksta, sekėjas atmeta AppendEntries RPC, informuodamas lyderį, kad jo žurnalas yra nuoseklus.
• Nuoseklumų sprendimas: Jei sekėjas atmeta AppendEntries RPC, lyderis sumažina nextIndex šiam sekėjui ir pakartoja AppendEntries RPC. nextIndex yra kito žurnalo įrašo indeksas, kurį lyderis atsiųs konkrečiam sekėjui. Šis procesas tęsiamas, kol nextIndex pasiekia tašką, kuriame lyderio ir sekėjo žurnalai atitinka. Kai atitikimas randamas, sekėjas gali priimti vėlesnius žurnalo įrašus, galiausiai suderindamas savo žurnalą su lyderio.
• Įrašų fiksavimas: Įrašas laikomas užfiksuotu, kai lyderis jį sėkmingai replikavo daugumai serverių (įskaitant save). Kai įrašas yra užfiksuotas, jis gali būti taikomas vietinei būsenos mašinai. Lyderis atnaujina savo commitIndex ir įtraukia tai į vėlesnius AppendEntries RPC, kad informuotų sekėjus apie užfiksuotus įrašus. Sekėjai atnaujina savo commitIndex remdamiesi lyderio leaderCommit ir taiko įrašus iki to indekso savo būsenos mašinai.
• Lyderio užbaigtumo ypatybė: „Raft“ garantuoja, kad jei žurnalo įrašas yra užfiksuotas tam tikru terminu, tada visi vėlesni lyderiai taip pat turės tą žurnalo įrašą. Ši ypatybė yra įgyvendinama per rinkimų apribojimą: kandidatas gali laimėti rinkimus tik tuo atveju, jei jo žurnalas yra bent jau toks pat atnaujintas kaip dauguma kitų serverių. Tai apsaugo nuo lyderio, kuris galėtų perrašyti ar praleisti užfiksuotus įrašus, išrinkimo.

3. Saugaus elgesio ypatybės ir garantijos

„Raft“ tvirtumas kyla iš kelių kruopščiai suprojektuotų saugos ypatybių, kurios apsaugo nuo nuoseklumo nesuderinamumo ir užtikrina duomenų vientisumą:

• Rinkimų sauga: Bet kuriuo terminu gali būti išrinktas ne daugiau kaip vienas lyderis. Tai užtikrinama balsavimo mechanizmu, kai sekėjas suteikia ne daugiau kaip vieną balsą per terminą, o kandidatui reikia daugumos balsų.
• Lyderio užbaigtumas: Jei žurnalo įrašas buvo užfiksuotas tam tikru terminu, tada tas įrašas bus visų vėlesnių lyderių žurnaluose. Tai svarbu siekiant užkirsti kelią užfiksuotų duomenų praradimui ir yra pirmiausia užtikrinama rinkimų apribojimu.
• Žurnalo atitikimo ypatybė: Jei du žurnalai turi įrašą su tuo pačiu indeksu ir terminu, tada žurnalai yra identiški visuose ankstesniuose įrašuose. Tai supaprastina žurnalo nuoseklumo patikrinimus ir leidžia lyderiui efektyviai suderinti sekėjų žurnalus.
• Fiksavimo sauga: Kai įrašas yra užfiksuotas, jis niekada nebus grąžintas ar perrašytas. Tai tiesioginė Lyderio užbaigtumo ir Žurnalo atitikimo ypatybių pasekmė. Kai įrašas yra užfiksuotas, jis laikomas nuolat saugomu.

Pagrindinės „Raft“ sąvokos ir mechanizmai

Be vaidmenų ir veiklos fazių, „Raft“ remiasi keletu pagrindinių sąvokų būsenai valdyti ir tinkamumui užtikrinti.

1. Terminai

Terminas „Raft“ yra nuolat didėjantis sveikasis skaičius. Jis veikia kaip loginis klasterio laikrodis. Kiekvienas terminas prasideda rinkimais, o jei rinkimai sėkmingi, tam terminui išrenkamas vienas lyderis. Terminai yra kritiniai siekiant nustatyti pasenusią informaciją ir užtikrinti, kad serveriai visada remtųsi naujausia informacija:

• Serveriai keičiasi savo dabartiniu terminu visuose RPC.
• Jei serveris aptinka kitą serverį su aukštesniu termo, jis atnaujina savo dabartinį terminą ir grįžta į sekėjo būseną.
• Jei kandidatas ar lyderis aptinka, kad jo term yra pasenęs (žemesnis nei kito serverio term), jis nedelsdamas pasitraukia.

2. Žurnalo įrašai

Žurnalas yra centrinis „Raft“ komponentas. Tai yra užsakytas įrašų seka, kurioje kiekvienas žurnalo įrašas atstovauja komandą, kuri turi būti vykdoma būsenos mašinoje. Kiekvienas įrašas yra:

• Komanda: Tikrasis atliekamas veiksmas (pvz., „nustatyti x=5“, „sukurti vartotoją“).
• Terminas: Terminas, kuriame įrašas buvo sukurtas lyderiu.
• Indeksas: Įrašo pozicija žurnale. Žurnalo įrašai yra griežtai užsakomi pagal indeksą.

Žurnalas yra nuolatinis, o tai reiškia, kad įrašai yra įrašomi į nuolatinę saugyklą prieš atsakant klientams, apsaugant nuo duomenų praradimo per sutrikimus.

3. Būsenos mašina

Kiekvienas „Raft“ klasterio serveris palaiko būsenos mašiną. Tai programai specifinis komponentas, kuris apdoroja užfiksuotus žurnalo įrašus. Siekiant užtikrinti nuoseklumą, būsenos mašina turi būti deterministinė (atsižvelgiant į tą pačią pradinę būseną ir komandų seką, ji visada duoda tą patį rezultatą ir galutinę būseną) ir idempotentinė (ta pačia komanda, taikoma kelis kartus, sukelia tą patį poveikį kaip ir taikant vieną kartą, o tai padeda švelniai tvarkyti pakartojimus, nors „Raft“ žurnalo fiksavimas iš esmės garantuoja vienkartinį taikymą).

4. Fiksavimo indeksas

Fiksavimo indeksas yra aukščiausias žurnalo įrašo indeksas, apie kurį žinoma, kad jis yra užfiksuotas. Tai reiškia, kad jis buvo saugiai replikuotas daugumai serverių ir gali būti taikomas būsenos mašinoje. Lyderiai nustato fiksavimo indeksą, o sekėjai atnaujina savo fiksavimo indeksą remdamiesi lyderio AppendEntries RPC. Visi įrašai iki fiksavimo indekso laikomi nuolatiniais ir negali būti grąžinti.

5. Momentinės nuotraukos

Laikui bėgant, replikuotas žurnalas gali tapti labai didelis, užimti daug disko vietos ir sulėtinti žurnalo replikavimą bei atkūrimą. „Raft“ tai sprendžia naudodamas momentines nuotraukas. Momentinė nuotrauka yra kompaktiškas būsenos mašinos būsenos atvaizdavimas tam tikru laiku. Vietoj to, kad laikytų visą žurnalą, serveriai gali periodiškai „užfiksuoti“ savo būseną, atmesti visus žurnalo įrašus iki momentinės nuotraukos taško ir tada replikuoti momentinę nuotrauką naujiems arba vėluojantiems sekėjams. Šis procesas žymiai pagerina efektyvumą:

• Žurnalo suspaudimas: Sumažina nuolatinio žurnalo duomenų kiekį.
• Greitesnis atkūrimas: Nauji arba sugedę serveriai gali gauti momentinę nuotrauką, o ne iš naujo paleisti visą žurnalą nuo pradžių.
• InstallSnapshot RPC: „Raft“ apibrėžia InstallSnapshot RPC, skirtą momentinėms nuotraukoms perduoti iš lyderio į sekėjus.

Nors ir veiksmingas, momentinių nuotraukų kūrimas padidina diegimo sudėtingumą, ypač valdant lygiagretų momentinių nuotraukų kūrimą, žurnalo apkarpytį ir perdavimą.

„Raft“ diegimas: praktiniai aspektai pasauliniams diegimams

„Raft“ elegantiško dizaino perkėlimas į tvirtą, gamybai paruoštą sistemą, ypač pasaulinėms auditorijoms ir įvairioms infrastruktūroms, apima keletą praktinių inžinerinių iššūkių sprendimą.

1. Tinklo vėlavimas ir skaidymai pasauliniu mastu

Pasauliniu mastu paskirstytose sistemose tinklo vėlavimas yra svarbus veiksnys. „Raft“ klasteris paprastai reikalauja, kad dauguma mazgų sutartų dėl žurnalo įrašo prieš jį užfiksuojant. Klasteryje, pasklidusiame per žemynus, mazgų vėlavimas gali būti šimtai milisekundžių. Tai tiesiogiai veikia:

• Užfiksavimo vėlavimas: Laikas, kurio reikia kliento užklausos užfiksavimui, gali būti apribotas lėčiausios tinklo jungties iki daugumos dublikatų. Strategijos, tokios kaip tik skaitymo sekėjai (kuriems nereikia lyderio sąveikos, kad gautų pasenusius skaitymus) arba geografinė kvorumo konfigūracija (pvz., 3 mazgai viename regione, 2 kitame 5 mazgų klasteryje, kur dauguma gali būti greitame regione), gali tai sumažinti.
• Lyderio rinkimų greitis: Didelis vėlavimas gali atidėti RequestVote RPC, galimai sukeldamas dažnesnius balsų perskirstymus arba ilgesnius rinkimų laikus. Būtina pritaikyti rinkimų laikmačius, kad jie būtų žymiai didesni nei įprastas mazgų tarpusavio vėlavimas.
• Tinklo skaidymų tvarkymas: Realaus pasaulio tinklai yra linkę į skaidymus. „Raft“ tinkamai tvarko skaidymus, užtikrinant, kad tik daugumą serverių turintis skaidymas galėtų išsirinkti lyderį ir judėti pirmyn. Mažumos skaidymas negalės užfiksuoti naujų įrašų, taigi užkertant kelią „suskaidyto smegenų“ scenarijams. Tačiau ilgalaikiai skaidymai pasaulinio masto diegime gali lemti tam tikrų regionų neprieinamumą, todėl reikia kruopščių architektūrinių sprendimų dėl kvorumo vietos.

2. Nuolatinė saugykla ir patvarumas

„Raft“ tinkamumas labai priklauso nuo jo žurnalo ir būsenos patvarumo. Prieš serveriui atsakant į RPC ar taikant įrašą savo būsenos mašinoje, jis turi užtikrinti, kad atitinkami duomenys (žurnalo įrašai, dabartinis terminas, balsavo už) būtų įrašyti į nuolatinę saugyklą ir sinchronizuoti (išversti į diską). Tai apsaugo nuo duomenų praradimo atsitikus sutrikimui. Apsvarstymai apima:

• Našumas: Dažni disko įrašai gali būti našumo kliūtis. Dažni įrašai ir didelio našumo SSD naudojimas yra įprasti optimizavimai.
• Patikimumas: Būtina pasirinkti patikimą ir patvarų saugyklos sprendimą (vietinis diskas, tinklo prijungta saugykla, debesų blokų saugykla).
• WAL (Write-Ahead Log): Dažnai „Raft“ diegimai naudoja priešrašymų žurnalą patvarumui, panašiai kaip duomenų bazės, kad užtikrintų, jog pakeitimai būtų įrašyti į diską prieš juos taikant atmintyje.

3. Klientų sąveika ir nuoseklumo modeliai

Klientai sąveikauja su „Raft“ klasteriu siųsdami užklausas lyderiui. Klientų užklausų tvarkymas apima:

• Lyderio aptikimas: Klientams reikia mechanizmo rasti dabartinį lyderį. Tai gali būti per paslaugų aptikimo mechanizmą, fiksuotą galinį tašką, kuris peradresuoja, arba bandant serverius, kol vienas atsakys kaip lyderis.
• Užklausos pakartojimai: Klientai turi būti pasirengę pakartoti užklausas, jei lyderis pasikeičia arba jei įvyksta tinklo klaida.
• Skaitymo nuoseklumas: „Raft“ pirmiausia garantuoja stiprų nuoseklumą įrašams. Skaitymams yra įmanoma keletas modelių:
  • Stipriai nuoseklus skaitymas: Klientas gali paprašyti lyderio užtikrinti, kad jo būsena yra atnaujinta, siųsdamas širdies plakimą daugumai savo sekėjų prieš aptarnaudamas skaitymą. Tai garantuoja šviežumą, bet padidina vėlavimą.
  • Lyderio nuomos skaitymai: Lyderis gali įgyti „nuomą“ iš daugumos mazgų trumpą laiką, per kurį jis žino, kad vis dar yra lyderis ir gali aptarnauti skaitymus be tolesnio konsensuso. Tai greičiau, bet laiko ribota.
  • Pasenę skaitymai (iš sekėjų): Skaitymas tiesiogiai iš sekėjų gali pasiūlyti mažesnį vėlavimą, tačiau rizikuojama skaityti pasenusius duomenis, jei sekėjo žurnalas atsilieka nuo lyderio. Tai priimtina programoms, kur galutinis nuoseklumas yra pakankamas skaitymams.

4. Konfigūracijos pakeitimai (klasterio narystė)

Keisti „Raft“ klasterio narystę (pridedant ar pašalinant serverius) yra sudėtinga operacija, kuri taip pat turi būti atliekama per konsensusą, kad būtų išvengta nuoseklumo nesuderinamumo ar „suskaidyto smegenų“ scenarijų. „Raft“ siūlo techniką, vadinamą bendru konsensusu:

• Dvi konfigūracijos: Konfigūracijos pakeitimo metu sistema laikinai veikia su dviem persidengiančiomis konfigūracijomis: senąja konfigūracija (C_old) ir naująja konfigūracija (C_new).
• Bendro konsensuso būsena (C_old, C_new): Lyderis siūlo specialų žurnalo įrašą, kuris atstovauja bendrą konfigūraciją. Kai šis įrašas yra užfiksuotas (reikalaujantis sutikimo iš C_old ir C_new abiejų daugumų), sistema yra pereinamoje būsenoje. Dabar sprendimams reikalingos abiejų konfigūracijų daugumos. Tai užtikrina, kad pereinamuoju laikotarpiu nei senoji, nei naujoji konfigūracija negali priimti sprendimų vienašališkai, užkertant kelią neatitikimams.
• Perėjimas prie C_new: Kai bendros konfigūracijos žurnalo įrašas yra užfiksuotas, lyderis siūlo kitą žurnalo įrašą, atstovaujantį tik naują konfigūraciją (C_new). Kai šis antrasis įrašas yra užfiksuotas, senoji konfigūracija atmetama, ir sistema veikia tik pagal C_new.
• Saugumas: Šis dviejų fazių patvirtinimo tipo procesas užtikrina, kad bet kuriuo metu negali būti išrinkti du prieštaringi lyderiai (vienas pagal C_old, kitas pagal C_new) ir kad sistema išlieka veikianti visos permainos metu.

Tinkamai įgyvendinti konfigūracijos pakeitimus yra viena iš sudėtingiausių „Raft“ algoritmo dalių dėl daugybės kraštinių atvejų ir gedimų scenarijų pereinamosios būsenos metu.

5. Paskirstytųjų sistemų testavimas: griežtas metodas

„Raft“ tipo paskirstytojo konsensuso algoritmas yra itin sudėtingas dėl jo nenatūralios elgsenos ir daugybės gedimų režimų. Paprasti vieneto testai nepakanka. Griežtas testavimas apima:

• Gedimų įterpimas: Sisteminio gedimų, tokių kaip mazgų sutrikimai, tinklo skaidymai, pranešimų vėlavimai ir pranešimų perskirstymas, sistemingas įvedimas. Įrankiai, tokie kaip Jepsen, yra specialiai sukurti šiam tikslui.
• Ypatybių pagrindu testavimas: Apibrėžiant invariantus ir saugos ypatybes (pvz., ne daugiau kaip vienas lyderis per terminą, užfiksuoti įrašai niekada neprarandami) ir testuojant, kad implementacija juos palaiko įvairiomis sąlygomis.
• Modelio tikrinimas: Kritinėms algoritmo dalims gali būti naudojamos formalios patvirtinimo technikos, siekiant įrodyti tinkamumą, tačiau tai yra labai specializuota.
• Simuliuojamos aplinkos: Bandymų vykdymas aplinkose, kurios imituoja tinklo sąlygas (vėlavimas, paketų praradimas), būdingas pasauliniams diegimams.

Naudojimo atvejai ir realaus pasaulio taikymai

„Raft“ praktiškumas ir suprantamumas lėmė jo plačiai paplitusį įsisavinimą įvairiose kritinėse infrastruktūros komponentuose:

1. Paskirstytosios raktų-vertybių saugyklos ir duomenų bazių replikavimas

• etcd: „Kubernetes“ pagrindinis komponentas, „etcd“ naudoja „Raft“ konfigūracijos duomenims, paslaugų aptikimo informacijai laikyti ir replikuoti bei klasterio būsenai valdyti. Jo patikimumas yra svarbiausias, kad „Kubernetes“ veiktų tinkamai.
• Consul: „HashiCorp“ sukurtas „Consul“ naudoja „Raft“ savo paskirstytam saugyklos pagrindui, leidžiančiam paslaugų aptikimą, būklės tikrinimą ir konfigūracijos valdymą dinamiškose infrastruktūros aplinkose.
• TiKV: Paskirstytasis transakcijinis raktas-vertybė saugykla, naudojama „TiDB“ (paskirstyta SQL duomenų bazė), įgyvendina „Raft“ savo duomenų replikavimui ir nuoseklumo garantijoms.
• CockroachDB: Ši pasaulinio masto paskirstyta SQL duomenų bazė plačiai naudoja „Raft“ duomenų replikavimui tarp daugelio mazgų ir geografinių regionų, užtikrinant aukštą prieinamumą ir stiprų nuoseklumą net ir regiono masto gedimų atveju.

2. Paslaugų aptikimas ir konfigūracijos valdymas

„Raft“ suteikia idealų pagrindą sistemoms, kurioms reikia laikyti ir platinti kritinę metaduomenų informaciją apie paslaugas ir konfigūracijas visame klasteryje. Kai paslauga registruojasi arba jos konfigūracija pasikeičia, „Raft“ užtikrina, kad visi mazgai galiausiai sutartų dėl naujos būsenos, leidžiant dinamiškus atnaujinimus be rankinio įsikišimo.

3. Paskirstytųjų sandorių koordinatoriai

Sistemoms, kurioms reikalingas atomumas tarp kelių operacijų ar paslaugų, „Raft“ gali palaikyti paskirstytuosius sandorių koordinatorius, užtikrinant, kad sandorių žurnalai būtų nuosekliai replikuojami prieš užfiksuojant pakeitimus tarp dalyvių.

4. Klasterio koordinavimas ir lyderio rinkimai kitose sistemose

Be aiškaus duomenų bazių ar raktų-vertybių saugyklų naudojimo, „Raft“ dažnai įterpiamas kaip biblioteka ar pagrindinis komponentas koordinavimo užduotims valdyti, lyderiams rinkti kitiems paskirstytiesiems procesams arba teikti patikimą valdymo plokštę didesnėse sistemose. Pavyzdžiui, daugelis debesų-nacionalinių sprendimų naudoja „Raft“ savo valdymo plokštės komponentų būsenai valdyti.

„Raft“ privalumai ir trūkumai

Nors „Raft“ siūlo reikšmingų privalumų, svarbu suprasti jo kompromisus.

Privalumai:

• Suprantamumas: Jo pagrindinis dizaino tikslas, leidžiantis lengviau įgyvendinti, derinti ir suprasti nei senesnius konsensuso algoritmus, tokius kaip „Paxos“.
• Stiprus nuoseklumas: Suteikia stiprias nuoseklumo garantijas užfiksuotiems žurnalo įrašams, užtikrinant duomenų vientisumą ir patikimumą.
• Atsparumas gedimams: Gali toleruoti mažumos mazgų gedimą (iki (N-1)/2 gedimų N mazgų klasteryje) neprarandant prieinamumo ar nuoseklumo.
• Našumas: Stabiliais sąlygomis (jokių lyderio pasikeitimų) „Raft“ gali pasiekti didelį našumą, nes lyderis seka visas užklausas nuosekliai ir replikuoja lygiagrečiai, efektyviai išnaudodamas tinklo pralaidumą.
• Aiškvūs vaidmenys: Aiškūs vaidmenys (Lyderis, Sekėjas, Kandidatas) ir būsenos perėjimai supaprastina mentalinį modelį ir įgyvendinimą.
• Konfigūracijos pakeitimai: Suteikia patikimą mechanizmą (Bendras Konsensusas) saugiai pridedant ar pašalinant mazgus iš klasterio, nepakenkiant nuoseklumui.

Trūkumai:

• Lyderio kliūtis: Visos klientų įrašų užklausos turi praeiti per lyderį. Scenarijuose su itin dideliu įrašų našumu arba kai lyderiai yra geografiškai nutolę nuo klientų, tai gali tapti našumo kliūtimi.
• Skaitymo vėlavimas: Stipriai nuoseklių skaitymų siekimas dažnai reikalauja bendravimo su lyderiu, potencialiai padidinant vėlavimą. Skaitymas iš sekėjų rizikuoja pasenusiais duomenimis.
• Kvorumo reikalavimas: Reikia daugumos mazgų, kad būtų galima užfiksuoti naujus įrašus. 5 mazgų klasteryje galima toleruoti 2 gedimus. Jei 3 mazgai suges, klasteris taps neprieinamas įrašams. Tai gali būti sudėtinga itin skaidomuose ar geografiniu mastu pasklidusiose aplinkose, kur sunku išlaikyti daugumą regionuose.
• Tinklo jautrumas: Labai jautrus tinklo vėlavimui ir skaidymams, kurie gali paveikti rinkimų laikus ir bendrą sistemos našumą, ypač plačiai pasklidusiuose diegimuose.
• Konfigūracijos pakeitimų sudėtingumas: Nors ir tvirtas, Bendro Konsensuso mechanizmas yra viena sudėtingiausių „Raft“ algoritmo dalių, kurią reikia tinkamai įgyvendinti ir kruopščiai išbandyti.
• Vieno taško gedimas (įrašams): Nors ir atsparus lyderio gedimams, jei lyderis yra visam laikui neveikiantis ir negali būti išrinktas naujas lyderis (pvz., dėl tinklo skaidymų ar per daug gedimų), sistema negali daryti pažangos įrašams.

Išvada: valdoma paskirstytoji konsensuso sistema pasaulinėms sistemoms

„Raft“ algoritmas yra pavyzdys, kaip apgalvotas dizainas gali supaprastinti sudėtingas problemas. Jo dėmesys suprantamumui demokratizavo paskirstytąjį konsensusą, leidžiant platesniam programuotojų ir organizacijų ratui kurti aukšto prieinamumo ir atsparias gedimams sistemas nepasiduodant ankstesnių metodų paslaptingoms sudėtingumams.

Nuo konteinerių klasterių orkestravimo su „Kubernetes“ (per „etcd“) iki patikimų duomenų saugyklų pasaulinėms duomenų bazėms, tokioms kaip „CockroachDB“, „Raft“ yra tylus darbininkas, užtikrinantis, kad mūsų skaitmeninis pasaulis išliktų nuoseklus ir veikiantis.

Veiksmų įžvalgos programuotojams ir architektams:

• Prioritetas supratimui: Prieš bandydami įgyvendinti, skirkite laiko kruopščiai suprasti kiekvieną „Raft“ taisyklę ir būsenos perėjimą. Originalus straipsnis ir vizualūs paaiškinimai yra neįkainojami ištekliai.
• Naudokite esamas bibliotekas: Daugumai programų apsvarstykite galimybę naudoti gerai patikrintas esamas „Raft“ implementacijas (pvz., iš „etcd“, „HashiCorp“ „Raft“ bibliotekos), o ne kurti nuo nulio, nebent jūsų poreikiai yra labai specifiški arba jūs atliekate akademinius tyrimus.
• Griežtas testavimas yra nebepraeinamas: Gedimų įterpimas, savybių pagrindu testavimas ir platus gedimų scenarijų modeliavimas yra būtini bet kuriai paskirstytojo konsensuso sistemai. Niekada nemanykite, kad „tai veikia“ be kruopštaus bandymo tai sugadinti.
• Projektavimas atsižvelgiant į pasaulinį vėlavimą: Diegiant pasauliniu mastu, atidžiai apsvarstykite savo kvorumo vietą, tinklo topologiją ir kliento skaitymo strategijas, kad optimizuotumėte tiek nuoseklumą, tiek našumą skirtinguose geografiniuose regionuose.
• Patvarumas ir ilgaamžiškumas: Užtikrinkite, kad jūsų pagrindinis saugyklos sluoksnis būtų tvirtas ir kad fsync arba atitinkamos operacijos būtų tinkamai naudojamos, kad būtų išvengta duomenų praradimo sutrikimo atveju.

Toliau plėtojantis paskirstytosioms sistemoms, „Raft“ įkūnyti principai – aiškumas, tvirtumas ir atsparumas gedimams – išliks patikimos programinės įrangos inžinerijos pagrindais. Įsisavindami „Raft“, jūs suteikiate sau galingą įrankį kurti atsparias, pasauliniu mastu masteliuojamas programas, kurios gali atlaikyti neišvengiamą paskirstytojo kompiuterio chaosą.