https://zookeeper.apache.org/doc/current/zookeeperOver.html
Domyślnie Zookeeper replikuje wszystkie dane do każdego węzła i pozwala klientom obserwować dane pod kątem zmian. Zmiany wysyłane są bardzo szybko (w określonym czasie) do klientów. Możesz także tworzyć „węzły tymczasowe”, które są usuwane w określonym czasie, jeśli klient się rozłączy. ZooKeeper jest wysoce zoptymalizowany pod kątem odczytów , podczas gdy zapisy są bardzo powolne (ponieważ zazwyczaj są wysyłane do każdego klienta natychmiast po zapisaniu). Wreszcie, maksymalny rozmiar „pliku” (znode) w Zookeeperze to 1 MB, ale zazwyczaj będą to pojedyncze ciągi.
Podsumowując, oznacza to, że zookeeper nie jest przeznaczony do przechowywania dużej ilości danych, a już na pewno nie do pamięci podręcznej. Zamiast tego służy do zarządzania pulsami/wiedzieć, które serwery są online, przechowywania/aktualizowania konfiguracji i ewentualnie przekazywania wiadomości (chociaż jeśli masz dużą liczbę wiadomości lub wysokie wymagania dotyczące przepustowości, coś takiego jak RabbitMQ będzie znacznie lepsze do tego zadania).
Zasadniczo ZooKeeper (i Curator, który jest na nim zbudowany) pomaga w obsłudze mechaniki klastrowania – pulsów, dystrybucji aktualizacji/konfiguracji, rozproszonych blokad itp.
Nie jest to tak naprawdę porównywalne z Redis, ale w przypadku konkretnych pytań...
-
Nie obsługuje żadnych obliczeń i w przypadku większości zestawów danych nie będzie w stanie przechowywać danych z żadną wydajnością.
-
Jest replikowany do wszystkich węzłów w klastrze (nie ma to jak klastrowanie Redis, w którym dane mogą być dystrybuowane). Wszystkie wiadomości są przetwarzane w całości w sposób niepodzielny i sekwencjonowane, więc nie ma prawdziwych transakcji. Może być UŻYWANY do zaimplementowania blokad w całym klastrze dla twoich usług (w rzeczywistości jest to bardzo dobre), a na samych węzłach znajduje się wiele prymitywów blokujących, aby kontrolować, które węzły mają do nich dostęp.
-
Jasne, ale ZooKeeper wypełnia niszę. Jest to narzędzie, dzięki któremu rozproszone aplikacje działają przyjemnie z wieloma instancjami, a nie do przechowywania/udostępniania dużych ilości danych. W porównaniu do używania IMDG do tego celu, Zookeeper będzie szybszy, zarządza pulsami i synchronizacją w przewidywalny sposób (z wieloma interfejsami API ułatwiającymi tę część) i ma paradygmat „push” zamiast „pull”, więc węzły są bardzo szybko powiadamiany o zmianach.
Cytat z pytania, do którego prowadzi link...
Kanonicznym przykładem użycia Zookeepera są obliczenia w pamięci rozproszonej
... jest, IMO, trochę mylące. Używałbyś go do organizowania obliczeń, a nie do dostarczania danych. Załóżmy na przykład, że musiałeś przetworzyć wiersze 1-100 tabeli. Można postawić 10 węzłów ZK o nazwach takich jak "1-10", "11-20", "21-30" itp. Aplikacje klienckie zostaną automatycznie powiadomione o tej zmianie przez ZK, a pierwsza z nich złapie " 1-10" i ustaw węzeł efemeryczny clients/192.168.77.66/processing/rows_1_10
Następna aplikacja zobaczy to i przejdzie do następnej grupy do przetworzenia. Rzeczywiste dane do obliczenia byłyby przechowywane w innym miejscu (np. Redis, baza danych SQL itp.). Jeśli węzeł nie powiódł się w trakcie obliczeń, inny węzeł może to zobaczyć (po 30-60 sekundach) i ponownie podjąć zadanie.
Powiedziałbym, że kanonicznym przykładem ZooKeepera jest wybór lidera. Załóżmy, że masz 3 węzły - jeden jest nadrzędny, a pozostałe 2 są podrzędne. Jeśli nadrzędny upadnie, nowym liderem musi zostać węzeł podrzędny. Tego typu rzeczy są idealne dla ZK.
