Овладяване на разпределения консенсус: задълбочен поглед върху имплементацията на алгоритъма Raft за глобални системи

В нашия все по-свързан свят разпределените системи са гръбнакът на почти всяка дигитална услуга, от платформи за електронна търговия и финансови институции до инфраструктура за облачни изчисления и инструменти за комуникация в реално време. Тези системи предлагат несравнима мащабируемост, наличност и устойчивост чрез разпределяне на работни натоварвания и данни между множество машини. Тази мощ обаче идва със значително предизвикателство: да се гарантира, че всички компоненти са съгласни относно състоянието на системата, дори при мрежови закъснения, откази на възли и едновременни операции. Този основен проблем е известен като разпределен консенсус.

Постигането на консенсус в асинхронна, склонна към грешки разпределена среда е изключително сложно. В продължение на десетилетия Paxos беше доминиращият алгоритъм за решаване на това предизвикателство, почитан заради теоретичната си здравина, но често критикуван за своята сложност и трудност при имплементация. След това се появи Raft, алгоритъм, създаден с основна цел: разбираемост. Raft има за цел да бъде еквивалентен на Paxos по отношение на отказоустойчивост и производителност, но структуриран по начин, който е много по-лесен за разбиране и надграждане от разработчиците.

Това изчерпателно ръководство се задълбочава в алгоритъма Raft, изследвайки неговите основополагащи принципи, оперативни механизми, практически съображения при имплементация и жизненоважната му роля в изграждането на здрави, глобално разпределени приложения. Независимо дали сте опитен архитект, инженер по разпределени системи или разработчик, който се стреми да изгражда услуги с висока наличност, разбирането на Raft е съществена стъпка към овладяването на сложностите на съвременните компютърни технологии.

Незаменимата нужда от разпределен консенсус в съвременните архитектури

Представете си глобална платформа за електронна търговия, обработваща милиони транзакции в секунда. Данни на клиенти, нива на инвентара, статуси на поръчки — всичко трябва да остане консистентно в множество центрове за данни, обхващащи континенти. Счетоводната книга на банкова система, разпределена на няколко сървъра, не може да си позволи дори моментно несъгласие относно салдо по сметка. Тези сценарии подчертават критичната важност на разпределения консенсус.

Присъщите предизвикателства на разпределените системи

Разпределените системи, по своята същност, въвеждат безброй предизвикателства, които отсъстват в монолитните приложения. Разбирането на тези предизвикателства е от решаващо значение за оценяването на елегантността и необходимостта на алгоритми като Raft:

• Частични откази: За разлика от един-единствен сървър, който или работи, или отказва напълно, в разпределена система някои възли могат да откажат, докато други продължават да работят. Сървър може да се срине, мрежовата му връзка може да прекъсне или дискът му може да се повреди, докато останалата част от клъстера остава функционална. Системата трябва да продължи да работи коректно въпреки тези частични откази.
• Мрежови разделяния: Мрежата, свързваща възлите, не винаги е надеждна. Мрежово разделяне възниква, когато комуникацията между подмножества от възли е прекъсната, което създава впечатление, че определени възли са отказали, дори ако все още работят. Разрешаването на тези „split-brain“ сценарии, при които различни части на системата работят независимо въз основа на остаряла или неконсистентна информация, е основен проблем на консенсуса.
• Асинхронна комуникация: Съобщенията между възлите могат да бъдат забавени, пренаредени или напълно изгубени. Няма глобален часовник или гаранция за времето на доставка на съобщенията, което затруднява установяването на консистентен ред на събитията или окончателно състояние на системата.
• Едновременност: Множество възли могат да се опитат да актуализират едновременно едни и същи данни или да инициират действия. Без механизъм за координиране на тези операции конфликтите и неконсистентностите са неизбежни.
• Непредсказуемо закъснение (Latency): Особено при глобално разпределени внедрявания, мрежовото закъснение може да варира значително. Операции, които са бързи в един регион, може да са бавни в друг, което засяга процесите на вземане на решения и координацията.

Защо консенсусът е крайъгълният камък на надеждността

Консенсусните алгоритми предоставят основен градивен елемент за решаване на тези предизвикателства. Те позволяват на колекция от ненадеждни компоненти да действат колективно като едно, силно надеждно и съгласувано цяло. По-конкретно, консенсусът помага да се постигне:

