Zookeeper - podstawy
Zanim zagłębimy się w działanie ZooKeepera, przyjrzyjmy się podstawowym koncepcjom ZooKeepera. W tym rozdziale omówimy następujące tematy -
- Architecture
- Hierarchiczna przestrzeń nazw
- Session
- Watches
Architektura ZooKeeper
Spójrz na poniższy diagram. Przedstawia „architekturę klient-serwer” ZooKeepera.
W poniższej tabeli opisano każdy z komponentów wchodzących w skład architektury ZooKeeper.
| Część | Opis |
|---|---|
| Klient | Klienci, jeden z węzłów w naszym rozproszonym klastrze aplikacji, uzyskują dostęp do informacji z serwera. Przez określony czas każdy klient wysyła wiadomość do serwera, aby poinformować serwer, że klient żyje. Podobnie serwer wysyła potwierdzenie, gdy klient łączy się. Jeśli nie ma odpowiedzi z podłączonego serwera, klient automatycznie przekierowuje wiadomość na inny serwer. |
| serwer | Serwer, jeden z węzłów w naszym zespole ZooKeeper, zapewnia wszystkie usługi klientom. Przekazuje klientowi potwierdzenie informujące, że serwer działa. |
| Ensemble | Grupa serwerów ZooKeeper. Minimalna liczba węzłów wymagana do utworzenia zespołu to 3. |
| Lider | Węzeł serwera, który przeprowadza automatyczne odzyskiwanie, jeśli którykolwiek z podłączonych węzłów ulegnie awarii. Liderzy są wybierani przy uruchomieniu usługi. |
| Zwolennik | Węzeł serwera zgodny z instrukcją lidera. |
Hierarchiczna przestrzeń nazw
Poniższy diagram przedstawia strukturę drzewa systemu plików ZooKeeper używanego do reprezentacji pamięci. Węzeł ZooKeeper jest określany jakoznode. Każdy znode jest identyfikowany nazwą i oddzielony ciągiem ścieżek (/).
Na diagramie najpierw masz root znodeoddzielone „/”. W katalogu głównym masz dwie logiczne przestrzenie nazwconfig i workers.
Plik config przestrzeń nazw jest używana do scentralizowanego zarządzania konfiguracją i workers przestrzeń nazw jest używana do nazewnictwa.
Pod configprzestrzeni nazw, każdy znode może przechowywać do 1MB danych. Jest to podobne do systemu plików UNIX z wyjątkiem tego, że nadrzędny znode może również przechowywać dane. Głównym celem tej struktury jest przechowywanie zsynchronizowanych danych oraz opis metadanych znode. Ta struktura nosi nazwęZooKeeper Data Model.
Każdy znod w modelu danych ZooKeeper utrzymuje plik statStruktura. Statystyka po prostu zapewniametadataznode. Składa się z numeru wersji, listy kontrolnej akcji (ACL), sygnatury czasowej i długości danych.
Version number- Każdy znod ma numer wersji, co oznacza, że za każdym razem, gdy zmieniają się dane związane ze znodem, jego odpowiedni numer wersji również by się zwiększał Użycie numeru wersji jest ważne, gdy wielu klientów zookeeper próbuje wykonać operacje na tym samym znodzie.
Action Control List (ACL)- ACL to w zasadzie mechanizm uwierzytelniania dostępu do znode. Zarządza wszystkimi operacjami odczytu i zapisu znode.
Timestamp- Znacznik czasu reprezentuje czas, który upłynął od utworzenia i modyfikacji znodu. Zwykle jest przedstawiany w milisekundach. ZooKeeper identyfikuje każdą zmianę znodów na podstawie „ID transakcji” (zxid).Zxid jest unikalny i przechowuje czas dla każdej transakcji, dzięki czemu można łatwo zidentyfikować czas, jaki upłynął od jednego żądania do drugiego.
Data length- Całkowita ilość danych przechowywanych w znodzie to długość danych. Możesz przechowywać maksymalnie 1 MB danych.
Rodzaje Znodów
Znody są klasyfikowane jako trwałe, sekwencyjne i efemeryczne.
Persistence znode- Trwałość znode żyje nawet po odłączeniu klienta, który utworzył ten konkretny znod. Domyślnie wszystkie znody są trwałe, chyba że określono inaczej.
Ephemeral znode- Znody efemeryczne są aktywne do czasu życia klienta. Gdy klient zostanie odłączony od zespołu ZooKeeper, efemeryczne znody zostaną automatycznie usunięte. Z tego powodu tylko znody efemeryczne nie mogą dalej mieć dzieci. Jeśli usunie się znod efemeryczny, to następny odpowiedni węzeł wypełni jego pozycję. Ulotne znody odgrywają ważną rolę w wyborach Lidera.
Sequential znode- Znody sekwencyjne mogą być trwałe lub efemeryczne. Kiedy nowy znode jest tworzony jako kolejny znode, ZooKeeper ustala ścieżkę znodu poprzez dołączenie 10-cyfrowego numeru porządkowego do oryginalnej nazwy. Na przykład, jeśli znode ze ścieżką/myapp jest tworzony jako sekwencyjny znode, ZooKeeper zmieni ścieżkę na /myapp0000000001i ustaw następny numer porządkowy na 0000000002. Jeśli dwa kolejne znody zostaną utworzone jednocześnie, ZooKeeper nigdy nie użyje tego samego numeru dla każdego znodu. Znody sekwencyjne odgrywają ważną rolę w blokowaniu i synchronizacji.
Sesje
Sesje są bardzo ważne dla działania ZooKeepera. Żądania w sesji są wykonywane w kolejności FIFO. Gdy klient połączy się z serwerem, zostanie ustanowiona sesja i pliksession id jest przypisany do klienta.
Klient wysyła heartbeatsw określonym przedziale czasu, aby sesja była ważna. Jeśli zespół ZooKeeper nie otrzyma pulsu od klienta przez okres dłuższy niż okres (limit czasu sesji) określony na początku usługi, decyduje, że klient zmarł.
Limity czasu sesji są zwykle przedstawiane w milisekundach. Kiedy sesja kończy się z jakiegokolwiek powodu, efemeryczne znody utworzone podczas tej sesji również zostaną usunięte.
Zegarki
Zegarki to prosty mechanizm, dzięki któremu klient może otrzymywać powiadomienia o zmianach w zespole ZooKeeper. Klienci mogą ustawiać zegarki podczas odczytywania konkretnego znodu. Zegarki wysyłają powiadomienie do zarejestrowanego klienta o każdej zmianie znode (na której klient się rejestruje).
Zmiany znodu to modyfikacja danych związanych ze znodem lub zmiany w potomkach znodu. Zegarki są uruchamiane tylko raz. Jeśli klient chce ponownie otrzymać powiadomienie, należy to zrobić za pomocą innej operacji odczytu. Po wygaśnięciu sesji połączenia klient zostanie odłączony od serwera, a skojarzone z nim zegarki również zostaną usunięte.