Iepazīstieties ar izplatīto vienprātību: Raft algoritma implementācijas padziļināta analīze globālām sistēmām

Mūsu arvien vairāk savstarpēji savienotajā pasaulē izplatītās sistēmas ir gandrīz katra digitālā pakalpojuma, sākot no e-komercijas platformām un finanšu iestādēm līdz mākoņdatošanas infrastruktūrai un reāllaika sakaru rīkiem, mugurkauls. Šīs sistēmas piedāvā nepārspējamu mērogojamību, pieejamību un noturību, sadalot darba slodzes un datus vairākās mašīnās. Tomēr šī jauda rada ievērojamu izaicinājumu: nodrošināt, ka visas sastāvdaļas vienojas par sistēmas stāvokli, pat ņemot vērā tīkla aizkavēšanos, mezglu kļūmes un vienlaicīgas darbības. Šī fundamentālā problēme ir pazīstama kā izplatītā vienprātība.

Vienprātības panākšana asinhronā, kļūmēm pakļautā izplatītā vidē ir bēdīgi sarežģīta. Gadu desmitiem Paxos bija dominējošais algoritms šī izaicinājuma risināšanai, ko cienīja par teorētisko pareizību, bet bieži kritizēja par sarežģītību un grūtībām ieviest. Tad parādījās Raft, algoritms, kas izstrādāts ar galveno mērķi: saprotamību. Raft mērķis ir būt ekvivalentam Paxos kļūdu tolerances un veiktspējas ziņā, taču strukturēts tā, lai izstrādātājiem būtu daudz vieglāk saprast un veidot uz tā pamata.

Šī visaptverošā rokasgrāmata dziļi iedziļinās Raft algoritmā, izpētot tā pamatprincipus, darbības mehānismus, praktiskos ieviešanas apsvērumus un tā vitāli svarīgo lomu spēcīgu, globāli izplatītu lietojumprogrammu veidošanā. Neatkarīgi no tā, vai esat pieredzējis arhitekts, izplatītu sistēmu inženieris vai izstrādātājs, kas vēlas veidot ļoti pieejamus pakalpojumus, Raft izpratne ir būtisks solis, lai apgūtu mūsdienu skaitļošanas sarežģītību.

Nepieciešamība pēc izplatītās vienprātības mūsdienu arhitektūrās

Iedomājieties globālu e-komercijas platformu, kas apstrādā miljoniem darījumu sekundē. Klientu dati, krājumu līmeņi, pasūtījumu statusi — visam jāpaliek konsekventam vairākos datu centros, kas aptver kontinentus. Banku sistēmas virsgrāmata, kas izplatīta vairākos serveros, nevar atļauties pat īsu neatbilstību konta atlikumā. Šīs situācijas uzsver izplatītās vienprātības kritisko nozīmi.

Izplatīto sistēmu raksturīgie izaicinājumi

Izplatītās sistēmas pēc savas būtības rada neskaitāmus izaicinājumus, kas nav monolītās lietojumprogrammās. Šo izaicinājumu izpratne ir būtiska, lai novērtētu tādu algoritmu kā Raft eleganci un nepieciešamību:

• Daļējas kļūmes: Atšķirībā no viena servera, kas vai nu darbojas, vai pilnībā sabrūk, izplatītā sistēma var piedzīvot dažādu mezglu kļūmes, kamēr citi turpina darboties. Serveris var sabrukt, tā tīkla savienojums var pazust, vai tā disks var tikt bojāts, kamēr pārējais klasteris paliek funkcionāls. Sistēmai ir jāturpina darboties pareizi, neskatoties uz šīm daļējām kļūmēm.
• Tīkla sadalījumi: Mezglus savienojošais tīkls ne vienmēr ir uzticams. Tīkla sadalījums rodas, kad tiek pārtraukta saziņa starp mezglu apakškopām, liekot šķist, ka noteikti mezgli ir sabrukuši, pat ja tie joprojām darbojas. Šo "dalīta smadzeņu" scenāriju risināšana, kur dažādas sistēmas daļas darbojas neatkarīgi, pamatojoties uz novecojušu vai nesaistītu informāciju, ir galvenā vienprātības problēma.
• Asinhronā saziņa: Ziņojumi starp mezgliem var aizkavēties, pārkārtoties vai vispār netikt piegādāti. Nav globāla pulksteņa vai garantijas par ziņojumu piegādes laikiem, padarot grūti izveidot konsekventu notikumu secību vai galīgo sistēmas stāvokli.
• Vienlaicīgums: Vairāki mezgli var vienlaicīgi mēģināt atjaunināt vienu un to pašu datu daļu vai uzsākt darbības. Bez mehānisma šo darbību koordinēšanai konflikti un nesakritības ir neizbēgamas.
• Neparedzama aizkavēšanās: Jo īpaši globālās izplatījumos tīkla aizkavēšanās var ievērojami atšķirties. Operācijas, kas ir ātras vienā reģionā, citā var būt lēnas, ietekmējot lēmumu pieņemšanas procesus un koordināciju.

Kāpēc vienprātība ir uzticamības stūrakmens

Vienprātības algoritmi nodrošina pamata celtniecības bloku šo izaicinājumu risināšanai. Tie ļauj kopumam neuzticamu komponentu kopīgi darboties kā vienai, ļoti uzticamai un saskaņotai vienībai. Konkrēti, vienprātība palīdz sasniegt:

• Stāvokļa mašīnas replikācija (SMR): Galvenā ideja aiz daudzām kļūmēm tolerējošām izplatītām sistēmām. Ja visi mezgli vienojas par operāciju secību, un ja katrs mezgls sāk ar tādu pašu sākotnējo stāvokli un izpilda šīs operācijas tādā pašā secībā, tad visi mezgli sasniegs to pašu galīgo stāvokli. Vienprātība ir mehānisms, lai vienotos par šo globālo operāciju secību.
• Augsta pieejamība: Ļaujot sistēmai turpināt darboties pat tad, ja mazākā daļa mezglu sabrūk, vienprātība nodrošina, ka pakalpojumi paliek pieejami un funkcionāli, samazinot dīkstāves laiku.
• Datu konsekvence: Tā garantē, ka visi datu attēlojumi paliek sinhronizēti, novēršot pretrunīgus atjauninājumus un nodrošinot, ka klienti vienmēr nolasa visaktuālāko un pareizo informāciju.
• Kļūdu tolerance: Sistēma var pieļaut noteiktu skaitu nejaušu mezglu kļūmju (parasti sadursmes kļūmju) un turpināt virzību uz priekšu bez cilvēka iejaukšanās.

Iepazīstinām ar Raft: Saprotama pieeja vienprātībai

Raft radās no akadēmiskās pasaules ar skaidru mērķi: padarīt izplatīto vienprātību pieejamu. Tā autori, Djēgo Ongaro un Džons Ousterhouts, nepārprotami izstrādāja Raft, lai tas būtu saprotams, mērķējot uz plašāku vienprātības algoritmu izmantošanu un pareizu ieviešanu.

Raft galvenā dizaina filozofija: vispirms saprotamība

Raft sadala sarežģīto vienprātības problēmu vairākās salīdzinoši neatkarīgās apakšproblēmās, katrai ar savu specifisko noteikumu un uzvedības kopumu. Šī modularitāte ievērojami palīdz izpratnei. Galvenie dizaina principi ietver:

• Uz līderi orientēta pieeja: Atšķirībā no dažiem citiem vienprātības algoritmiem, kur visi mezgli vienādi piedalās lēmumu pieņemšanā, Raft ieceļ vienu līderi. Līderis ir atbildīgs par replikētā žurnāla pārvaldīšanu un visu klientu pieprasījumu koordinēšanu. Tas vienkāršo žurnālu pārvaldīšanu un samazina mezglu mijiedarbības sarežģītību.
• Stiprs līderis: Līderis ir galvenā iestāde jaunu žurnāla ierakstu ierosināšanai un noteikšanai, kad tie ir apstiprināti. Sekotāji pasīvi replicē līdera žurnālu un atbild uz līdera pieprasījumiem.
• Deteministiskas vēlēšanas: Raft izmanto nejaušu vēlēšanu taimautu, lai nodrošinātu, ka noteiktā vēlēšanu termiņā parasti parādās tikai viens kandidāts.
• Žurnāla konsekvence: Raft nodrošina stingras konsekvences īpašības savam replikētajam žurnālam, nodrošinot, ka apstiprinātie ieraksti nekad netiek atgriezti un ka visi apstiprinātie ieraksti galu galā parādās visos pieejamos mezglos.

Īss salīdzinājums ar Paxos

Pirms Raft Paxos bija de facto standarts izplatītai vienprātībai. Lai gan jaudīgs, Paxos ir bēdīgi grūti saprotams un pareizi ieviests. Tā dizains, kas atdala lomas (priekšlikumu devējs, akceptētājs, lietotājs) un ļauj vienlaicīgi pastāvēt vairākiem līderiem (lai gan tikai viens var apstiprināt vērtību), var radīt sarežģītas mijiedarbības un malas gadījumus.

Raft, turpretī, vienkāršo stāvokļa telpu. Tas nodrošina stingru līdera modeli, kur līderis ir atbildīgs par visām žurnāla mutācijām. Tas skaidri definē lomas (Līderis, Sekotājs, Kandidāts) un pārejas starp tām. Šī struktūra padara Raft uzvedību intuitīvāku un vieglāk prognozējamu, radot mazāk ieviešanas kļūdu un ātrākus izstrādes ciklus. Daudzas reālās pasaules sistēmas, kas sākotnēji saskārās ar problēmām ar Paxos, ir guvušas panākumus, pieņemot Raft.

Trīs pamata lomas Raft

Jebkurā laikā katrs Raft klastera serveris atrodas vienā no trim stāvokļiem: Līderis, Sekotājs vai Kandidāts. Šīs lomas ir izslēdzošas un dinamiskas, serveriem pārejot starp tām, pamatojoties uz specifiskiem noteikumiem un notikumiem.

1. Sekotājs

• Pasīvā loma: Sekotāji ir vispasīvākā loma Raft. Viņi vienkārši reaģē uz līdera un kandidātu pieprasījumiem.
• Sirds ritmu saņemšana: Sekotājs sagaida saņemt sirds ritmus (tukšus AppendEntries RPC) no līdera regulāri. Ja sekotājs noteiktā vēlēšanu taimauta periodā nesaņem sirds ritmus vai AppendEntries RPC, tas pieņem, ka līderis ir sabrucis, un pāriet kandidāta stāvoklī.
• Balsošana: Vēlēšanu laikā sekotājs balsos par ne vairāk kā vienu kandidātu katrā termiņā.
• Žurnāla replikācija: Sekotāji pievieno žurnāla ierakstus savam lokālajam žurnālam, kā norādījis līderis.

2. Kandidāts

• Vēlēšanu uzsākšana: Kad sekotājs pārsniedz taimautu (nedzird no līdera), tas pāriet kandidāta stāvoklī, lai uzsāktu jaunu vēlēšanu.
• Pašbalsošana: Kandidāts palielina savu pašreizējo termiņu, balso par sevi un nosūta RequestVote RPC visiem citiem klastera serveriem.
• Vēlēšanu uzvara: Ja kandidāts saņem balsis no vairuma klastera serveru vienā un tajā pašā termiņā, tas pāriet līdera stāvoklī.
• Nokāpšana: Ja kandidāts atklāj citu serveri ar augstāku termiņu, vai ja tas saņem AppendEntries RPC no likumīga līdera, tas atgriežas sekotāja stāvoklī.

