PL 
EnglishDomyślny
Українська💻 Konsensus rozproszony
Algorytm konsensusu Raft, twierdzenie CAP i odporność na błędy bizantyjskie w systemach rozproszonych.
O symulacji
Ta symulacja pokazuje, jak klaster pięciu węzłów osiąga porozumienie za pomocą algorytmu konsensusu Raft. Każdy węzeł uruchamia losowy licznik czasu wyborów, głosuje na kandydata, a gdy zbierze kworum trzech z pięciu głosów, staje się liderem na dany okres kadencji (term). Lider replikuje następnie polecenia klienta jako wpisy dziennika za pomocą wiadomości heartbeat i AppendEntries, dzięki czemu cały klaster pozostaje spójny nawet wtedy, gdy pojedyncze węzły ulegają awarii lub sieć się dzieli.
🔬 Co pokazuje
Pięciowęzłowy klaster Raft animowany na płótnie canvas. Węzły przechodzą między rolami followera, kandydata i lidera; liczniki czasu wyborów są rysowane jako wypełniające się łuki, a kolorowe kropki reprezentują wiadomości RequestVote, Heartbeat i AppendEntries przesyłane między węzłami. Wybory wymagają większościowego kworum trzech głosów, a wpisy dziennika zatwierdzane są dopiero po potwierdzeniu przez większość.
🎮 Jak korzystać
Wybierz algorytm (Raft, Paxos lub BFT) za pomocą przycisków u góry. Użyj „Append Log Entry”, aby lider zreplikował polecenie, „Network Partition”, aby podzielić klaster na [N1,N2,N3] i [N4,N5], oraz „Heal Partition”, aby go ponownie połączyć. Każdy węzeł na liście ma przycisk Kill lub Revive, a „Reset Cluster” restartuje wybory od nowa.
💡 Czy wiesz, że?
Raft został zaprojektowany w 2013 roku przez Diego Ongaro i Johna Ousterhouta specjalnie po to, by był bardziej zrozumiały niż Paxos, przy zachowaniu takich samych gwarancji odporności na awarie. Napędza systemy produkcyjne, takie jak etcd, Consul i CockroachDB.
Najczęściej zadawane pytania
Czym jest rozproszony konsensus?
Rozproszony konsensus to problem doprowadzenia wielu niezależnych maszyn do zgody co do jednej wspólnej wartości lub uporządkowanej sekwencji poleceń, nawet gdy niektóre maszyny ulegają awarii lub wiadomości giną. Jest to podstawa odpornych na awarie baz danych, magazynów konfiguracji i replikowanych maszyn stanowych, zapewniająca, że każdy sprawny węzeł kończy z tym samym zatwierdzonym dziennikiem.
Jak działa tutaj algorytm Raft?
Każdy follower uruchamia losowy limit czasu wyborów. Gdy upłynie bez wiadomości od lidera, węzeł staje się kandydatem, zwiększa swój numer kadencji i prosi o głosy. Jeśli zbierze kworum trzech z pięciu głosów, zostaje liderem i wysyła okresowe wiadomości heartbeat. Lider replikuje nowe wpisy do followerów i oznacza je jako zatwierdzone, gdy potwierdzi je większość.
Co robią panele sterowania i statystyk?
Przyciski algorytmu przełączają między Raft, Paxos i BFT oraz resetują klaster. Append Log Entry prosi obecnego lidera o zreplikowanie polecenia; Network Partition izoluje węzły N4 i N5; a przyciski Kill lub Revive powodują awarię lub przywracają poszczególne węzły. Panel statystyk pokazuje aktualnego lidera, bieżącą kadencję, liczbę zatwierdzonych wpisów, liczbę żywych węzłów, procent dostępności oraz wymagane kworum.
Dlaczego partycja sieci wymusza nowe wybory?
Raft gwarantuje bezpieczeństwo, wymagając większościowego kworum. Gdy klaster dzieli się na [N1,N2,N3] i [N4,N5], tylko strona posiadająca trzy lub więcej węzłów może wybrać lidera i zatwierdzać wpisy. Jeśli dotychczasowy lider znajdzie się w mniejszościowej partycji dwóch węzłów, nie może już osiągnąć kworum, więc strona większościowa wybiera nowego lidera na wyższą kadencję, podczas gdy strona mniejszościowa zamiera.
Czy to wierny model prawdziwego klastra Raft?
Oddaje wiernie kluczowe mechanizmy: kadencje, losowe limity czasu wyborów, głosowanie większościowe, heartbeaty lidera, replikację dziennika i zatwierdzanie oparte na kworum. Dla przejrzystości upraszcza pewne szczegóły, takie jak pełne sprawdzanie spójności dopasowania dziennika, trwałe przechowywanie danych i dokładną logikę ponawiania RPC, a przyciski Paxos i BFT są wariantami poglądowymi, a nie osobnymi pełnymi implementacjami.
O symulacji Rozproszony konsensus — Raft i tolerancja błędów bizantyjskich
Ta symulacja modeluje pięciowęzłowy klaster rozproszony działający na algorytmie konsensusu Raft, który rozwiązuje fundamentalny problem doprowadzenia niezależnych maszyn do zgody co do wspólnego, uporządkowanego dziennika poleceń, nawet gdy węzły ulegają awarii lub sieci się dzielą. Możesz na żywo obserwować przebieg wyborów lidera, gdy węzły wymieniają wiadomości RequestVote i Heartbeat, obserwować, jak kworum (większość trzech z pięciu węzłów) warunkuje każde zatwierdzenie, oraz eksperymentować z awariami węzłów i podziałami sieci, by zobaczyć, jak klaster się odzyskuje. Przełączenie na tryb Paxos lub BFT ilustruje alternatywne podejścia do tego samego podstawowego wyzwania.
Algorytmy rozproszonego konsensusu stanowią podstawę niemal każdego dużego, niezawodnego systemu budowanego dziś — od Google Spanner i Amazon DynamoDB po projekty open source, takie jak etcd (na którym opiera się Kubernetes) i Apache Zookeeper — co czyni ten temat jednym z najbardziej praktycznie doniosłych w informatyce.
Najczęściej zadawane pytania
Na czym polega problem konsensusu w systemach rozproszonych?
Problem konsensusu dotyczy tego, jak zbiór niezależnych procesów, z których każdy ma własny stan i podlega awariom, może niezawodnie uzgodnić jedną wartość lub sekwencję decyzji. Poprawny protokół konsensusu musi jednocześnie spełniać trzy własności: bezpieczeństwo (wszystkie węzły, które decydują, muszą zdecydować to samo), żywotność (system musi w końcu robić postępy) oraz odporność na awarie (protokół musi działać mimo ograniczonej liczby awarii węzłów lub utraty wiadomości).
Jak używać tej symulacji, by zobaczyć wybory lidera?
Po wczytaniu strony wszystkie pięć węzłów zaczyna jako followerzy z losowymi licznikami czasu wyborów pokazanymi jako wypełniające się żółte łuki wokół każdego okręgu. Pierwszy węzeł, którego licznik upłynie, staje się kandydatem, wysyła wiadomości RequestVote (żółte kropki), a jeśli zbierze trzy głosy, zmienia kolor na niebieski jako nowy lider. Możesz w każdej chwili wymusić nowe wybory, klikając Kill przy obecnym liderze i obserwując, jak wśród pozostałych węzłów automatycznie rozpoczynają się nowe wybory.
Co dzieje się z wpisami dziennika podczas partycji sieci?
Kliknięcie Network Partition izoluje węzły N4 i N5 od N1, N2 i N3. Ponieważ Raft wymaga kworum trzech węzłów do zatwierdzenia jakiegokolwiek wpisu, strona mniejszościowa (N4, N5) jest zamrożona i nie może wybrać lidera ani zatwierdzać nowych poleceń. Strona większościowa (N1, N2, N3) może nadal normalnie wybierać lidera i dodawać wpisy. Po kliknięciu Heal Partition izolowane węzły dołączają ponownie, odkrywają lidera o wyższej kadencji i automatycznie synchronizują swoje dzienniki.
Czym jest kworum i dlaczego wynosi dokładnie trzy z pięciu?
Kworum to minimalna liczba węzłów, które muszą uczestniczyć w decyzji, aby zagwarantować, że dowolne dwa kworum zachodzą na siebie przynajmniej jednym węzłem. Dla klastra N węzłów kworum Raft wynosi floor(N/2) + 1. Dla pięciu węzłów daje to floor(5/2) + 1 = 3. Ta własność zachodzenia na siebie gwarantuje, że dowolne dwie większości mają wspólny węzeł, który widział najnowszy zatwierdzony stan, co uniemożliwia dwóm sprzecznym liderom niezależne zatwierdzanie kolidujących wpisów i naruszanie spójności.
Czym Raft różni się od Paxos?
Paxos, opisany przez Lesliego Lamporta w jego pracy z 1989 roku „The Part-Time Parliament” (opublikowanej w 1998 roku), jest często uważany za kanoniczny algorytm konsensusu, ale jest notorycznie trudny do pełnego zrozumienia i zaimplementowania, ponieważ wiele praktycznych szczegółów pozostawiono niedopowiedzianych. Raft, zaprojektowany przez Diego Ongaro i Johna Ousterhouta i opublikowany w 2014 roku, rozkłada problem na trzy w dużej mierze niezależne podproblemy (wybory lidera, replikację dziennika i bezpieczeństwo) oraz wykorzystuje pojedynczego silnego lidera, aby uprościć rozumowanie. Badania empiryczne pokazały, że studenci i inżynierowie przyswajają Raft znacznie szybciej niż Paxos, mimo że oba zapewniają równoważne gwarancje odporności na awarie.
Czym jest tolerancja błędów bizantyjskich i kiedy ma znaczenie?
Błędy bizantyjskie to najpoważniejsza klasa awarii: węzeł nie tylko ulega awarii i milknie, ale aktywnie wysyła błędne, niespójne lub złośliwe wiadomości do różnych partnerów. Protokół odporny na błędy bizantyjskie (BFT), taki jak PBFT lub wariant HotStuff używany w wielu blockchainach, może tolerować do floor((N-1)/3) węzłów bizantyjskich, wymagając co najmniej 3f+1 węzłów, by obsłużyć f zdrajców. Jest to droższe niż odporność Raft na awarie typu crash (która wymaga tylko 2f+1 węzłów dla f awarii), ale jest niezbędne w otwartych, wrogich środowiskach, takich jak sieci blockchain, gdzie uczestnikom nie można ufać.
Kto wynalazł Raft i kiedy został opublikowany?
Raft został stworzony przez Diego Ongaro w ramach jego rozprawy doktorskiej na Uniwersytecie Stanforda pod kierunkiem promotora Johna Ousterhouta. Fundamentalna publikacja, „In Search of an Understandable Consensus Algorithm”, została zaprezentowana na USENIX ATC w czerwcu 2014 roku i zdobyła nagrodę Best Paper. Deklarowany cel Ongaro był wyraźny: zaprojektować algorytm konsensusu, którego głównym atutem jest zrozumiałość, ułatwiającą praktykom tworzenie poprawnych implementacji w porównaniu z gęstym formalizmem Paxos.
Jakie systemy w świecie rzeczywistym korzystają z rozproszonego konsensusu?
Raft jest używany w etcd (magazynie klucz-wartość będącym podstawą stanu klastra Kubernetes), HashiCorp Consul (siatka usług i konfiguracja), CockroachDB i TiKV (rozproszony SQL) oraz InfluxDB. Paxos (lub protokoły wywodzące się z Paxos) leży u podstaw Google Chubby, Google Spanner i Apache Zookeeper. Warianty konsensusu bizantyjskiego napędzają silniki konsensusu blockchain, takie jak Tendermint (Cosmos), HotStuff (Libra/Diem) oraz permisjonowane rejestry oparte na PBFT. Amazon DynamoDB wykorzystuje podejście zbliżone do Raft w swoich wewnętrznych grupach replikacji.
Czy klaster Raft może kiedykolwiek utracić zatwierdzone dane?
Powszechnym błędnym przekonaniem jest, że zabijanie węzłów może spowodować utratę już zatwierdzonych wpisów. W Raft nie może się to zdarzyć, dopóki przetrwa kworum węzłów: wpis jest oznaczany jako zatwierdzony dopiero po otrzymaniu przez lidera potwierdzenia od większości, a własność bezpieczeństwa wyborów Raft gwarantuje, że każdy przyszły lider musi mieć w swoim własnym kworum przynajmniej jeden węzeł z tej większości, więc zawsze będzie posiadał zatwierdzony wpis. Dane mogą zostać trwale utracone tylko wtedy, gdy jednocześnie zawiedzie tak wiele węzłów, że nie przetrwa żadne kworum — dla pięciu węzłów oznacza to utratę trzech lub więcej węzłów naraz.
Jak twierdzenie CAP odnosi się do algorytmów konsensusu?
Twierdzenie CAP Erica Brewera (sformalizowane przez Gilberta i Lyncha w 2002 roku) mówi, że system rozproszony nie może jednocześnie gwarantować spójności (Consistency), dostępności (Availability) i odporności na partycje (Partition tolerance) — podczas partycji sieci trzeba wybrać jedno z dwóch. Raft i Paxos wybierają CP — podczas partycji strona mniejszościowa staje się niedostępna zamiast ryzykować podanie nieaktualnych lub niespójnych danych. Magazyny o spójności ostatecznej, jak Apache Cassandra, wybierają AP, pozostając dostępne podczas partycji, ale potencjalnie zwracając nieaktualne odczyty. Ten symulator bezpośrednio demonstruje wybór CP: izolowana partycja N4/N5 przestaje obsługiwać żądania, zamiast rozejść się z większością.
Jakie są obecne granice badań nad rozproszonym konsensusem?
Aktywne badania koncentrują się na kilku kierunkach: konsensusie geo-rozproszonym o zmniejszonym opóźnieniu z wykorzystaniem Flexible Paxos i wariantów zoptymalizowanych pod sieci WAN; protokołach bezliderowych, takich jak EPaxos i Atlas, pozwalających dowolnemu węzłowi zatwierdzać niekolidujące polecenia równolegle, eliminując wąskie gardło lidera; protokołach rekonfiguracji, które bezpiecznie dodają lub usuwają węzły bez zatrzymywania systemu; oraz integracji ze sprzętowymi zaufanymi środowiskami wykonawczymi (Intel TDX, AMD SEV) w celu obniżenia kosztu tolerancji błędów bizantyjskich. W obszarze blockchain protokoły BFT typu proof-of-stake, jak Gasper w Ethereum, wciąż ewoluują w kierunku wyższej przepustowości i formalnej weryfikowalności.