• Репликация на машина на състоянията (SMR): Основната идея зад много отказоустойчиви разпределени системи. Ако всички възли се съгласят относно реда на операциите и ако всеки възел започва в същото начално състояние и изпълнява тези операции в същия ред, тогава всички възли ще достигнат до същото крайно състояние. Консенсусът е механизмът за съгласуване на този глобален ред на операциите.
• Висока наличност: Като позволява на системата да продължи да работи, дори ако малцинство от възлите откажат, консенсусът гарантира, че услугите остават достъпни и функционални, минимизирайки времето на престой.
• Консистентност на данните: Гарантира, че всички реплики на данните остават синхронизирани, предотвратявайки конфликтни актуализации и гарантирайки, че клиентите винаги четат най-актуалната и коректна информация.
• Отказоустойчивост: Системата може да толерира определен брой произволни откази на възли (обикновено сривове) и да продължи да напредва без човешка намеса.

Представяне на Raft: разбираем подход към консенсуса

Raft се появява от академичния свят с ясна цел: да направи разпределения консенсус достъпен. Неговите автори, Диего Онгаро и Джон Оустерхаут, изрично проектират Raft с цел разбираемост, стремейки се да позволят по-широко приемане и правилна имплементация на консенсусни алгоритми.

Основната философия на дизайна на Raft: разбираемостта на първо място

Raft разгражда сложния проблем на консенсуса на няколко относително независими подпроблема, всеки със свой собствен специфичен набор от правила и поведения. Тази модулност значително подпомага разбирането. Ключовите принципи на дизайна включват:

• Лидер-центриран подход: За разлика от някои други консенсусни алгоритми, при които всички възли участват равностойно във вземането на решения, Raft определя един-единствен лидер. Лидерът е отговорен за управлението на репликирания лог и координирането на всички клиентски заявки. Това опростява управлението на лога и намалява сложността на взаимодействията между възлите.
• Силен лидер: Лидерът е върховният авторитет за предлагане на нови записи в лога и определяне кога те са потвърдени (committed). Последователите пасивно репликират лога на лидера и отговарят на неговите заявки.
• Детерминистични избори: Raft използва рандомизирано време за изчакване на избори (election timeout), за да гарантира, че обикновено само един кандидат се появява като лидер в даден изборен мандат.
• Консистентност на лога: Raft налага строги свойства за консистентност на своя репликиран лог, гарантирайки, че потвърдените записи никога не се отменят и че всички потвърдени записи в крайна сметка се появяват на всички налични възли.

Кратко сравнение с Paxos

Преди Raft, Paxos беше де факто стандартът за разпределен консенсус. Въпреки че е мощен, Paxos е изключително труден за разбиране и правилна имплементация. Неговият дизайн, който разделя ролите (proposer, acceptor, learner) и позволява съществуването на няколко лидера едновременно (въпреки че само един може да потвърди стойност), може да доведе до сложни взаимодействия и гранични случаи.

Raft, за разлика от него, опростява пространството на състоянията. Той налага силен лидерски модел, при който лидерът е отговорен за всички промени в лога. Той ясно дефинира ролите (лидер, последовател, кандидат) и преходите между тях. Тази структура прави поведението на Raft по-интуитивно и по-лесно за разсъждение, което води до по-малко грешки при имплементация и по-бързи цикли на разработка. Много системи в реалния свят, които първоначално са се сблъсквали с трудности с Paxos, са постигнали успех, като са приели Raft.

Трите основни роли в Raft

Във всеки даден момент всеки сървър в клъстер на Raft е в едно от три състояния: лидер (Leader), последовател (Follower) или кандидат (Candidate). Тези роли са изключителни и динамични, като сървърите преминават между тях въз основа на специфични правила и събития.

1. Последовател (Follower)

• Пасивна роля: Последователите са в най-пасивното състояние в Raft. Те просто отговарят на заявки от лидери и кандидати.
• Получаване на пулсации (Heartbeats): Последователят очаква да получава пулсации (празни AppendEntries RPC) от лидера на редовни интервали. Ако последовател не получи пулсация или AppendEntries RPC в рамките на определен период на изчакване на избори (election timeout), той приема, че лидерът е отказал и преминава в състояние на кандидат.
• Гласуване: По време на избори последователят ще гласува за най-много един кандидат на мандат.
• Репликация на лога: Последователите добавят записи в своя локален лог, както е указано от лидера.

2. Кандидат (Candidate)