3. Līderis

• Vienīgā autoritāte: Jebkurā Raft klasterī jebkurā laikā ir tikai viens līderis (attiecīgajam termiņam). Līderis ir atbildīgs par visām klientu mijiedarbībām, žurnāla replikāciju un konsekvences nodrošināšanu.
• Sirds ritmu sūtīšana: Līderis periodiski sūta AppendEntries RPC (sirds ritmus) visiem sekotājiem, lai saglabātu savu autoritāti un novērstu jaunas vēlēšanas.
• Žurnāla pārvaldība: Līderis pieņem klientu pieprasījumus, pievieno jaunus žurnāla ierakstus savam lokālajam žurnālam un pēc tam replicē šos ierakstus visiem sekotājiem.
• Apstiprināšana: Līderis nosaka, kad ieraksts ir droši replicēts vairumam serveru un var tikt apstiprināts stāvokļa mašīnā.
• Nokāpšana: Ja līderis atklāj serveri ar augstāku termiņu, tas nekavējoties nokāpj un atgriežas sekotāja stāvoklī. Tas nodrošina, ka sistēma vienmēr virzās uz priekšu ar augstāko zināmo termiņu.

Raft darbības fāzes: detalizēta izskaidrošana

Raft darbojas nepārtrauktā līdera vēlēšanu un žurnāla replikācijas ciklā. Šie divi primārie mehānismi, līdztekus svarīgajām drošības īpašībām, nodrošina klastera konsekvenci un kļūdu toleranci.

1. Līdera vēlēšanas

Līdera vēlēšanu process ir Raft darbības pamats, nodrošinot, ka klasterim vienmēr ir viena, autoritatīva mezgla, kas koordinē darbības.

• Vēlēšanu taimauts: Katrs sekotājs uztur nejaušu vēlēšanu taimautu (parasti 150-300 ms). Ja sekotājs nenesaņem nekādu saziņu (sirds ritmu vai AppendEntries RPC) no pašreizējā līdera šajā taimauta periodā, tas pieņem, ka līderis ir sabrucis vai noticis tīkla sadalījums.
• Pāreja uz kandidātu: Pēc taimauta sekotājs pāriet Kandidāta stāvoklī. Tas palielina savu pašreizējo termiņu, balso par sevi un atiestata savu vēlēšanu taimeri.
• RequestVote RPC: Kandidāts pēc tam nosūta RequestVote RPC visiem citiem klastera serveriem. Šis RPC ietver kandidāta pašreizējo termiņu, tā kandidātaId un informāciju par tā pēdējo žurnāla indeksu un pēdējo žurnāla termiņu (vairāk par to, kāpēc tas ir svarīgi drošībai vēlāk).
• Balsošanas noteikumi: Serveris piešķirs savu balsi kandidātam, ja:
  1. Tā pašreizējais termiņš ir mazāks vai vienāds ar kandidāta termiņu.
  2. Tas vēl nav balsojis par citu kandidātu pašreizējā termiņā.
  3. Kandidāta žurnāls ir vismaz tikpat aktuāls kā tā paša žurnāls. Tas tiek noteikts, vispirms salīdzinot pēdējo žurnāla termiņu, tad pēdējo žurnāla indeksu, ja termiņi ir vienādi. Kandidāts ir "aktuāls", ja tā žurnālā ir visi apstiprinātie ieraksti, kas ir cita servera žurnālā. Šī ir pazīstama kā vēlēšanu ierobežojums un ir kritiska drošībai.
• Vēlēšanu uzvara: Kandidāts kļūst par jauno līderi, ja tas saņem balsis no vairākuma serveru klasterī vienā un tajā pašā termiņā. Pēc ievēlēšanas jaunais līderis nekavējoties nosūta AppendEntries RPC (sirds ritmus) visiem citiem serveriem, lai nodibinātu savu autoritāti un novērstu jaunas vēlēšanas.
• Balsojumu sadalīšana un atkārtoti mēģinājumi: Ir iespējams, ka vienlaicīgi parādās vairāki kandidāti, izraisot balsojumu sadalīšanu, kur neviens kandidāts nesaņem vairākumu. Lai to atrisinātu, katram kandidātam ir nejaušs vēlēšanu taimauts. Ja kandidāta taimauts beidzas bez vēlēšanu uzvaras vai bez jauna līdera dzirdēšanas, tas palielina savu termiņu un uzsāk jaunu vēlēšanu. Nejaušība palīdz nodrošināt, ka balsojumu sadalīšana ir reta un ātri tiek atrisināta.
• Augstāku termiņu atklāšana: Ja kandidāts (vai jebkurš serveris) saņem RPC ar termiņu, kas augstāks par tā paša pašreizējo termiņu, tas nekavējoties atjaunina savu pašreizējo termiņu uz augstāko vērtību un atgriežas sekotāja stāvoklī. Tas nodrošina, ka serveris ar novecojušu informāciju nekad nemēģina kļūt par līderi vai traucēt likumīgu līderi.

2. Žurnāla replikācija

Kad līderis ir ievēlēts, tā galvenā atbildība ir pārvaldīt replikēto žurnālu un nodrošināt konsekvenci visā klasterī. Tas ietver klientu komandu pieņemšanu, to pievienošanu savam žurnālam un to replikāciju sekotājiem.

