Proponuję zapoznać się z transkrypcją wykładu „Hadoop. ZooKeeper” z cyklu „Metody rozproszonego przetwarzania dużych wolumenów danych w Hadoop”
Czym jest ZooKeeper i jego miejsce w ekosystemie Hadoop. Nieprawdy o przetwarzaniu rozproszonym. Schemat standardowego systemu rozproszonego. Trudność w koordynacji systemów rozproszonych. Typowe problemy z koordynacją. Zasady stojące za projektem ZooKeeper. Model danych ZooKeepera. flagi znode. Sesje. API klienta. Elementy podstawowe (konfiguracja, członkostwo w grupie, proste blokady, wybór lidera, blokowanie bez efektu stada). Architektura ZooKeepera. Zookeeper DB. ZAB. Osoba zajmująca się prośbami.
Dzisiaj porozmawiamy o ZooKeeperze. Ta rzecz jest bardzo przydatna. Jak każdy produkt Apache Hadoop posiada logo. Przedstawia mężczyznę.
Wcześniej rozmawialiśmy głównie o tym, jak można tam przetwarzać dane, jak je przechowywać, czyli jak je jakoś wykorzystać i jakoś z nimi pracować. A dzisiaj chciałbym trochę porozmawiać o budowaniu aplikacji rozproszonych. A ZooKeeper jest jedną z tych rzeczy, które pozwalają uprościć tę sprawę. Jest to rodzaj usługi, która ma na celu pewnego rodzaju koordynację interakcji procesów w systemach rozproszonych, w aplikacjach rozproszonych.
Zapotrzebowanie na tego typu aplikacje z dnia na dzień staje się coraz większe i o to właśnie chodzi w naszym kursie. Z jednej strony MapReduce i ten gotowy framework pozwala wyrównać tę złożoność i uwolnić programistę od pisania prymitywów, takich jak interakcja i koordynacja procesów. Ale z drugiej strony nikt nie gwarantuje, że i tak nie będzie trzeba tego robić. MapReduce lub inne gotowe frameworki nie zawsze całkowicie zastępują niektóre przypadki, których nie można zaimplementować przy ich użyciu. Włączając samo MapReduce i kilka innych projektów Apache; w rzeczywistości są to również aplikacje rozproszone. Aby ułatwić pisanie, napisali ZooKeeper.
Podobnie jak wszystkie aplikacje związane z Hadoop, został opracowany przez Yahoo! Jest to teraz także oficjalna aplikacja Apache. Nie jest tak aktywnie rozwijany jak HBase. Jeśli wejdziesz do JIRA HBase, to każdego dnia pojawia się garść raportów o błędach, garść propozycji optymalizacji czegoś, czyli życie w projekcie ciągle toczy się. A ZooKeeper z jednej strony jest produktem stosunkowo prostym, z drugiej strony gwarantuje to jego niezawodność. Jest też dość łatwy w użyciu, dlatego stał się standardem w aplikacjach w ramach ekosystemu Hadoop. Pomyślałem więc, że warto go przejrzeć, aby zrozumieć, jak działa i jak z niego korzystać.
To jest zdjęcie z jakiegoś wykładu, który odbyliśmy. Można powiedzieć, że jest ortogonalny do wszystkiego, co rozważaliśmy do tej pory. I wszystko, co jest tu wskazane, w takim czy innym stopniu współpracuje z ZooKeeperem, czyli jest to usługa korzystająca ze wszystkich tych produktów. Ani HDFS, ani MapReduce nie piszą własnych podobnych usług, które byłyby specjalnie dla nich odpowiednie. W związku z tym używany jest ZooKeeper. A to upraszcza rozwój i niektóre rzeczy związane z błędami.
Skąd to wszystko się bierze? Wydawać by się mogło, że uruchomiliśmy równolegle dwie aplikacje na różnych komputerach, połączyliśmy je sznurkiem lub siatką i wszystko działa. Problem polega jednak na tym, że sieć jest zawodna i jeśli podsłuchasz ruch lub przyjrzysz się na niskim poziomie temu, co się tam dzieje, jak klienci wchodzą w interakcje w sieci, często możesz zobaczyć, że niektóre pakiety są tracone lub ponownie wysyłane. Nie bez powodu wynaleziono protokoły TCP, które pozwalają nawiązać określoną sesję i zagwarantować dostarczenie wiadomości. Ale w każdym razie nawet TCP nie zawsze może cię uratować. Wszystko ma swój limit czasu. Sieć może po prostu na jakiś czas przestać działać. Może po prostu mrugnąć. A to wszystko prowadzi do tego, że nie można polegać na niezawodności Sieci. Na tym polega główna różnica w stosunku do pisania aplikacji równoległych, które działają na jednym komputerze lub na jednym superkomputerze, gdzie nie ma sieci, a w pamięci znajduje się bardziej niezawodna magistrala wymiany danych. I to jest zasadnicza różnica.
Między innymi podczas korzystania z sieci zawsze występuje pewne opóźnienie. Na dysku też to ma, ale w sieci jest tego więcej. Opóźnienie to pewien czas opóźnienia, który może być mały lub dość znaczący.
Topologia sieci ulega zmianie. Czym jest topologia - to rozmieszczenie naszego sprzętu sieciowego. Są centra danych, stoją tam stojaki, są świece. Wszystko to można ponownie podłączyć, przenieść itp. To wszystko również należy wziąć pod uwagę. Zmieniają się nazwy IP, zmienia się routing, przez który przechodzi nasz ruch. To również należy wziąć pod uwagę.
Sieć może zmienić się także pod względem sprzętowym. Z praktyki mogę powiedzieć, że nasi inżynierowie sieciowi bardzo lubią okresowo aktualizować coś na temat świec. Nagle wyszło nowe oprogramowanie i nie byli szczególnie zainteresowani jakimś klastrem Hadoop. Mają swoją pracę. Dla nich najważniejsze jest to, że Sieć działa. W związku z tym chcą tam coś ponownie przesłać, wykonać flashowanie na swoim sprzęcie, a sprzęt również zmienia się okresowo. Wszystko to trzeba w jakiś sposób wziąć pod uwagę. Wszystko to wpływa na naszą rozproszoną aplikację.
Zwykle osoby, które z jakiegoś powodu rozpoczynają pracę z dużą ilością danych, uważają, że Internet jest nieograniczony. Jeśli znajduje się tam plik o wielkości kilku terabajtów, możesz zabrać go na swój serwer lub komputer i otworzyć za pomocą jak i oglądaj. Wkradł się kolejny błąd Vim spójrz na logi. Nigdy tego nie rób, bo to złe. Ponieważ Vim próbuje wszystko buforować, ładuje wszystko do pamięci, zwłaszcza gdy zaczynamy przeglądać ten dziennik i czegoś szukać. To rzeczy, o których się zapomina, ale warto je rozważyć.
Łatwiej jest napisać jeden program, który działa na jednym komputerze z jednym procesorem.
Kiedy nasz system się rozrośnie, chcemy to wszystko zrównoleglić i to nie tylko na komputerze, ale także na klastrze. Powstaje pytanie: jak skoordynować tę sprawę? Nasze aplikacje może nawet nie współdziałają ze sobą, ale uruchomiliśmy kilka procesów równolegle na kilku serwerach. I jak monitorować, czy wszystko idzie im dobrze? Na przykład wysyłają coś przez Internet. Muszą gdzieś o swoim stanie napisać, na przykład w jakiejś bazie danych lub logu, potem zagregować ten log i gdzieś go przeanalizować. Poza tym trzeba wziąć pod uwagę, że proces działał i działał, nagle pojawił się w nim jakiś błąd lub uległ awarii, to jak szybko się o tym dowiemy?
Oczywiste jest, że wszystko to można szybko monitorować. To też jest dobre, ale monitorowanie to ograniczona rzecz, która pozwala monitorować niektóre rzeczy na najwyższym poziomie.
Kiedy chcemy, aby nasze procesy zaczęły ze sobą współdziałać, np. przesyłać sobie jakieś dane, wtedy pojawia się również pytanie – jak to się stanie? Czy nastąpi jakiś wyścig, czy nadpiszą się nawzajem, czy dane dotrą poprawnie, czy coś zostanie utracone po drodze? Musimy opracować jakiś protokół itp.
Koordynacja tych wszystkich procesów nie jest rzeczą trywialną. I zmusza programistę do zejścia na jeszcze niższy poziom i napisania systemów albo od zera, albo nie całkiem od zera, ale to nie jest takie proste.
Jeśli wymyślisz algorytm kryptograficzny lub nawet go zaimplementujesz, to natychmiast go wyrzuć, bo najprawdopodobniej nie zadziała dla Ciebie. Najprawdopodobniej będzie zawierał mnóstwo błędów, o których zapomniałeś wspomnieć. Nigdy nie używaj go do niczego poważnego, ponieważ najprawdopodobniej będzie niestabilny. Ponieważ wszystkie istniejące algorytmy były testowane przez czas przez bardzo długi czas. Jest to zbugowane przez społeczność. To jest osobny temat. I tutaj jest tak samo. Jeśli nie da się samodzielnie wdrożyć jakiejś synchronizacji procesów, to lepiej tego nie robić, bo jest to dość skomplikowane i prowadzi na krętą ścieżkę ciągłego poszukiwania błędów.
Dziś mówimy o ZooKeeperze. Z jednej strony jest to framework, z drugiej zaś usługa, która ułatwia życie programiście i maksymalnie upraszcza realizację logiki oraz koordynację naszych procesów.
Przypomnijmy sobie, jak mógłby wyglądać standardowy system rozproszony. Właśnie o tym rozmawialiśmy - HDFS, HBase. Istnieje proces główny, który zarządza procesami roboczymi i podrzędnymi. Odpowiada za koordynację i dystrybucję zadań, ponowne uruchamianie pracowników, uruchamianie nowych i dystrybucję obciążenia.
Bardziej zaawansowaną rzeczą jest Usługa Koordynacji, to znaczy przeniesienie samego zadania koordynacyjnego do osobnego procesu, plus równoległe uruchomienie jakiegoś rodzaju kopii zapasowej lub stanu gotowości Mastera, ponieważ Master może zawieść. A jeśli Mistrz upadnie, nasz system nie będzie działał. Uruchamiamy kopię zapasową. Niektórzy twierdzą, że należy zreplikować moduł główny w celu wykonania kopii zapasowej. Można to również powierzyć Służbie Koordynacyjnej. Ale na tym schemacie sam Mistrz jest odpowiedzialny za koordynację pracowników; tutaj usługa koordynuje działania związane z replikacją danych.
Bardziej zaawansowaną opcją jest sytuacja, gdy całą koordynacją zajmuje się nasz serwis, jak to zwykle ma miejsce. Bierze na siebie odpowiedzialność za upewnienie się, że wszystko działa. A jeśli coś nie działa, dowiadujemy się o tym i staramy się obejść tę sytuację. W każdym razie pozostaje nam Mistrz, który w jakiś sposób wchodzi w interakcję z niewolnikami i może przesyłać dane, informacje, wiadomości itp. za pośrednictwem jakiejś usługi.
Istnieje jeszcze bardziej zaawansowany schemat, gdy nie mamy Mastera, wszystkie węzły są Master Slave, różniące się zachowaniem. Jednak nadal muszą ze sobą współdziałać, zatem pozostaje jeszcze pewna służba, która będzie koordynować te działania. Prawdopodobnie Cassandra, która działa na tej zasadzie, pasuje do tego schematu.
Trudno powiedzieć, który z tych schematów sprawdza się lepiej. Każdy ma swoje zalety i wady.
A pewnych rzeczy z Mistrzem nie trzeba się bać, bo jak pokazuje praktyka, nie jest on już tak podatny na ciągłą służbę. Najważniejsze jest, aby wybrać odpowiednie rozwiązanie do hostowania tej usługi na oddzielnym, wydajnym węźle, aby miała wystarczające zasoby, aby w miarę możliwości użytkownicy nie mieli tam dostępu, aby przypadkowo nie zabili tego procesu. Ale jednocześnie w takim schemacie znacznie łatwiej jest zarządzać pracownikami z procesu Master, czyli schemat ten jest prostszy z punktu widzenia wdrożenia.
A ten schemat (powyżej) jest prawdopodobnie bardziej złożony, ale bardziej niezawodny.
Głównym problemem są częściowe awarie. Przykładowo, gdy wysyłamy wiadomość przez Sieć, następuje jakiś wypadek i osoba, która wysłała wiadomość, nie będzie wiedziała, czy jego wiadomość została odebrana i co wydarzyło się po stronie odbiorcy, nie będzie wiedziała, czy wiadomość została poprawnie przetworzona , czyli nie otrzyma żadnego potwierdzenia.
W związku z tym musimy przepracować tę sytuację. A najprościej jest wysłać tę wiadomość ponownie i poczekać, aż otrzymamy odpowiedź. Nie jest w tym wypadku brane pod uwagę to, czy zmienił się stan odbiornika. Możemy wysłać wiadomość i dwukrotnie dodać te same dane.
ZooKeeper oferuje sposoby radzenia sobie z takimi odmowami, co również ułatwia nam życie.
Jak wspomniano nieco wcześniej, przypomina to pisanie programów wielowątkowych, ale główna różnica polega na tym, że w aplikacjach rozproszonych, które budujemy na różnych maszynach, jedyną metodą komunikacji jest Sieć. Zasadniczo jest to architektura typu „nic wspólnego”. Każdy proces lub usługa działająca na jednej maszynie ma własną pamięć, własny dysk, własny procesor, którymi nie jest nikomu udostępniany.
Jeśli napiszemy program wielowątkowy na jednym komputerze, wówczas do wymiany danych będziemy mogli wykorzystać pamięć współdzieloną. Mamy tam przełącznik kontekstu, procesy mogą się przełączać. Ma to wpływ na wydajność. Z jednej strony w programie nie ma czegoś takiego na klastrze, ale są problemy z Siecią.
W związku z tym główne problemy pojawiające się podczas pisania systemów rozproszonych to konfiguracja. Piszemy jakąś aplikację. Jeśli jest to proste, to kodujemy na stałe w kodzie wszelkiego rodzaju liczby, ale jest to niewygodne, ponieważ jeśli zdecydujemy, że zamiast limitu czasu wynoszącego pół sekundy chcemy limitu czasu wynoszącego jedną sekundę, wówczas musimy ponownie skompilować aplikację i rozłóż wszystko jeszcze raz. Co innego, gdy jest na jednej maszynie, kiedy można go po prostu zrestartować, ale gdy mamy wiele maszyn, musimy ciągle wszystko kopiować. Musimy starać się, aby aplikacja była konfigurowalna.
Mówimy tutaj o konfiguracji statycznej procesów systemowych. To nie do końca, może z punktu widzenia systemu operacyjnego może to być konfiguracja statyczna dla naszych procesów, czyli jest to konfiguracja, której nie da się po prostu pobrać i zaktualizować.
Istnieje również konfiguracja dynamiczna. Są to parametry, które chcemy na bieżąco zmieniać, aby zostały tam wyłapane.
Jaki jest tutaj problem? Zaktualizowaliśmy konfigurację, wdrożyliśmy ją i co z tego? Problem może polegać na tym, że z jednej strony wdrożyliśmy konfigurację, ale zapomnieliśmy o nowości, konfiguracja pozostała. Po drugie, w trakcie wdrażania konfiguracja została zaktualizowana w niektórych miejscach, ale nie w innych. A niektóre procesy naszej aplikacji działające na jednym komputerze zostały zrestartowane z nową konfiguracją, a gdzieś ze starą. Może to spowodować, że nasza rozproszona aplikacja będzie niespójna z punktu widzenia konfiguracji. Ten problem jest powszechny. W przypadku konfiguracji dynamicznej jest to bardziej istotne, ponieważ oznacza, że można je zmieniać w locie.
Kolejnym problemem jest przynależność do grupy. Zawsze mamy jakąś grupę pracowników i zawsze chcemy wiedzieć, który z nich żyje, a który nie. Jeśli jest Mistrz, to musi zrozumieć, którzy pracownicy mogą zostać przekierowani do klientów, aby wykonywali obliczenia lub pracowali z danymi, a którzy nie. Ciągle pojawiającym się problemem jest to, że musimy wiedzieć, kto pracuje w naszym klastrze.
Innym typowym problemem są wybory liderów, kiedy chcemy wiedzieć, kto rządzi. Jednym z przykładów jest replikacja, gdy mamy proces, który otrzymuje operacje zapisu, a następnie replikuje je wśród innych procesów. On będzie przywódcą, wszyscy inni będą mu posłuszni i pójdą za nim. Należy tak dobrać proces, aby był dla wszystkich jednoznaczny i nie okazało się, że wybiera się dwóch liderów.
Dostęp jest również wzajemnie wykluczający się. Problem tutaj jest bardziej złożony. Istnieje coś takiego jak mutex, gdy piszesz programy wielowątkowe i chcesz, aby dostęp do jakiegoś zasobu, np. komórki pamięci, był ograniczony i realizowany tylko przez jeden wątek. Tutaj zasób może być czymś bardziej abstrakcyjnym. A różne aplikacje z różnych węzłów naszej Sieci powinny otrzymać jedynie wyłączny dostęp do danego zasobu, a nie po to, aby każdy mógł to zmienić lub coś tam napisać. Są to tak zwane zamki.
ZooKeeper pozwala w mniejszym lub większym stopniu rozwiązać wszystkie te problemy. I pokażę na przykładach, jak pozwala to zrobić.
Nie ma żadnych prymitywów blokujących. Kiedy zaczniemy czegoś używać, ten prymityw nie będzie czekał na wystąpienie żadnego zdarzenia. Najprawdopodobniej to coś będzie działać asynchronicznie, dzięki czemu procesy nie będą się zawieszać podczas oczekiwania na coś. To bardzo przydatna rzecz.
Wszystkie żądania klientów są przetwarzane w kolejności w kolejce ogólnej.
A klienci mają możliwość otrzymania powiadomienia o zmianach w jakimś stanie, o zmianach danych, zanim sam zobaczy zmienione dane.
ZooKeeper może pracować w dwóch trybach. Pierwszy jest samodzielny, w jednym węźle. Jest to wygodne do testowania. Może także pracować w trybie klastrowym na dowolnej liczbie serwerów. Jeśli mamy klaster składający się ze 100 maszyn, to nie jest konieczne, aby działał on na 100 maszynach. Wystarczy wybrać kilka komputerów, na których można uruchomić ZooKeeper. I wyznaje zasadę wysokiej dostępności. W każdej działającej instancji ZooKeeper przechowuje całą kopię danych. Później opowiem ci, jak on to robi. Nie dzieli danych ani nie dzieli ich na partycje. Z jednej strony jest to minus, że nie możemy za dużo przechowywać, z drugiej strony nie ma potrzeby tego robić. Nie do tego jest przeznaczona, to nie jest baza danych.
Dane mogą być buforowane po stronie klienta. Jest to standardowa zasada, abyśmy nie przerywali usługi i nie ładowali jej tymi samymi żądaniami. Inteligentny klient zwykle o tym wie i buforuje to.
Na przykład tutaj coś się zmieniło. Istnieje pewien rodzaj zastosowania. Wybrano nowego lidera, który odpowiada m.in. za przetwarzanie operacji zapisu. I chcemy replikować dane. Jednym z rozwiązań jest umieszczenie go w pętli. I ciągle kwestionujemy naszą usługę - czy coś się zmieniło? Druga opcja jest bardziej optymalna. Jest to mechanizm zegarkowy, który pozwala na powiadamianie klientów, że coś się zmieniło. Jest to metoda tańsza pod względem zasobów i wygodniejsza dla klientów.
Klient to użytkownik korzystający z ZooKeepera.
Serwer to sam proces ZooKeepera.
Znode jest kluczową rzeczą w ZooKeeperze. Wszystkie znody są przechowywane w pamięci ZooKeepera i zorganizowane w formie diagramu hierarchicznego, w formie drzewa.
Istnieją dwa rodzaje operacji. Pierwsza to aktualizacja/zapis, gdy jakaś operacja zmienia stan naszego drzewa. Drzewo jest pospolite.
Możliwe jest, że klient nie zrealizuje jednego żądania i zostanie rozłączony, ale może nawiązać sesję, poprzez którą wchodzi w interakcję z ZooKeeperem.
Model danych ZooKeepera przypomina system plików. Jest standardowy katalog główny i dalej przeszliśmy jakby przez katalogi wychodzące z katalogu głównego. A potem katalog pierwszego poziomu, drugiego poziomu. To wszystko znodes.
Każdy znode może przechowywać pewne dane, zwykle niezbyt duże, na przykład 10 kilobajtów. A każdy znode może mieć określoną liczbę dzieci.
Znode występuje w kilku typach. Można je stworzyć. A tworząc znode, określamy typ, do którego ma on należeć.
Istnieją dwa typy. Pierwszą z nich jest flaga efemeryczna. Znode żyje w ramach sesji. Na przykład klient nawiązał sesję. I tak długo jak ta sesja będzie żywa, będzie istnieć. Jest to konieczne, aby nie wyprodukować czegoś niepotrzebnego. Jest to również odpowiednie w momentach, w których ważne jest dla nas przechowywanie prymitywów danych w ramach sesji.
Drugi typ to flaga sekwencyjna. Zwiększa licznik w drodze do znode. Na przykład mieliśmy katalog z aplikacją 1_5. A kiedy utworzyliśmy pierwszy węzeł, otrzymał on p_1, drugi - p_2. A gdy wywołujemy tę metodę każdorazowo, przekazujemy pełną ścieżkę, wskazując tylko część ścieżki, a liczba ta jest automatycznie zwiększana, ponieważ wskazujemy typ węzła - sekwencyjny.
Zwykły znode. Zawsze będzie żyła i nosiła imię, które jej nadamy.
Kolejną przydatną rzeczą jest flaga zegarka. Jeśli go zainstalujemy, to klient będzie mógł subskrybować niektóre zdarzenia dla konkretnego węzła. Pokażę później na przykładzie, jak to się robi. ZooKeeper sam powiadamia klienta, że dane w węźle uległy zmianie. Powiadomienia nie gwarantują jednak otrzymania nowych danych. Mówią po prostu, że coś się zmieniło, więc nadal trzeba później porównywać dane w osobnych rozmowach.
I jak już powiedziałem, kolejność danych zależy od kilobajtów. Nie ma potrzeby przechowywać tam dużych danych tekstowych, bo to nie jest baza danych, tylko serwer koordynacji działań.
Opowiem Wam trochę o sesjach. Jeśli mamy wiele serwerów, możemy w przejrzysty sposób przechodzić z serwera na serwer za pomocą identyfikatora sesji. To całkiem wygodne.
Każda sesja ma pewien limit czasu. Sesja jest definiowana na podstawie tego, czy klient podczas tej sesji wysyła cokolwiek do serwera. Jeżeli w czasie oczekiwania nic nie przesłał, sesja zostaje zerwana lub klient może ją sam zamknąć.
Nie ma zbyt wielu funkcji, ale za pomocą tego interfejsu API możesz robić różne rzeczy. To wywołanie, które widzieliśmy, tworzy znode i przyjmuje trzy parametry. To jest ścieżka do znode i musi być podana w całości w katalogu głównym. I to też są pewne dane, które chcemy tam przenieść. I rodzaj flagi. A po utworzeniu zwraca ścieżkę do znode.
Po drugie, możesz go usunąć. Sztuczka polega na tym, że drugi parametr, oprócz ścieżki do znode, może określić wersję. W związku z tym ten znode zostanie usunięty, jeśli jego wersja, którą przenieśliśmy, jest równoważna tej, która faktycznie istnieje.
Jeśli nie chcemy sprawdzać tej wersji, po prostu przekazujemy argument „-1”.
Po trzecie, sprawdza istnienie znode. Zwraca wartość true, jeśli węzeł istnieje, w przeciwnym razie false.
Następnie pojawia się flaga watch, która pozwala monitorować ten węzeł.
Możesz ustawić tę flagę nawet na nieistniejącym węźle i otrzymać powiadomienie, gdy się pojawi. To również może być przydatne.
Jest jeszcze kilka wyzwań otrzymać dane. Oczywiste jest, że możemy odbierać dane za pośrednictwem znode. Możesz także użyć zegarka z flagą. W takim przypadku nie zostanie zainstalowany, jeśli nie ma węzła. Dlatego musisz zrozumieć, że istnieje, a następnie otrzymać dane.
Jest również UstawDane. Tutaj podajemy wersję. A jeśli przekażemy to dalej, dane w znode określonej wersji zostaną zaktualizowane.
Można także określić „-1”, aby wykluczyć tę kontrolę.
Inną przydatną metodą jest zdobądź dzieci. Możemy również uzyskać listę wszystkich znodów, które do niego należą. Możemy to monitorować, ustawiając funkcję flag watch.
I metoda synchronizować umożliwia jednoczesne przesłanie wszystkich zmian, zapewniając w ten sposób ich zapisanie i całkowitą zmianę wszystkich danych.
Jeśli wyciągniemy analogie ze zwykłym programowaniem, to gdy użyjesz metod typu write, które zapisują coś na dysk, a po zwróceniu Ci odpowiedzi, nie ma gwarancji, że zapisałeś dane na dysk. I nawet gdy system operacyjny ma pewność, że wszystko zostało zapisane, w samym dysku działają mechanizmy, dzięki którym proces przechodzi przez warstwy buforów, a dopiero potem dane są umieszczane na dysku.
Używane są głównie wywołania asynchroniczne. Dzięki temu klient może pracować równolegle z różnymi żądaniami. Można zastosować podejście synchroniczne, ale jest ono mniej produktywne.
Dwie operacje, o których mówiliśmy, to aktualizacja/zapis, które zmieniają dane. Są to: tworzenie, ustawianie danych, synchronizacja, usuwanie. I czytanie istnieje, getData, getChildren.
Teraz kilka przykładów tego, jak można stworzyć prymitywy do pracy w systemie rozproszonym. Na przykład związane z konfiguracją czegoś. Pojawił się nowy pracownik. Dodaliśmy maszynę i rozpoczęliśmy proces. I są trzy następujące pytania. W jaki sposób wysyła zapytanie do ZooKeepera o konfigurację? A jeśli chcemy zmienić konfigurację, jak to zmienić? A kiedy to zmieniliśmy, jak ci pracownicy, których mieliśmy, to zrozumieli?
ZooKeeper sprawia, że jest to stosunkowo łatwe. Na przykład istnieje nasze drzewo znode. Znajduje się tu węzeł dla naszej aplikacji, tworzymy w nim dodatkowy węzeł, który zawiera dane z konfiguracji. Mogą to być oddzielne parametry lub nie. Ponieważ rozmiar jest mały, rozmiar konfiguracji również jest zwykle mały, więc całkiem możliwe jest przechowywanie go tutaj.
Używasz tej metody otrzymać dane aby uzyskać konfigurację procesu roboczego z węzła. Ustaw na true. Jeśli z jakiegoś powodu ten węzeł nie istnieje, zostaniemy o nim poinformowani, gdy się pojawi lub gdy ulegnie zmianie. Jeśli chcemy wiedzieć, że coś się zmieniło, ustawiamy wartość na true. A jeśli dane w tym węźle ulegną zmianie, będziemy o tym wiedzieć.
UstawDane. Ustawiamy dane, ustawiamy „-1”, czyli nie sprawdzamy wersji, zakładamy, że zawsze mamy jedną konfigurację, nie musimy przechowywać wielu konfiguracji. Jeśli chcesz dużo przechowywać, będziesz musiał dodać kolejny poziom. Tutaj wierzymy, że jest tylko jeden, więc aktualizujemy tylko najnowszą, więc nie sprawdzamy wersji. W tym momencie wszyscy klienci, którzy wykupili wcześniej subskrypcję, otrzymują powiadomienie, że coś się zmieniło w tym węźle. A po ich otrzymaniu muszą również ponownie poprosić o dane. Powiadomienie polega na tym, że nie otrzymują samych danych, a jedynie powiadomienie o zmianach. Następnie muszą poprosić o nowe dane.
Druga opcja użycia prymitywu to członkostwo w grupie. Mamy rozproszoną aplikację, jest mnóstwo pracowników i chcemy zrozumieć, że wszyscy są na swoim miejscu. Dlatego muszą się zarejestrować, że pracują w naszej aplikacji. Chcemy także dowiedzieć się, czy to z procesu głównego, czy z innego miejsca, o wszystkich aktywnych pracownikach, których obecnie mamy.
Jak to zrobić? Dla aplikacji tworzymy węzeł workers i dodajemy tam podpoziom metodą create. Mam błąd na slajdzie. Tutaj potrzebujesz ciągły określ, wówczas wszyscy pracownicy zostaną utworzeni jeden po drugim. A aplikacja żądająca wszystkich danych o dzieciach tego węzła otrzymuje wszystkich istniejących aktywnych pracowników.
To okropna implementacja tego, jak można to zrobić w kodzie Java. Zacznijmy od końca, od głównej metody. To jest nasza klasa, stwórzmy jej metodę. Jako pierwszy argument posługujemy się hostem, z którym się łączymy, czyli ustawiamy go jako argument. Drugim argumentem jest nazwa grupy.
Jak następuje połączenie? To jest prosty przykład użytego interfejsu API. Tutaj wszystko jest stosunkowo proste. Istnieje standardowa klasa ZooKeeper. Przekazujemy do niego gospodarzy. I ustaw limit czasu na przykład na 5 sekund. Mamy też członka o nazwie connectSignal. Zasadniczo tworzymy grupę wzdłuż przesyłanej ścieżki. Nie zapisujemy tam danych, choć można było coś napisać. A węzeł tutaj jest typu trwałego. Zasadniczo jest to zwykły węzeł regularny, który będzie istniał przez cały czas. W tym miejscu tworzona jest sesja. Jest to realizacja samego klienta. Nasz klient będzie okresowo wysyłał wiadomości wskazujące, że sesja jest aktywna. A jak zakończymy sesję, to zamykamy i koniec, sesja się kończy. To na wypadek, gdyby coś nam wypadło, aby ZooKeeper dowiedział się o tym i przerwał sesję.
Jak zablokować zasób? Tutaj wszystko jest trochę bardziej skomplikowane. Mamy zbiór pracowników i istnieje pewien zasób, który chcemy zablokować. W tym celu tworzymy oddzielny węzeł, na przykład o nazwie lock1. Jeśli udałoby nam się to stworzyć, mamy tutaj zamek. A jeśli nie uda nam się go utworzyć, to worker próbuje stąd pobrać getData, a skoro węzeł został już utworzony, to umieszczamy tutaj obserwatora i w chwili, gdy zmieni się stan tego węzła, dowiemy się o tym. I możemy spróbować znaleźć czas na jego odtworzenie. Jeśli wzięliśmy ten węzeł, wzięliśmy tę blokadę, to gdy nie będziemy już potrzebować blokady, porzucimy ją, ponieważ węzeł istnieje tylko w ramach sesji. W związku z tym zniknie. A inny klient w ramach innej sesji będzie mógł zdjąć blokadę na tym węźle, a raczej otrzyma powiadomienie, że coś się zmieniło i będzie mógł spróbować zrobić to na czas.
Kolejny przykład tego, jak można wybrać głównego lidera. Jest to nieco bardziej skomplikowane, ale także stosunkowo proste. Co tu się dzieje? Istnieje główny węzeł, który agreguje wszystkich pracowników. Próbujemy zdobyć dane o przywódcy. Jeżeli przebiegło to pomyślnie, czyli otrzymaliśmy jakieś dane, to nasz pracownik zaczyna podążać za tym liderem. Uważa, że lider już jest.
Jeśli lider z jakiegoś powodu zmarł, np. odpadł, wówczas staramy się stworzyć nowego lidera. A jeśli nam się to uda, to nasz pracownik zostaje liderem. A jeśli komuś w tym momencie udało się stworzyć nowego lidera, to staramy się zrozumieć, kto to jest, a następnie podążać za nim.
Powstaje tu tzw. efekt stada, czyli efekt stada, ponieważ gdy umrze przywódca, przywódcą zostanie ten, kto zdąży na czas.
Podczas przechwytywania zasobu możesz spróbować zastosować nieco inne podejście, które jest następujące. Na przykład chcemy uzyskać zamek, ale bez efektu hert. Będzie to polegać na tym, że nasza aplikacja zażąda listy wszystkich identyfikatorów węzłów dla już istniejącego węzła z blokadą. A jeśli wcześniej węzeł, dla którego utworzyliśmy blokadę, jest najmniejszym ze zbioru, który otrzymaliśmy, to oznacza to, że przechwyciliśmy blokadę. Sprawdzamy, czy otrzymaliśmy zamek. Dla sprawdzenia będzie warunek, że identyfikator, który otrzymaliśmy przy tworzeniu nowego zamka, jest minimalny. A jeśli to otrzymaliśmy, to pracujemy dalej.
Jeśli istnieje jakiś identyfikator mniejszy od naszego zamka, to kładziemy obserwatora na to wydarzenie i czekamy na powiadomienie, aż coś się zmieni. Oznacza to, że otrzymaliśmy ten zamek. I dopóki nie spadnie, nie staniemy się minimalnym identyfikatorem i nie otrzymamy minimalnej blokady, a tym samym będziemy mogli się zalogować. A jeśli ten warunek nie zostanie spełniony, to od razu udajemy się tutaj i ponownie staramy się zdobyć ten zamek, bo coś mogło się w tym czasie zmienić.
Z czego składa się ZooKeeper? Są 4 główne rzeczy. To są procesy przetwarzania - Żądanie. A także transmisja atomowa ZooKeeper. Istnieje dziennik zatwierdzeń, w którym rejestrowane są wszystkie operacje. Oraz sama replikowana baza danych w pamięci, czyli sama baza danych, w której przechowywane jest całe drzewo.
Warto zauważyć, że wszystkie operacje zapisu przechodzą przez procesor żądań. Operacje odczytu trafiają bezpośrednio do bazy danych w pamięci.
Sama baza danych jest w pełni replikowana. Wszystkie instancje ZooKeeper przechowują pełną kopię danych.
Aby przywrócić bazę danych po awarii, istnieje dziennik zatwierdzeń. Standardową praktyką jest to, że zanim dane trafią do pamięci, są tam zapisywane, aby w przypadku awarii można było odtworzyć ten dziennik i przywrócić stan systemu. Stosowane są również okresowe migawki bazy danych.
ZooKeeper Atomic Broadcast to narzędzie służące do utrzymywania replikowanych danych.
ZAB wewnętrznie wybiera lidera z punktu widzenia węzła ZooKeeper. Inne węzły stają się jej naśladowcami i oczekują od niej pewnych działań. Jeżeli otrzymają zgłoszenia, przekazują je wszystkie liderowi. Najpierw wykonuje operację zapisu, a następnie wysyła wiadomość o tym, co się zmieniło, do swoich obserwujących. To bowiem musi odbywać się atomowo, tzn. operacja nagrywania i nadawania całości musi odbywać się atomowo, gwarantując w ten sposób spójność danych.
Przetwarza tylko żądania zapisu. Jego głównym zadaniem jest przekształcenie operacji w aktualizację transakcyjną. To jest specjalnie wygenerowane żądanie.
I tutaj warto zauważyć, że idempotentność aktualizacji dla tej samej operacji jest gwarantowana. Co to jest? Ta rzecz, jeśli zostanie wykonana dwukrotnie, będzie miała ten sam stan, tj. samo żądanie nie ulegnie zmianie. Należy to zrobić, aby w przypadku awarii można było ponownie uruchomić operację, cofając w ten sposób zmiany, które w tej chwili odpadły. W takim przypadku stan systemu stanie się taki sam, tzn. nie powinno być tak, że seria tych samych, np. procesów aktualizacyjnych, doprowadziła do różnych stanów końcowych systemu.
Źródło: www.habr.com