• Иницииране на избори: Когато времето за изчакване на последовател изтече (не получава съобщение от лидера), той преминава в състояние на кандидат, за да инициира нови избори.
• Самогласуване: Кандидатът увеличава своя текущ мандат (current term), гласува за себе си и изпраща RequestVote RPC до всички други сървъри в клъстера.
• Спечелване на избори: Ако кандидат получи гласове от мнозинството сървъри в клъстера за същия мандат, той преминава в състояние на лидер.
• Оттегляне: Ако кандидат открие друг сървър с по-висок мандат или ако получи AppendEntries RPC от легитимен лидер, той се връща в състояние на последовател.

3. Лидер (Leader)

• Единствен авторитет: Във всеки даден момент (за даден мандат) в клъстер на Raft има само един лидер. Лидерът е отговорен за всички взаимодействия с клиенти, репликация на лога и гарантиране на консистентност.
• Изпращане на пулсации: Лидерът периодично изпраща AppendEntries RPC (пулсации) до всички последователи, за да поддържа своя авторитет и да предотврати нови избори.
• Управление на лога: Лидерът приема клиентски заявки, добавя нови записи в своя локален лог и след това репликира тези записи до всички последователи.
• Потвърждаване (Commitment): Лидерът решава кога даден запис е безопасно репликиран на мнозинството от сървърите и може да бъде потвърден (committed) в машината на състоянията.
• Оттегляне: Ако лидерът открие сървър с по-висок мандат (term), той незабавно се оттегля и се връща в състояние на последовател. Това гарантира, че системата винаги напредва с най-високия известен мандат.

Оперативни фази на Raft: подробен преглед

Raft работи чрез непрекъснат цикъл на избор на лидер и репликация на лога. Тези два основни механизма, заедно с решаващи свойства за безопасност, гарантират, че клъстерът поддържа консистентност и отказоустойчивост.

1. Избор на лидер (Leader Election)

Процесът на избор на лидер е фундаментален за работата на Raft, като гарантира, че клъстерът винаги има един-единствен, авторитетен възел за координиране на действията.

• Време за изчакване на избори (Election Timeout): Всеки последовател поддържа рандомизирано време за изчакване на избори (обикновено 150-300ms). Ако последовател не получи никаква комуникация (пулсация или AppendEntries RPC) от текущия лидер в рамките на този период, той приема, че лидерът е отказал или е настъпило мрежово разделяне.
• Преход към кандидат: При изтичане на времето за изчакване, последователят преминава в състояние кандидат. Той увеличава своя текущ мандат, гласува за себе си и нулира своя таймер за избори.
• RequestVote RPC: Кандидатът изпраща RequestVote RPC до всички други сървъри в клъстера. Този RPC включва текущия мандат на кандидата, неговия candidateId и информация за неговия последен индекс в лога (last log index) и последен мандат в лога (last log term) (повече защо това е от решаващо значение за безопасността по-късно).
• Правила за гласуване: Сървър ще даде своя глас на кандидат, ако:
  1. Неговият текущ мандат е по-малък или равен на мандата на кандидата.
  2. Все още не е гласувал за друг кандидат в текущия мандат.
  3. Логът на кандидата е поне толкова актуален, колкото неговият собствен. Това се определя чрез сравняване първо на последния мандат в лога, след това на последния индекс в лога, ако мандатите са еднакви. Кандидатът е „актуален“, ако неговият лог съдържа всички потвърдени записи, които съдържа логът на гласоподавателя. Това е известно като ограничение при избори (election restriction) и е критично за безопасността.
• Спечелване на изборите: Кандидат става новият лидер, ако получи гласове от мнозинството сървъри в клъстера за същия мандат. Веднъж избран, новият лидер незабавно изпраща AppendEntries RPC (пулсации) до всички други сървъри, за да установи своя авторитет и да предотврати нови избори.
• Разделени гласове и повторни опити: Възможно е няколко кандидати да се появят едновременно, което да доведе до разделен вот, при който никой кандидат не получава мнозинство. За да се реши това, всеки кандидат има рандомизирано време за изчакване на избори. Ако времето за изчакване на кандидата изтече, без да е спечелил изборите или да е получил съобщение от нов лидер, той увеличава своя мандат и започва нови избори. Рандомизацията помага да се гарантира, че разделените гласове са рядкост и се разрешават бързо.
• Откриване на по-високи мандати: Ако кандидат (или който и да е сървър) получи RPC с мандат, по-висок от собствения му текущ мандат, той незабавно актуализира своя текущ мандат до по-високата стойност и се връща в състояние на последовател. Това гарантира, че сървър с остаряла информация никога не се опитва да стане лидер или да наруши работата на легитимен лидер.

2. Репликация на лога (Log Replication)