• Klientu pieprasījumi: Visi klientu pieprasījumi (komandas, kas jāizpilda stāvokļa mašīnā) tiek novirzīti uz līderi. Ja klients sazinās ar sekotāju, sekotājs novirza pieprasījumu uz pašreizējo līderi.
• Pievienošana līdera žurnālam: Kad līderis saņem klienta komandu, tas pievieno komandu kā jaunu žurnāla ierakstu savam lokālajam žurnālam. Katrs žurnāla ieraksts satur pašu komandu, termiņu, kurā tas tika saņemts, un tā žurnāla indeksu.
• AppendEntries RPC: Pēc tam līderis nosūta AppendEntries RPC visiem sekotājiem, pieprasot tiem pievienot jauno žurnāla ierakstu (vai ierakstu kopumu) saviem žurnāliem. Šie RPC ietver:
  • termiņš: Līdera pašreizējais termiņš.
  • līderaId: Līdera ID (lai sekotāji varētu novirzīt klientus).
  • iepriekšējaisŽurnālaIndekss: Žurnāla ieraksta indekss, kas tieši priekšā jaunajiem ierakstiem.
  • iepriekšējaisŽurnālaTermiņš: iepriekšējaisŽurnālaIndekss ieraksta termiņš. Šie divi (iepriekšējaisŽurnālaIndekss, iepriekšējaisŽurnālaTermiņš) ir ļoti svarīgi žurnāla atbilstības īpašībai.
  • ieraksti[]: Žurnāla ieraksti, kas jāglabā (tukšs sirds ritmiem).
  • līderaApstiprinājumaIndekss: Līdera apstiprinājumaIndekss (visaugstākais žurnāla ieraksta indekss, par kuru zināms, ka tas ir apstiprināts).
• Konsekvences pārbaude (žurnāla atbilstības īpašība): Kad sekotājs saņem AppendEntries RPC, tas veic konsekvences pārbaudi. Tas pārbauda, vai tā žurnālā ir ieraksts pie iepriekšējaisŽurnālaIndekss ar termiņu, kas atbilst iepriekšējaisŽurnālaTermiņš. Ja šī pārbaude neizdodas, sekotājs noraida AppendEntries RPC, informējot līderi, ka tā žurnāls ir nesaistīts.
• Nesaistību novēršana: Ja sekotājs noraida AppendEntries RPC, līderis samazina nākamoIndeksu attiecībā uz šo sekotāju un atkārtoti mēģina AppendEntries RPC. nākamoIndekss ir nākamā žurnāla ieraksta indekss, ko līderis nosūtīs konkrētam sekotājam. Šis process turpinās, līdz nākamoIndekss sasniegs punktu, kurā līdera un sekotāja žurnāli atbilst. Kad atbilstība ir atrasta, sekotājs var pieņemt turpmākos žurnāla ierakstus, galu galā padarot tā žurnālu atbilstošu līdera žurnālam.
• Ierakstu apstiprināšana: Ieraksts tiek uzskatīts par apstiprinātu, kad līderis to ir veiksmīgi replicējis vairumam serveru (ieskaitot sevi). Kad ieraksts ir apstiprināts, to var lietot stāvokļa mašīnā. Līderis atjaunina savu apstiprinājumaIndeksu un iekļauj to turpmākos AppendEntries RPC, lai informētu sekotājus par apstiprinātajiem ierakstiem. Sekotāji atjaunina savu apstiprinājumaIndeksu, pamatojoties uz līdera līderaApstiprinājumaIndeksu, un piemēro ierakstus līdz šim indeksam savai stāvokļa mašīnai.
• Līdera pilnīguma īpašība: Raft garantē, ka, ja žurnāla ieraksts ir apstiprināts noteiktā termiņā, tad visi turpmākie līderi to arī obligāti saturēs. Šī īpašība tiek nodrošināta ar vēlēšanu ierobežojumu: kandidāts var uzvarēt vēlēšanās tikai tad, ja tā žurnāls ir vismaz tikpat aktuāls kā vairumam citu serveru. Tas novērš līderi, kas varētu pārrakstīt vai palaist garām apstiprinātos ierakstus.

3. Drošības īpašības un garantijas

Raft robustums izriet no vairākām rūpīgi izstrādātām drošības īpašībām, kas novērš nesaistības un nodrošina datu integritāti:

• Vēlēšanu drošība: Jebkurā noteiktā termiņā var tikt ievēlēts ne vairāk kā viens līderis. Tas tiek nodrošināts ar balsošanas mehānismu, kur sekotājs piešķir ne vairāk kā vienu balsi katrā termiņā, un kandidātam nepieciešams vairākums balsu.
• Līdera pilnīgums: Ja žurnāla ieraksts ir apstiprināts noteiktā termiņā, tad šis ieraksts būs visu turpmāko līderu žurnālos. Tas ir ļoti svarīgi, lai novērstu apstiprināto datu zudumu, un to galvenokārt nodrošina vēlēšanu ierobežojums.
• Žurnāla atbilstības īpašība: Ja divi žurnāli satur ierakstu ar vienādu indeksu un termiņu, tad žurnāli ir identiski visos iepriekšējos ierakstos. Tas vienkāršo žurnāla konsekvences pārbaudes un ļauj līderim efektīvi atjaunināt sekotāju žurnālus.
• Apstiprināšanas drošība: Kad ieraksts ir apstiprināts, tas nekad netiks atcelts vai pārrakstīts. Tas ir tiešs Līdera pilnīguma un Žurnāla atbilstības īpašību rezultāts. Kad ieraksts ir apstiprināts, tas tiek uzskatīts par pastāvīgi saglabātu.

Galvenie jēdzieni un mehānismi Raft

Papildus lomām un darbības fāzēm Raft paļaujas uz vairākiem galvenajiem jēdzieniem, lai pārvaldītu stāvokli un nodrošinātu pareizību.

