Zookeeper - przepływ pracy

Gdy zespół ZooKeeper zostanie uruchomiony, będzie czekał na połączenie klientów. Klienci będą łączyć się z jednym z węzłów w zespole ZooKeeper. Może to być lider lub węzeł podążający. Po podłączeniu klienta węzeł przypisuje identyfikator sesji do konkretnego klienta i wysyła klientowi potwierdzenie. Jeśli klient nie otrzyma potwierdzenia, po prostu próbuje podłączyć inny węzeł w zespole ZooKeeper. Po podłączeniu do węzła klient będzie wysyłał pulsy do węzła w regularnych odstępach czasu, aby upewnić się, że połączenie nie zostanie utracone.

• If a client wants to read a particular znode, wysyła read requestdo węzła ze ścieżką znode, a węzeł zwraca żądany znode pobierając go z własnej bazy danych. Z tego powodu odczyty są szybkie w zespole ZooKeeper.

• If a client wants to store data in the ZooKeeper ensemblewysyła ścieżkę znode i dane do serwera. Połączony serwer przekaże żądanie do lidera, a następnie lider ponownie wyśle ​​żądanie zapisu do wszystkich obserwujących. Jeśli tylko większość węzłów odpowie pomyślnie, żądanie zapisu powiedzie się, a do klienta zostanie wysłany pomyślny kod powrotu. W przeciwnym razie żądanie zapisu zakończy się niepowodzeniem. Ścisła większość węzłów nosi nazwę asQuorum.

Węzły w zespole ZooKeeper

Przeanalizujmy efekt posiadania różnej liczby węzłów w zespole ZooKeeper.

• Jeśli mamy a single node, wtedy zespół ZooKeeper zawiedzie, gdy ten węzeł ulegnie awarii. Przyczynia się do „pojedynczego punktu awarii” i nie jest zalecany w środowisku produkcyjnym.

• Jeśli mamy two nodes a jeden węzeł zawodzi, nie mamy też większości, ponieważ jeden na dwa nie jest większością.

• Jeśli mamy three nodesa jeden węzeł nie działa, mamy większość, więc jest to minimalne wymaganie. Zespół ZooKeeper musi mieć co najmniej trzy węzły w aktywnym środowisku produkcyjnym.

• Jeśli mamy four nodesa dwa węzły ulegają awarii, to znowu się nie udaje i jest to podobne do posiadania trzech węzłów. Dodatkowy węzeł nie służy żadnemu celowi, dlatego lepiej jest dodawać węzły w liczbach nieparzystych, np. 3, 5, 7.

Wiemy, że proces zapisu jest kosztowny niż proces odczytu w zespole ZooKeeper, ponieważ wszystkie węzły muszą zapisywać te same dane w swojej bazie danych. Dlatego lepiej jest mieć mniejszą liczbę węzłów (3, 5 lub 7) niż dużą liczbę węzłów dla zrównoważonego środowiska.

Poniższy diagram przedstawia ZooKeeper WorkFlow, a następna tabela wyjaśnia jego różne komponenty.

Składnik	Opis
pisać	Proces zapisu jest obsługiwany przez węzeł wiodący. Lider przekazuje żądanie zapisu do wszystkich znodów i czeka na odpowiedzi od znodów. Jeśli połowa znodów odpowiada, to proces zapisu jest zakończony.
Czytać	Odczyty wykonywane są wewnętrznie przez konkretny podłączony znode, więc nie ma potrzeby interakcji z klastrem.
Replikowana baza danych	Służy do przechowywania danych w zookeeper. Każdy znode ma swoją własną bazę danych, a każdy znode ma za każdym razem te same dane za pomocą spójności.
Lider	Lider to Znode, który jest odpowiedzialny za przetwarzanie żądań zapisu.
Zwolennik	Obserwujący otrzymują zapytania od klientów i przekazują je do lidera znode.
Poproś o procesor	Występuje tylko w węźle wiodącym. Zarządza żądaniami zapisu z węzła śledzącego.
Transmisje atomowe	Odpowiada za rozgłaszanie zmian z węzła lidera do węzłów śledzących.