След като бъде избран лидер, неговата основна отговорност е да управлява репликирания лог и да гарантира консистентност в целия клъстер. Това включва приемане на клиентски команди, добавянето им към своя лог и репликирането им до последователите.

• Клиентски заявки: Всички клиентски заявки (команди, които трябва да бъдат изпълнени от машината на състоянията) се насочват към лидера. Ако клиент се свърже с последовател, последователят пренасочва заявката към текущия лидер.
• Добавяне към лога на лидера: Когато лидерът получи клиентска команда, той я добавя като нов запис в лога (log entry) към своя локален лог. Всеки запис в лога съдържа самата команда, мандата, в който е получена, и нейния индекс в лога (log index).
• AppendEntries RPC: След това лидерът изпраща AppendEntries RPC до всички последователи, като ги моли да добавят новия запис в лога (или партида от записи) към своите логове. Тези RPC включват:
  • term: Текущият мандат на лидера.
  • leaderId: ID на лидера (за да могат последователите да пренасочват клиенти).
  • prevLogIndex: Индексът на записа в лога, непосредствено предхождащ новите записи.
  • prevLogTerm: Мандатът на записа на prevLogIndex. Тези две (prevLogIndex, prevLogTerm) са от решаващо значение за свойството за съвпадение на лога.
  • entries[]: Записите в лога, които да се съхранят (празен за пулсации).
  • leaderCommit: commitIndex на лидера (индексът на най-високия запис в лога, за който е известно, че е потвърден).
• Проверка за консистентност (Log Matching Property): Когато последовател получи AppendEntries RPC, той извършва проверка за консистентност. Той проверява дали неговият лог съдържа запис на prevLogIndex с мандат, съответстващ на prevLogTerm. Ако тази проверка е неуспешна, последователят отхвърля AppendEntries RPC, информирайки лидера, че логът му е неконсистентен.
• Разрешаване на неконсистентности: Ако последовател отхвърли AppendEntries RPC, лидерът намалява nextIndex за този последовател и опитва отново с AppendEntries RPC. nextIndex е индексът на следващия запис в лога, който лидерът ще изпрати на конкретен последовател. Този процес продължава, докато nextIndex достигне точка, в която логовете на лидера и последователя съвпадат. След като се намери съвпадение, последователят може да приеме последващи записи в лога, като в крайна сметка приведе своя лог в съответствие с този на лидера.
• Потвърждаване на записи: Даден запис се счита за потвърден (committed), когато лидерът успешно го е репликирал на мнозинството от сървърите (включително себе си). Веднъж потвърден, записът може да бъде приложен към локалната машина на състоянията. Лидерът актуализира своя commitIndex и включва това в последващи AppendEntries RPC, за да информира последователите за потвърдените записи. Последователите актуализират своя commitIndex въз основа на leaderCommit на лидера и прилагат записи до този индекс към своята машина на състоянията.
• Свойство за пълнота на лидера (Leader Completeness Property): Raft гарантира, че ако даден запис в лога е потвърден в даден мандат, тогава всички последващи лидери също трябва да имат този запис. Това свойство се налага от ограничението при избори: кандидат може да спечели избори само ако неговият лог е поне толкова актуален, колкото този на мнозинството от другите сървъри. Това предотвратява избирането на лидер, който може да презапише или пропусне потвърдени записи.

3. Свойства за безопасност и гаранции

Здравината на Raft произтича от няколко внимателно проектирани свойства за безопасност, които предотвратяват неконсистентности и гарантират целостта на данните:

• Безопасност на изборите: В даден мандат може да бъде избран най-много един лидер. Това се налага от механизма за гласуване, при който последовател дава най-много един глас на мандат, а кандидат се нуждае от мнозинство от гласовете.
• Пълнота на лидера: Ако даден запис в лога е бил потвърден в даден мандат, тогава този запис ще присъства в логовете на всички последващи лидери. Това е от решаващо значение за предотвратяване на загуба на потвърдени данни и се гарантира предимно от ограничението при избори.
• Свойство за съвпадение на лога: Ако два лога съдържат запис със същия индекс и мандат, тогава логовете са идентични във всички предходни записи. Това опростява проверките за консистентност на лога и позволява на лидера ефективно да актуализира логовете на последователите.
• Безопасност на потвърждаването: След като даден запис е потвърден, той никога няма да бъде отменен или презаписан. Това е пряко следствие от свойствата за пълнота на лидера и съвпадение на лога. След като даден запис е потвърден, той се счита за постоянно съхранен.

Ключови концепции и механизми в Raft