1. Termiņi

Termiņš Raft ir nepārtraukti pieaugošs vesels skaitlis. Tas darbojas kā loģisks pulkstenis klasterim. Katrs termiņš sākas ar vēlēšanām, un, ja vēlēšanas ir veiksmīgas, šim termiņam tiek ievēlēts viens līderis. Termiņi ir ļoti svarīgi, lai identificētu novecojušu informāciju un nodrošinātu, ka serveri vienmēr atsakās no visaktuālākās informācijas:

• Serveri apmainās ar saviem pašreizējiem termiņiem visos RPC.
• Ja serveris atklāj citu serveri ar augstāku termiņu, tas atjaunina savu pašreizējo termiņu un atgriežas sekotāja stāvoklī.
• Ja kandidāts vai līderis atklāj, ka tā termiņš ir novecojis (zemāks par cita servera termiņu), tas nekavējoties nokāpj.

2. Žurnāla ieraksti

Žurnāls ir Raft centrālais komponents. Tā ir sakārtota ierakstu secība, kur katrs žurnāla ieraksts pārstāv komandu, kas jāizpilda stāvokļa mašīnā. Katrs ieraksts satur:

• Komanda: Faktiskā operācija, kas jāveic (piemēram, "iestatīt x=5", "izveidot lietotāju").
• Termiņš: Termiņš, kurā ieraksts tika izveidots līderī.
• Indekss: Ieraksta pozīcija žurnālā. Žurnāla ieraksti ir stingri sakārtoti pēc indeksa.

Žurnāls ir pastāvīgs, kas nozīmē, ka ieraksti tiek ierakstīti stabilā krātuvē pirms atbildēšanas klientiem, pasargājot no datu zuduma avāriju gadījumā.

3. Stāvokļa mašīna

Katra Raft klastera serveris uztur stāvokļa mašīnu. Tas ir lietojumprogrammai specifisks komponents, kas apstrādā apstiprinātos žurnāla ierakstus. Lai nodrošinātu konsekvenci, stāvokļa mašīnai jābūt deteministiskai (ņemot vērā tādu pašu sākotnējo stāvokli un komandu secību, tā vienmēr rada tādu pašu izvadi un galīgo stāvokli) un idempotentai (tās pašas komandas atkārtota piemērošana ir tāda pati kā tās vienreizējas piemērošanas, kas palīdz viegli apstrādāt atkārtotus mēģinājumus, lai gan Raft žurnāla apstiprināšana lielā mērā garantē vienreizēju piemērošanu).

4. Apstiprinājuma indekss

Apstiprinājuma indekss ir visaugstākais žurnāla ieraksta indekss, par kuru zināms, ka tas ir apstiprināts. Tas nozīmē, ka tas ir droši replicēts vairumam serveru un var tikt lietots stāvokļa mašīnā. Līderi nosaka apstiprinājumaIndeksu, un sekotāji atjaunina savu apstiprinājumaIndeksu, pamatojoties uz līdera AppendEntries RPC. Visi ieraksti līdz apstiprinājumaIndekss tiek uzskatīti par pastāvīgiem un tos nevar atcelt.

5. Momentuzņēmumi

Laika gaitā replikētais žurnāls var kļūt ļoti liels, patērējot ievērojamu diska vietu un palēninot žurnāla replikāciju un atjaunošanu. Raft to risina ar momentuzņēmumiem. Momentuzņēmums ir kompaktā stāvokļa mašīnas stāvokļa reprezentācija noteiktā laika brīdī. Tā vietā, lai saglabātu visu žurnālu, serveri var periodiski "momentuzņemt" savu stāvokli, izmest visus žurnāla ierakstus līdz momentuzņēmuma punktam un pēc tam replicēt momentuzņēmumu jaunajiem vai atpalikušajiem sekotājiem. Šis process ievērojami uzlabo efektivitāti:

• Kompakts žurnāls: Samazina pastāvīgā žurnāla datu apjomu.
• Ātrāka atjaunošana: Jauni vai sabrukuši serveri var saņemt momentuzņēmumu, nevis atskaņot visu žurnālu no sākuma.
• InstallSnapshot RPC: Raft definē InstallSnapshot RPC, lai pārsūtītu momentuzņēmumus no līdera uz sekotājiem.

Lai gan efektīvi, momentuzņēmumu veidošana palielina ieviešanas sarežģītību, īpaši vienlaicīgas momentuzņēmumu izveides, žurnālu apgriešanas un pārsūtīšanas pārvaldībā.

Raft ieviešana: praktiski apsvērumi globālai izvietošanai

Raft elegantā dizaina pārvēršana spēcīgā, ražošanai gatavā sistēmā, īpaši globālai auditorijai un dažādām infrastruktūrām, ietver vairāku praktisku inženierijas izaicinājumu risināšanu.

1. Tīkla aizkavēšanās un sadalījumi globālā kontekstā

Globāli izplatītām sistēmām tīkla aizkavēšanās ir ievērojams faktors. Raft klasterim parasti ir nepieciešams vairākums mezglu, lai vienotos par žurnāla ierakstu, pirms tas var tikt apstiprināts. Klasterī, kas izplatīts pa kontinentiem, mezglu aizkavēšanās var būt simtiem milisekundes. Tas tieši ietekmē:

