Kiedy używać Paxos (prawdziwe praktyczne przypadki użycia)?

Zakładamy, że wszystkie serwery są ze sobą zsynchronizowane (tzn. mają ten sam stan), więc gdy serwer musi wybrać następną kartę, każdy z serwerów wybierze dokładnie tę samą kartę (zakładając, że kod jest deterministyczny).

Jednak stan twoich serwerów zależy również od działań użytkownika. Na przykład, jeśli użytkownik zdecydował się podnieść o 50$ - Twój serwer musi gdzieś przechowywać te informacje. Teraz Załóżmy, że twój serwer odpowiedział" ok " do web-client (zakładam, że web-based gry w pokera), a potem Serwer się rozbił. Twoje inne serwery mogą nie mieć informacji dotyczących podbicia 50$, a Twój system będzie niespójny (w tym sensie, że klient uważa, że podbicie 50$ zostało dokonane, podczas gdy ocalałe serwery są o tym nieświadome).

Zauważ, że większość tu nie pomoże, ponieważ dane są utracone. Co więcej, Załóżmy, że zamiast głównego serwera upaść, główny serwer plus inny dostał dane 50 $ podnieść. W tym przypadku korzystanie z większości może nawet gorzej: jeśli otrzymasz odpowiedź z dwóch serwerów z danymi, pomyślisz, że podwyżka 50 $ została wykonana. Ale jeśli jeden z nich zawiedzie, wtedy nie będziesz miał większości, a pomyślisz, że podwyżka nie została wykonana.

Ogólnie rzecz biorąc, Paxos może być używany do replikacji maszyny stanowej, w sposób odporny na błędy. Gdzie "maszyna stanowa" może być traktowana jako algorytm, który ma pewien stan początkowy i postępuje on deterministycznie w zależności od wiadomości otrzymywanych z zewnątrz (np. web-client).

Dokładniej, Paxos należy traktować jako rozproszony dziennik, więcej na ten temat można przeczytać tutaj: zrozumienie Paxos-Część 1

Aktualizacja 2018: Mysql High Availability wykorzystuje paxos: https://mysqlhighavailability.com/the-king-is-dead-long-live-the-king-our-homegrown-paxos-based-consensus/

Przykład ze świata rzeczywistego:

Cassandra używa Paxos , aby zapewnić, że klienci podłączeni do różnych węzłów klastra mogą bezpiecznie wykonywać operacje zapisu, dodając "jeśli nie istnieje" do operacji zapisu. Cassandra nie ma węzła głównego, więc dwie sprzeczne operacje mogą być wykonywane jednocześnie w wiele węzłów. Przy użyciu składni if-not-exists algorytm paxos jest używany do wykonywania operacji porządkowych między maszynami, aby zapewnić, że tylko jeden się powiedzie. To może być następnie wykorzystane przez klientów do przechowywania autorytatywnych danych z dzierżawy wygaśnięcia . Tak długo, jak większość węzłów Cassandry będzie działać. Więc jeśli zdefiniujesz współczynnik replikacji Twojej przestrzeni kluczy na 3, to 1 węzeł może zawieść, z 5 potem 2 może zawieść, itd.

Dla zapisów normalnych pozwala na wielokrotne zapisywanie sprzecznych akceptowane przez różne węzły, które mogą być chwilowo niezdolne do komunikacji. W takim przypadku nie używa Paxos, więc może stracić dane , gdy dwa zapisy występują w tym samym czasie dla tego samego klucza. Istnieją specjalne struktury danych wbudowane w Cassandrę, które nie tracą danych, które są tylko insert-only.

Poker i Paxos:

Jak inne odpowiedzi uwaga poker jest turowy i ma zasady. Jeśli pozwolisz jednemu mistrzowi i wielu replikom, mistrz rozstrzygnie następną akcję. Powiedzmy, że najpierw użytkownik kliknie przycisk" Sprawdź", a następnie zmienia zdanie i kliknie "fold". Są to sprzeczne polecenia tylko pierwsze powinny być akceptowane. Przeglądarka nie powinna pozwolić im nacisnąć drugi przycisk, wyłączy go po naciśnięciu pierwszego przycisku. Ponieważ pieniądze są zaangażowane główny serwer powinien również egzekwować zasady i zezwalać tylko na jedną akcję na gracza na turę. Problem pojawia się, gdy master zawiesza się podczas gry. Która replika może zostać mistrzem i jak wyegzekwować, że tylko jeden replika staje się mistrzem?

Jednym ze sposobów radzenia sobie z wyborem nowego Mastera jest korzystanie z zewnętrznej usługi strong konsekwentnie. Możemy użyć Cassandry, aby utworzyć dzierżawę dla węzła głównego. Repliki mogą mieć czas na mistrza i próbować wziąć dzierżawę. Ponieważ Cassandra używa Paxos, jest odporna na błędy; możesz nadal odczytywać lub aktualizować dzierżawę, nawet jeśli węzły Cassandra ulegną awarii.

W powyższym przykładzie mistrz pokera i repliki są ostatecznie spójne. Mistrz może wysłać bicie serca, więc repliki wiedzą, że są nadal połączone z mistrzem. Jest to szybkie, ponieważ wiadomości płyną w jednym kierunku. Gdy mistrz się rozbija, w replikach mogą występować warunki rasowe starając się być mistrzem. Korzystanie z Paxos w tym momencie daje silne konsekwentnie na wynik, który węzeł jest teraz master. Wymaga to dodatkowych komunikatów między węzłami, aby zapewnić konsensus pojedynczego mistrza.

Paxos jest używany do replikacji bazujących na sieci WAN repozytoriów Subversion i wysokiej dostępności kodu Hadoop przez firmę, dla której pracuję (WANdisco plc.)

W przypadku, gdy opisujesz, masz rację, Paxos nie jest naprawdę konieczne: jeden organ centralny może wygenerować permutację dla talii i rozpowszechnić ją wśród wszystkich na początku rozdania. W rzeczywistości, do gry w pokera w ogóle, gdzie jest ścisła kolejność kolei i jednego aktywnego gracza, jak w pokera, nie widzę sensownej sytuacji, w której może trzeba użyć Paxos, z wyjątkiem być może wybrać organ centralny, który tasuje pokłady.

Lepszym przykładem może być gra z jednoczesnymi ruchami, takimi jak Jeopardy. Paxos w tej sytuacji pozwoliłby wszystkim serwerom decydować razem, w jakiej kolejności miała miejsce seria ściśle określonych zdarzeń (takich jak brzęczyki), tak aby wszystkie serwery doszły do tego samego wniosku.