Освен ролите и оперативните фази, Raft разчита на няколко основни концепции за управление на състоянието и гарантиране на коректност.

1. Мандати (Terms)

Мандат (term) в Raft е непрекъснато нарастващо цяло число. Той действа като логически часовник за клъстера. Всеки мандат започва с избори и ако изборите са успешни, за този мандат се избира един-единствен лидер. Мандатите са от решаващо значение за идентифициране на остаряла информация и гарантиране, че сървърите винаги се подчиняват на най-актуалната информация:

• Сървърите обменят своя текущ мандат във всички RPC.
• Ако сървър открие друг сървър с по-висок мандат, той актуализира собствения си текущ мандат и се връща в състояние на последовател.
• Ако кандидат или лидер открие, че неговият мандат е остарял (по-нисък от мандата на друг сървър), той незабавно се оттегля.

2. Записи в лога (Log Entries)

Логът (log) е централният компонент на Raft. Това е подредена последователност от записи, където всеки запис в лога представлява команда, която трябва да бъде изпълнена от машината на състоянията. Всеки запис съдържа:

• Команда: Действителната операция, която трябва да бъде извършена (напр. „set x=5“, „create user“).
• Мандат: Мандатът, в който записът е създаден от лидера.
• Индекс: Позицията на записа в лога. Записите в лога са стриктно подредени по индекс.

Логът е персистентен, което означава, че записите се записват на стабилно хранилище, преди да се отговори на клиентите, което предпазва от загуба на данни при сривове.

3. Машина на състоянията (State Machine)

Всеки сървър в клъстер на Raft поддържа машина на състоянията. Това е специфичен за приложението компонент, който обработва потвърдени записи в лога. За да се гарантира консистентност, машината на състоянията трябва да бъде детерминистична (при дадено същото начално състояние и последователност от команди, тя винаги произвежда същия изход и крайно състояние) и идемпотентна (прилагането на една и съща команда няколко пъти има същия ефект като прилагането ѝ веднъж, което помага при грациозно обработване на повторни опити, въпреки че потвърждаването на лога в Raft до голяма степен гарантира еднократно приложение).

4. Индекс на потвърждаване (Commit Index)

commitIndex е най-високият индекс на запис в лога, за който е известно, че е потвърден. Това означава, че той е безопасно репликиран на мнозинството от сървърите и може да бъде приложен към машината на състоянията. Лидерите определят commitIndex, а последователите актуализират своя commitIndex въз основа на AppendEntries RPC от лидера. Всички записи до commitIndex се считат за постоянни и не могат да бъдат отменени.

5. Моментни снимки (Snapshots)

С течение на времето репликираният лог може да нарасне много, консумирайки значително дисково пространство и правейки репликацията и възстановяването на лога бавни. Raft решава този проблем с моментни снимки (snapshots). Моментната снимка е компактно представяне на състоянието на машината на състоянията в определен момент. Вместо да пазят целия лог, сървърите могат периодично да правят „моментна снимка“ на своето състояние, да изхвърлят всички записи в лога до точката на снимката и след това да репликират снимката до нови или изоставащи последователи. Този процес значително подобрява ефективността:

• Компактен лог: Намалява количеството на персистентните данни в лога.
• По-бързо възстановяване: Нови или сринати сървъри могат да получат моментна снимка, вместо да възпроизвеждат целия лог от началото.
• InstallSnapshot RPC: Raft дефинира InstallSnapshot RPC за прехвърляне на моментни снимки от лидера към последователите.

Въпреки че е ефективно, правенето на моментни снимки добавя сложност към имплементацията, особено при управлението на едновременно създаване на снимки, съкращаване на лога и предаване.

Имплементиране на Raft: практически съображения за глобално внедряване

Превеждането на елегантния дизайн на Raft в здрава, готова за производство система, особено за глобална аудитория и разнообразна инфраструктура, включва справяне с няколко практически инженерни предизвикателства.

1. Мрежово закъснение и разделяния в глобален контекст

За глобално разпределени системи мрежовото закъснение е значителен фактор. Клъстер на Raft обикновено изисква мнозинството от възлите да се съгласят за запис в лога, преди той да може да бъде потвърден. В клъстер, разпръснат по континенти, закъснението между възлите може да бъде стотици милисекунди. Това пряко влияе на:

• Закъснение при потвърждаване: Времето, необходимо за потвърждаване на клиентска заявка, може да бъде ограничено от най-бавната мрежова връзка до мнозинството от репликите. Стратегии като последователи само за четене (които не изискват взаимодействие с лидера за остарели четения) или географски осведомена конфигурация на кворума (напр. 3 възела в един регион, 2 в друг за 5-възлов клъстер, където мнозинството може да е в рамките на един бърз регион) могат да смекчат това.
• Скорост на избор на лидер: Високото закъснение може да забави RequestVote RPC, което потенциално може да доведе до по-чести разделени гласове или по-дълго време за избори. Регулирането на времето за изчакване на избори да бъде значително по-голямо от типичното закъснение между възлите е от решаващо значение.
• Обработка на мрежови разделяния: Реалните мрежи са склонни към разделяния. Raft се справя правилно с разделянията, като гарантира, че само разделението, съдържащо мнозинството от сървърите, може да избере лидер и да напредва. Разделението с малцинство няма да може да потвърждава нови записи, като по този начин се предотвратяват „split-brain“ сценарии. Въпреки това, продължителните разделяния в глобално разпределена среда могат да доведат до недостъпност в определени региони, което налага внимателни архитектурни решения относно разположението на кворума.

2. Персистентно съхранение и трайност

Коректността на Raft силно зависи от персистентността на неговия лог и състояние. Преди сървърът да отговори на RPC или да приложи запис към своята машина на състоянията, той трябва да гарантира, че съответните данни (записи в лога, current term, votedFor) са записани на стабилно хранилище и fsync'd (изчистени на диска). Това предотвратява загуба на данни в случай на срив. Съображенията включват:

• Производителност: Честите записи на диска могат да бъдат тесно място за производителността. Пакетирането на записи и използването на високопроизводителни SSD са често срещани оптимизации.
• Надеждност: Изборът на здраво и трайно решение за съхранение (локален диск, мрежово свързано хранилище, облачно блоково хранилище) е от решаващо значение.
• WAL (Write-Ahead Log): Често имплементациите на Raft използват write-ahead log за трайност, подобно на базите данни, за да гарантират, че промените се записват на диска, преди да бъдат приложени в паметта.

3. Взаимодействие с клиенти и модели на консистентност

Клиентите взаимодействат с клъстера на Raft, като изпращат заявки до лидера. Обработката на клиентски заявки включва:

• Откриване на лидера: Клиентите се нуждаят от механизъм за намиране на текущия лидер. Това може да бъде чрез механизъм за откриване на услуги, фиксирана крайна точка, която пренасочва, или чрез опитване на сървъри, докато един от тях отговори като лидер.
• Повторни опити на заявки: Клиентите трябва да са подготвени да опитват отново заявки, ако лидерът се смени или ако възникне мрежова грешка.
• Консистентност при четене: Raft основно гарантира силна консистентност за записи. За четения са възможни няколко модела:
  • Силно консистентни четения: Клиент може да поиска от лидера да гарантира, че състоянието му е актуално, като изпрати пулсация до мнозинството от своите последователи, преди да обслужи четене. Това гарантира свежест, но добавя закъснение.
  • Четения с „наем“ от лидера (Leader-Lease Reads): Лидерът може да придобие „наем“ от мнозинството възли за кратък период, през който знае, че все още е лидер и може да обслужва четения без допълнителен консенсус. Това е по-бързо, но ограничено във времето.
  • Остарели четения (от последователи): Четенето директно от последователи може да предложи по-ниско закъснение, но рискува четене на остарели данни, ако логът на последователя изостава от този на лидера. Това е приемливо за приложения, при които евентуалната консистентност е достатъчна за четения.

4. Промени в конфигурацията (членство в клъстера)

Промяната на членството в клъстер на Raft (добавяне или премахване на сървъри) е сложна операция, която също трябва да се извърши чрез консенсус, за да се избегнат неконсистентности или „split-brain“ сценарии. Raft предлага техника, наречена съвместен консенсус (Joint Consensus):

• Две конфигурации: По време на промяна на конфигурацията системата временно работи с две припокриващи се конфигурации: старата конфигурация (C_old) и новата конфигурация (C_new).
• Състояние на съвместен консенсус (C_old, C_new): Лидерът предлага специален запис в лога, който представлява съвместната конфигурация. След като този запис бъде потвърден (изискващ съгласие от мнозинствата както в C_old, така и в C_new), системата е в преходно състояние. Сега решенията изискват мнозинства и от двете конфигурации. Това гарантира, че по време на прехода нито старата, нито новата конфигурация могат да вземат решения едностранно, предотвратявайки разминаване.
• Преход към C_new: След като записът в лога за съвместната конфигурация бъде потвърден, лидерът предлага друг запис в лога, представляващ само новата конфигурация (C_new). След като този втори запис бъде потвърден, старата конфигурация се отхвърля и системата работи само под C_new.
• Безопасност: Този двуфазен процес, подобен на commit, гарантира, че в нито един момент не могат да бъдат избрани два конфликтуващи лидера (един под C_old, друг под C_new) и че системата остава работеща през цялата промяна.