• Apstiprināšanas aizkavēšanās: Laiks, kas nepieciešams, lai klients pieprasījums tiktu apstiprināts, var tikt palēnināts no vislēnākā tīkla savienojuma līdz vairumam attēlojumu. Stratēģijas, piemēram, tikai lasāmi sekotāji (kas neprasa līdera mijiedarbību novecojušiem lasījumiem) vai ģeogrāfiski apzināta kvoruma konfigurācija (piemēram, 3 mezgli vienā reģionā, 2 citā 5 mezglu klasterī, kur vairākums var būt viena ātra reģiona ietvaros) var to mazināt.
• Līdera vēlēšanu ātrums: Augsta aizkavēšanās var aizkavēt RequestVote RPC, potenciāli izraisot biežākus balsojumu sadalījumus vai ilgākus vēlēšanu laikus. Ir ļoti svarīgi pielāgot vēlēšanu taimautus, lai tie būtu ievērojami lielāki par tipisko mezglu starpaizkavēšanos.
• Tīkla sadalījumu apstrāde: Reālās pasaules tīkli ir pakļauti sadalījumiem. Raft apstrādā sadalījumus pareizi, nodrošinot, ka tikai vairākumu mezglu saturošā daļa var ievēlēt līderi un virzīties uz priekšu. Mazākuma daļa nespēs apstiprināt jaunus ierakstus, tādējādi novēršot "dalīta smadzeņu" scenārijus. Tomēr ilgstoši sadalījumi globāli izplatītā iestatījumā var izraisīt noteiktu reģionu nepieejamību, pieprasot rūpīgus arhitektūras lēmumus par kvoruma izvietojumu.

2. Pastāvīgā krātuve un izturība

Raft pareizība lielā mērā ir atkarīga no tā žurnāla un stāvokļa pastāvības. Pirms serveris atbild uz RPC vai lieto ierakstu savā stāvokļa mašīnā, tas jāpārliecinās, ka attiecīgie dati (žurnāla ieraksti, pašreizējais termiņš, balsotsPar) ir ierakstīti stabilā krātuvē un fsync'd (noskaloti uz diska). Tas novērš datu zudumu avāriju gadījumā. Apsvērumi ietver:

• Veiktspēja: Bieži diska rakstīšana var būt veiktspējas "pullenes kakls". Rakstīšanas grupas un ātrdarbīgu SSD izmantošana ir izplatītas optimizācijas.
• Uzticamība: Kritiskas ir izturīgas un noturīgas krātuves risinājuma (lokālais disks, ar tīklu pievienotā krātuve, mākoņa bloku krātuve) izvēle.
• WAL (Write-Ahead Log): Bieži Raft implementācijas izmanto iepriekš rakstītu žurnālu noturībai, līdzīgi datu bāzēm, lai nodrošinātu, ka izmaiņas tiek ierakstītas diskā pirms to piemērošanas atmiņā.

3. Klientu mijiedarbība un konsekvences modeļi

Klienti mijiedarbojas ar Raft klasteri, nosūtot pieprasījumus līderim. Klientu pieprasījumu apstrāde ietver:

• Līdera atklāšana: Klientiem ir nepieciešams mehānisms, lai atrastu pašreizējo līderi. Tas var būt caur pakalpojumu atklāšanas mehānismu, fiksētu galapunktu, kas novirza, vai mēģinot serverus, līdz viens atbild kā līderis.
• Pieprasījumu atkārtoti mēģinājumi: Klientiem ir jābūt gataviem atkārtoti mēģināt pieprasījumus, ja līderis mainās vai notiek tīkla kļūda.
• Lasīšanas konsekvence: Raft galvenokārt garantē spēcīgu konsekvenci rakstīšanai. Lasīšanai ir iespējami vairāki modeļi:
  • Stingri konsekventi lasījumi: Klients var pieprasīt līderim nodrošināt, ka tā stāvoklis ir aktuāls, nosūtot sirds ritmu vairumam savu sekotāju pirms lasījuma apkalpošanas. Tas garantē jaunumu, bet palielina aizkavēšanos.
  • Līdera īres laika lasījumi: Līderis var iegūt "īres laiku" no vairuma mezglu uz īsu periodu, kura laikā tas zina, ka joprojām ir līderis un var apkalpot lasījumus bez turpmākas vienprātības. Tas ir ātrāk, bet ierobežots laikā.
  • Novecojuši lasījumi (no sekotājiem): Lasīšana tieši no sekotājiem var nodrošināt mazāku aizkavēšanos, bet pastāv risks nolasīt novecojušus datus, ja sekotāja žurnāls atpaliek no līdera. Tas ir pieņemami lietojumprogrammām, kurām lasīšanai pietiek ar galīgo konsekvenci.

4. Konfigurācijas izmaiņas (klastera dalībnieki)

Raft klastera dalībnieku skaita maiņa (serveru pievienošana vai noņemšana) ir sarežģīta operācija, kas arī jāveic, pamatojoties uz vienprātību, lai izvairītos no nesaistībām vai "dalīta smadzeņu" scenārijiem. Raft piedāvā paņēmienu, ko sauc par kopīgu vienprātību:

• Divas konfigurācijas: Konfigurācijas maiņas laikā sistēma īslaicīgi darbojas ar divām pārklājošām konfigurācijām: veco konfigurāciju (C_old) un jauno konfigurāciju (C_new).
• Kopīgās vienprātības stāvoklis (C_old, C_new): Līderis ierosina speciālu žurnāla ierakstu, kas pārstāv kopīgo konfigurāciju. Kad šis ieraksts ir apstiprināts (nepieciešama vienošanās no C_old un C_new vairākumiem), sistēma ir pārejas stāvoklī. Tagad lēmumi prasa vairākumus no abām konfigurācijām. Tas nodrošina, ka pārejas laikā ne vecā, ne jaunā konfigurācija nevar pieņemt lēmumus vienpersoniski, novēršot atšķirības.
• Pāreja uz C_new: Kad kopīgās konfigurācijas žurnāla ieraksts ir apstiprināts, līderis ierosina citu žurnāla ierakstu, kas pārstāv tikai jauno konfigurāciju (C_new). Kad šis otrais ieraksts ir apstiprināts, vecā konfigurācija tiek izmesta, un sistēma darbojas tikai zem C_new.
• Drošība: Šis divu posmu apstiprinājuma līdzīgais process nodrošina, ka nekādā brīdī nevar tikt ievēlēti divi pretrunīgi līderi (viens zem C_old, viens zem C_new), un ka sistēma paliek funkcionāla visā maiņas laikā.

Pareizas konfigurācijas izmaiņu ieviešana ir viena no sarežģītākajām Raft algoritma daļām, pateicoties daudzajiem malu gadījumiem un kļūmju scenārijiem pārejas stāvoklī.

5. Izplatīto sistēmu testēšana: stingra pieeja

Raft līdzīga izplatītā vienprātības algoritma testēšana ir ārkārtīgi sarežģīta, pateicoties tā nedeterministiskajai dabai un plašajām kļūmju metodēm. Vienkāršas vienības testēšanas nav pietiekami. Stingra testēšana ietver:

• Kļūmju injekcija: Sistēmatiska kļūmju ieviešana, piemēram, mezglu avārijas, tīkla sadalījumi, ziņojumu aizkavēšanās un ziņojumu pārkārtošana. Tādi rīki kā Jepsen ir īpaši izstrādāti šim nolūkam.
• Īpašībās balstīta testēšana: Invariantu un drošības īpašību (piemēram, ne vairāk kā viens līderis katrā termiņā, apstiprinātie ieraksti nekad netiek zaudēti) definēšana un testēšana, ka implementācija tos ievēro dažādos apstākļos.
• Modeļu pārbaude: Kritiskajām algoritma daļām var izmantot formālās verifikācijas metodes, lai pierādītu pareizību, lai gan tas ir ļoti specializēts.
• Simulēti vides: Testu veikšana vidēs, kas simulē tīkla apstākļus (aizkavēšanās, pakešu zudums), kas raksturīgi globālajām izvietojumiem.

Lietošanas gadījumi un reālās pasaules lietojumprogrammas

Raft praktiskums un saprotamība ir noveduši pie tā plašās izmantošanas dažādos kritiskas infrastruktūras komponentos:

1. Izplatīti atslēgu-vērtību veikali un datu bāzu replikācija

• etcd: Kubernetes pamata komponents, etcd izmanto Raft, lai glabātu un replicētu konfigurācijas datus, pakalpojumu atklāšanas informāciju un pārvaldītu klastera stāvokli. Tā uzticamība ir vissvarīgākā, lai Kubernetes darbotos pareizi.
• Consul: HashiCorp izstrādātais Consul izmanto Raft savam izplatītajam krātuves pamatā, ļaujot pakalpojumu atklāšanu, veselības pārbaudi un konfigurācijas pārvaldību dinamiskās infrastruktūras vidēs.
• TiKV: Izplatītais transakciju atslēgu-vērtību veikals, ko izmanto TiDB (izplatīta SQL datu bāze), ievieš Raft savai datu replikācijai un konsekvences garantijām.
• CockroachDB: Šī globāli izplatītā SQL datu bāze plaši izmanto Raft, lai replicētu datus vairākos mezglos un ģeogrāfiskajos apgabalos, nodrošinot augstu pieejamību un spēcīgu konsekvenci pat tad, ja rodas reģiona mēroga kļūmes.

2. Pakalpojumu atklāšana un konfigurācijas pārvaldība

Raft nodrošina ideālu pamatu sistēmām, kurām nepieciešams uzglabāt un izplatīt kritisku metadatu par pakalpojumiem un konfigurācijām visā klasterī. Kad pakalpojums reģistrējas vai tā konfigurācija mainās, Raft nodrošina, ka visi mezgli galu galā vienojas par jauno stāvokli, ļaujot veikt dinamiskus atjauninājumus bez manuālas iejaukšanās.

3. Izplatīti transakciju koordinatori

Sistēmām, kurām nepieciešama atomiskums vairākās operācijās vai pakalpojumos, Raft var būt pamats izplatītiem transakciju koordinatoriem, nodrošinot, ka transakciju žurnāli tiek konsekventi replicēti pirms izmaiņu apstiprināšanas starp dalībniekiem.

4. Klastera koordinācija un līdera vēlēšanas citās sistēmās

Papildus tiešai datu bāzu vai atslēgu-vērtību veikalu izmantošanai, Raft bieži tiek iegults kā bibliotēka vai galvenais komponents, lai pārvaldītu koordinācijas uzdevumus, ievēlētu līderus citiem izplatītiem procesiem vai nodrošinātu uzticamu vadības plakni lielākās sistēmās. Piemēram, daudzi mākoņa-oriģinālie risinājumi izmanto Raft, lai pārvaldītu savu vadības plaknes komponentu stāvokli.

Raft priekšrocības un trūkumi

Lai gan Raft piedāvā ievērojamas priekšrocības, ir svarīgi saprast tā kompromisus.

Priekšrocības:

• Saprotamība: Tā galvenais dizaina mērķis, padarot to vieglāk ieviest, atkļūdot un saprast nekā vecākiem vienprātības algoritmiem, piemēram, Paxos.
• Stipra konsekvence: Nodrošina spēcīgas konsekvences garantijas apstiprinātajiem žurnāla ierakstiem, nodrošinot datu integritāti un uzticamību.
• Kļūdu tolerance: Var pieļaut mazākuma mezglu (līdz (N-1)/2 kļūmju N mezglu klasterī) neveiksmi, nezaudējot pieejamību vai konsekvenci.
• Veiktspēja: Stabilos apstākļos (nav līdera maiņas) Raft var sasniegt augstu caurlaidības spēju, jo līderis secīgi apstrādā visus pieprasījumus un replicē paralēli, efektīvi izmantojot tīkla joslas platumu.
• Skaidri definētas lomas: Skaidras lomas (Līderis, Sekotājs, Kandidāts) un stāvokļa pārejas vienkāršo domas modeli un ieviešanu.
• Konfigurācijas izmaiņas: Piedāvā spēcīgu mehānismu (Kopīgā vienprātība) drošai serveru pievienošanai vai noņemšanai no klastera, nekaitējot konsekvencei.