Правилното имплементиране на промени в конфигурацията е една от най-предизвикателните части на имплементацията на Raft поради многобройните гранични случаи и сценарии на отказ по време на преходното състояние.

5. Тестване на разпределени системи: строг подход

Тестването на алгоритъм за разпределен консенсус като Raft е изключително предизвикателно поради неговия недетерминистичен характер и множеството режими на отказ. Простите единични тестове са недостатъчни. Строгото тестване включва:

• Инжектиране на грешки: Систематично въвеждане на откази като сривове на възли, мрежови разделяния, забавяния на съобщения и пренареждане на съобщения. Инструменти като Jepsen са специално създадени за тази цел.
• Тестване, базирано на свойства (Property-Based Testing): Дефиниране на инварианти и свойства за безопасност (напр. най-много един лидер на мандат, потвърдените записи никога не се губят) и тестване, че имплементацията ги поддържа при различни условия.
• Проверка на модели (Model Checking): За критични части на алгоритъма могат да се използват техники за формална верификация, за да се докаже коректност, въпреки че това е силно специализирано.
• Симулирани среди: Изпълнение на тестове в среди, които симулират мрежови условия (закъснение, загуба на пакети), типични за глобални внедрявания.

Случаи на употреба и приложения в реалния свят

Практичността и разбираемостта на Raft са довели до широкото му приемане в различни критични инфраструктурни компоненти:

1. Разпределени хранилища ключ-стойност и репликация на бази данни

• etcd: Основен компонент на Kubernetes, etcd използва Raft за съхраняване и репликиране на конфигурационни данни, информация за откриване на услуги и управление на състоянието на клъстера. Неговата надеждност е от първостепенно значение за правилната работа на Kubernetes.
• Consul: Разработен от HashiCorp, Consul използва Raft за своя разпределен бекенд за съхранение, позволявайки откриване на услуги, проверка на здравето и управление на конфигурацията в динамични инфраструктурни среди.
• TiKV: Разпределеното транзакционно хранилище ключ-стойност, използвано от TiDB (разпределена SQL база данни), имплементира Raft за репликация на данни и гаранции за консистентност.
• CockroachDB: Тази глобално разпределена SQL база данни използва Raft широко за репликиране на данни в множество възли и географски региони, като гарантира висока наличност и силна консистентност дори при откази в цял регион.

2. Откриване на услуги и управление на конфигурацията

Raft предоставя идеална основа за системи, които трябва да съхраняват и разпространяват критични метаданни за услуги и конфигурации в клъстер. Когато услуга се регистрира или нейната конфигурация се промени, Raft гарантира, че всички възли в крайна сметка се съгласяват за новото състояние, позволявайки динамични актуализации без ръчна намеса.

3. Координатори на разпределени транзакции

За системи, изискващи атомарност на множество операции или услуги, Raft може да бъде основа за координатори на разпределени транзакции, като гарантира, че транзакционните логове са консистентно репликирани преди потвърждаване на промените между участниците.

4. Координация на клъстери и избор на лидер в други системи

Освен изричното използване в бази данни или хранилища ключ-стойност, Raft често се вгражда като библиотека или основен компонент за управление на координационни задачи, избор на лидери за други разпределени процеси или предоставяне на надеждна контролна равнина в по-големи системи. Например, много облачно-базирани решения използват Raft за управление на състоянието на компонентите на своята контролна равнина.

Предимства и недостатъци на Raft

Въпреки че Raft предлага значителни предимства, е важно да се разберат неговите компромиси.

Предимства:

• Разбираемост: Неговата основна цел при проектиране, което го прави по-лесен за имплементиране, отстраняване на грешки и разсъждение в сравнение със стари консенсусни алгоритми като Paxos.
• Силна консистентност: Предоставя силни гаранции за консистентност за потвърдени записи в лога, като гарантира целостта и надеждността на данните.
• Отказоустойчивост: Може да толерира отказа на малцинство от възлите (до (N-1)/2 отказа в клъстер с N възела) без загуба на наличност или консистентност.
• Производителност: В стабилни условия (без смяна на лидер), Raft може да постигне висока пропускателна способност, тъй като лидерът обработва всички заявки последователно и репликира паралелно, използвайки ефективно мрежовата честотна лента.
• Ясно дефинирани роли: Ясните роли (лидер, последовател, кандидат) и преходите на състоянията опростяват мисловния модел и имплементацията.
• Промени в конфигурацията: Предлага здрав механизъм (съвместен консенсус) за безопасно добавяне или премахване на възли от клъстера, без да се компрометира консистентността.