Trūkumi:

• Līdera "pullenes kakls": Visiem klientu rakstīšanas pieprasījumiem ir jāiet caur līderi. Situācijās ar ārkārtīgi augstu rakstīšanas caurlaidības spēju vai kur līderi ir ģeogrāfiski tālu no klientiem, tas var kļūt par veiktspējas "pullenes kaklu".
• Lasīšanas aizkavēšanās: Stingri konsekventu lasījumu sasniegšana bieži prasa saziņu ar līderi, potenciāli palielinot aizkavēšanos. Lasīšana no sekotājiem rada novecojušu datu risku.
• Kvoruma prasība: Nepieciešams vairākums pieejamo mezglu, lai apstiprinātu jaunus ierakstus. 5 mezglu klasterī ir pieļaujamas 2 kļūmes. Ja sabrūk 3 mezgli, klasteris kļūst nepieejams rakstīšanai. Tas var būt grūti ļoti sadalītās vai ģeogrāfiski izplatītās vidēs, kur ir grūti uzturēt vairākumu visos reģionos.
• Tīkla jutība: Ļoti jutīgs pret tīkla aizkavēšanos un sadalījumiem, kas var ietekmēt vēlēšanu laikus un kopējo sistēmas caurlaidības spēju, īpaši plaši izplatītos izvietojumos.
• Konfigurācijas izmaiņu sarežģītība: Lai gan spēcīgs, Kopīgās vienprātības mehānisms ir viena no sarežģītākajām Raft algoritma daļām, kas jāievieš pareizi un jātestē rūpīgi.
• Viena punkta neveiksmes risks (rakstīšanai): Lai gan kļūmju tolerants līdera neveiksmei, ja līderis ir pastāvīgi pazudis un jaunu līderi nevar ievēlēt (piemēram, tīkla sadalījumu vai pārāk daudz kļūmju dēļ), sistēma nevar veikt progresu rakstīšanā.

Secinājums: Izplatītās vienprātības apgūšana noturīgām globālām sistēmām

Raft algoritms ir apliecinājums pārdomāta dizaina spēkam, vienkāršojot sarežģītas problēmas. Tā uzsvars uz saprotamību ir demokratizējis izplatīto vienprātību, ļaujot plašākam izstrādātāju un organizāciju lokam veidot ļoti pieejamas un kļūmēm tolerējošas sistēmas, nezaudējot iepriekšējo pieeju askētiskajās sarežģītībās.

Sākot ar konteineru kopu orķestrēšanu ar Kubernetes (caur etcd) un beidzot ar globālu datu bāzu, piemēram, CockroachDB, nodrošinot noturīgu datu krātuvi, Raft ir kluss darba zirgs, kas nodrošina, ka mūsu digitālā pasaule paliek konsekventa un funkcionāla. Raft ieviešana nav triviāls uzdevums, taču tā specifikācijas skaidrība un tās apkārtējās ekosistēmas bagātība padara to par atlīdzinošu pasākumu tiem, kas ir apņēmušies veidot nākamās paaudzes spēcīgu, mērogojamu infrastruktūru.

Praktiski ieskati izstrādātājiem un arhitektiem:

• Prioritizējiet izpratni: Pirms ieviešanas mēģinājuma, veltiet laiku, lai rūpīgi izprastu katru Raft noteikumu un stāvokļa pāreju. Sākotnējais dokuments un vizuālie skaidrojumi ir nenovērtējami resursi.
• Izmantojiet esošās bibliotēkas: Lielākajai daļai lietojumprogrammu apsveriet labi pārbaudītu esošo Raft implementāciju izmantošanu (piemēram, no etcd, HashiCorp Raft bibliotēkas), nevis veidošanu no nulles, ja vien jūsu prasības nav ļoti specifiskas vai jūs neveicat akadēmisko izpēti.
• Stingra testēšana ir neapsolāma: Kļūmju injekcija, īpašībās balstīta testēšana un plaša kļūmju scenāriju simulācija ir vissvarīgākā jebkurai izplatītai vienprātības sistēmai. Nekad neuzskatiet "tas darbojas", pirms tas nav rūpīgi salauzts.
• Dizains globālajai aizkavēšanai: Izvietojot globāli, rūpīgi apsveriet savu kvoruma izvietojumu, tīkla topoloģiju un klienta lasīšanas stratēģijas, lai optimizētu gan konsekvenci, gan veiktspēju dažādos ģeogrāfiskajos apgabalos.
• Pastāvība un noturība: Nodrošiniet, ka jūsu zemākā līmeņa krātuves slānis ir spēcīgs un ka fsync vai līdzvērtīgas operācijas tiek pareizi izmantotas, lai novērstu datu zudumu avāriju scenārijos.

Tā kā izplatītās sistēmas turpina attīstīties, Raft iemiesotie principi — skaidrība, noturība un kļūdu tolerance — paliks uzticamas programmatūras inženierijas stūrakmeņi. Apgūstot Raft, jūs aprīkojat sevi ar spēcīgu rīku, lai veidotu noturīgas, globāli mērogojamas lietojumprogrammas, kas var izturēt neizbēgamo izplatītās skaitļošanas haosu.