Недостатъци:

• Тесно място при лидера: Всички клиентски заявки за запис трябва да преминат през лидера. В сценарии с изключително висока пропускателна способност на запис или когато лидерите са географски отдалечени от клиентите, това може да се превърне в тесно място за производителността.
• Закъснение при четене: Постигането на силно консистентни четения често изисква комуникация с лидера, което потенциално добавя закъснение. Четенето от последователи рискува остарели данни.
• Изискване за кворум: Изисква мнозинството от възлите да са налични за потвърждаване на нови записи. В 5-възлов клъстер са допустими 2 отказа. Ако 3 възела откажат, клъстерът става недостъпен за записи. Това може да бъде предизвикателство в силно разделени или географски разпръснати среди, където поддържането на мнозинство в различните региони е трудно.
• Чувствителност към мрежата: Силно чувствителен към мрежово закъснение и разделяния, които могат да повлияят на времето за избори и общата пропускателна способност на системата, особено при широко разпределени внедрявания.
• Сложност на промените в конфигурацията: Въпреки че е здрав, механизмът за съвместен консенсус е една от по-сложните части на алгоритъма Raft за правилно имплементиране и щателно тестване.
• Единична точка на отказ (за записи): Въпреки че е отказоустойчив при отказ на лидера, ако лидерът е постоянно неработещ и нов лидер не може да бъде избран (напр. поради мрежови разделяния или твърде много откази), системата не може да напредва със записите.

Заключение: Овладяване на разпределения консенсус за устойчиви глобални системи

Алгоритъмът Raft е доказателство за силата на премисления дизайн при опростяването на сложни проблеми. Неговият акцент върху разбираемостта е демократизирал разпределения консенсус, позволявайки на по-широк кръг от разработчици и организации да изграждат системи с висока наличност и отказоустойчивост, без да се поддават на тайнствените сложности на предишни подходи.

От оркестриране на контейнерни клъстери с Kubernetes (чрез etcd) до предоставяне на устойчиво съхранение на данни за глобални бази данни като CockroachDB, Raft е тих работен кон, който гарантира, че нашият дигитален свят остава консистентен и работещ. Имплементирането на Raft не е тривиална задача, но яснотата на неговата спецификация и богатството на заобикалящата го екосистема го правят възнаграждаващо начинание за тези, които са ангажирани с изграждането на следващото поколение здрава, мащабируема инфраструктура.

Практически съвети за разработчици и архитекти:

• Приоритизирайте разбирането: Преди да опитате имплементация, инвестирайте време в щателно разбиране на всяко правило и преход на състоянието на Raft. Оригиналният документ и визуалните обяснения са безценни ресурси.
• Използвайте съществуващи библиотеки: За повечето приложения обмислете използването на добре проверени съществуващи имплементации на Raft (напр. от etcd, библиотеката Raft на HashiCorp), вместо да изграждате от нулата, освен ако вашите изисквания не са силно специализирани или провеждате академично изследване.
• Строгото тестване не подлежи на договаряне: Инжектиране на грешки, тестване, базирано на свойства, и обширна симулация на сценарии на отказ са от първостепенно значение за всяка система за разпределен консенсус. Никога не приемайте, че „работи“, без щателно да го счупите.
• Проектирайте за глобално закъснение: Когато внедрявате глобално, внимателно обмислете разположението на вашия кворум, мрежовата топология и стратегиите за четене от клиенти, за да оптимизирате както консистентността, така и производителността в различните географски региони.
• Персистентност и трайност: Уверете се, че вашият основен слой за съхранение е здрав и че fsync или еквивалентни операции се използват правилно, за да се предотврати загуба на данни при сценарии на срив.

Докато разпределените системи продължават да се развиват, принципите, въплътени от Raft — яснота, здравина и отказоустойчивост — ще останат крайъгълни камъни на надеждното софтуерно инженерство. Като овладеете Raft, вие се въоръжавате с мощен инструмент за изграждане на устойчиви, глобално мащабируеми приложения, които могат да устоят на неизбежния хаос на разпределените изчисления.