Erklärung von Apache ZooKeeper

Question

Ich versuche zu verstehen, was ZooKeeper ist, wie es funktioniert und was es tut. Gibt es eine Anwendung, die mit ZooKeeper vergleichbar ist?

Wenn Sie es wissen, wie würden Sie ZooKeeper einem Laien beschreiben?

Ich habe apache wiki, zookeeper sourceforge ausprobiert... aber ich kann mich immer noch nicht damit identifizieren.

Ich habe gerade http://zookeeper.sourceforge.net/index.sf.shtml durchgelesen, also gibt es nicht mehr Dienste wie diesen? Ist es so einfach wie das Replizieren eines Serverdienstes?

Answer 1

Kurz gesagt hilft Ihnen ZooKeeper beim Aufbau verteilter Anwendungen.

Wie es funktioniert

Sie können ZooKeeper als einen replizierten Synchronisierungsdienst mit eventueller Konsistenz beschreiben. Es ist robust, da die persistierten Daten zwischen mehreren Knoten verteilt sind (diese Knotengruppe wird als "Ensemble" bezeichnet) und sich ein Client mit einem beliebigen davon verbindet (d.h. einem bestimmten "Server"), der migriert, wenn ein Knoten ausfällt; solange eine strenge Mehrheit der Knoten funktioniert, ist das Ensemble von ZooKeeper-Knoten aktiv. Insbesondere wird ein Masterknoten innerhalb des Ensembles durch Konsens dynamisch ausgewählt; wenn der Masterknoten ausfällt, migriert die Rolle des Masters zu einem anderen Knoten.

Wie Schreibvorgänge gehandhabt werden

Der Master ist die Autorität für Schreibvorgänge: Auf diese Weise können Schreibvorgänge garantiert in der Reihenfolge erhalten bleiben, d.h. Schreibvorgänge sind linear. Jedes Mal, wenn ein Client in das Ensemble schreibt, persistiert eine Mehrheit der Knoten die Informationen: Diese Knoten umfassen den Server für den Client und offensichtlich den Master. Dies bedeutet, dass jeder Schreibvorgang den Server auf den neuesten Stand mit dem Master bringt. Es bedeutet jedoch auch, dass keine gleichzeitigen Schreibvorgänge möglich sind.

Die Garantie für lineare Schreibvorgänge ist der Grund dafür, dass ZooKeeper für schreiblastige Workloads nicht gut geeignet ist. Insbesondere sollte es nicht für den Austausch großer Datenmengen wie Medien verwendet werden. Solange Ihre Kommunikation gemeinsame Daten beinhaltet, hilft Ihnen ZooKeeper. Wenn Daten gleichzeitig geschrieben werden könnten, hindert ZooKeeper tatsächlich, da es eine strenge Reihenfolge der Operationen auferlegt, auch wenn diese aus Sicht der Schreiber nicht unbedingt erforderlich ist. Sein idealer Einsatz liegt in der Koordination, bei der Nachrichten zwischen den Clients ausgetauscht werden.

Wie Lesevorgänge gehandhabt werden

Hierbei glänzt ZooKeeper: Lesevorgänge sind simultan, da sie vom spezifischen Server bedient werden, mit dem sich der Client verbindet. Dies ist jedoch auch der Grund für die eventuelle Konsistenz: Die "Ansicht" eines Clients kann veraltet sein, da der Master den entsprechenden Server mit einer begrenzten, aber undefinierten Verzögerung aktualisiert.

Im Detail

Die replizierte Datenbank von ZooKeeper besteht aus einem Baum von ZNodes, die Entitäten darstellen, die grob gesagt Dateisystemknoten darstellen (stellen Sie sie sich als Verzeichnisse vor). Jeder ZNode kann um einen Byte-Array erweitert werden, das Daten speichert. Außerdem kann jeder ZNode andere ZNodes unter sich haben, die praktisch ein internes Verzeichnissystem bilden.

Sequenzielle ZNodes

Interessanterweise kann der Name eines ZNodes "sequenziell" sein, was bedeutet, dass der Name, den der Client beim Erstellen des ZNodes angibt, nur ein Präfix ist: Der vollständige Name wird auch durch eine von dem Ensemble gewählte sequenzielle Nummer angegeben. Dies ist nützlich, zum Beispiel für Synchronisationszwecke: Wenn mehrere Clients einen Sperrmechanismus für eine Ressource möchten, können sie jeweils gleichzeitig einen sequenziellen ZNode an einem Ort erstellen: Derjenige mit der niedrigsten Nummer hat Anspruch auf die Sperre.

Ephemere ZNodes

Ein ZNode kann auch "ephemeral" sein: Dies bedeutet, dass er gelöscht wird, sobald der Client, der ihn erstellt hat, die Verbindung trennt. Dies ist hauptsächlich nützlich, um zu wissen, wann ein Client ausfällt, was relevant sein kann, wenn der Client selbst Verantwortlichkeiten hat, die von einem neuen Client übernommen werden sollen. Nehmen wir das Beispiel des Sperrmechanismus: Sobald der Client, der die Sperre hat, die Verbindung trennt, können die anderen Clients überprüfen, ob sie Anspruch auf die Sperre haben.

Watches

Das Beispiel der Client-Trennung kann problematisch sein, wenn der Zustand von ZNodes regelmäßig abgefragt werden muss. Glücklicherweise bietet ZooKeeper ein Ereignissystem, bei dem ein Watch auf einem ZNode gesetzt werden kann. Diese Watches können so eingestellt werden, dass ein Ereignis ausgelöst wird, wenn sich der ZNode gezielt ändert oder entfernt wird oder neue untergeordnete Elemente erstellt werden. Dies ist in Kombination mit den sequenziellen und ephemeren Optionen für ZNodes offensichtlich nützlich.

Wo und wie man es einsetzt

Ein klassisches Beispiel für die Verwendung von Zookeeper ist die verteilte Speicherberechnung, bei der einige Daten zwischen Clientknoten geteilt werden müssen und in einer sehr sorgfältigen Weise auf Synchronisierung zugegriffen/aktualisiert werden müssen.

ZooKeeper bietet die Bibliothek zur Konstruktion Ihrer Synchronisierungsprimitiven, während die Möglichkeit, einen verteilten Server auszuführen, das Problem des Single-Point-of-Failure vermeidet, das Sie bei der Verwendung eines zentralisierten (brokerähnlichen) Nachrichtenrepositorys haben.

ZooKeeper ist funktionsleicht, was bedeutet, dass Mechanismen wie Leader-Wahl, Sperren, Barrieren usw. nicht bereits vorhanden sind, aber über den ZooKeeper-Primitiven implementiert werden können. Falls die C/Java-API für Ihre Zwecke zu schwerfällig ist, sollten Sie auf Bibliotheken setzen, die auf ZooKeeper aufbauen, wie z. B. Cages und insbesondere Curator.

Wo man mehr lesen kann

Abgesehen von der offiziellen Dokumentation, die ziemlich gut ist, schlage ich vor, Kapitel 14 von Hadoop: The Definitive Guide zu lesen, das etwa 35 Seiten umfasst und im Wesentlichen erklärt, was ZooKeeper tut, gefolgt von einem Beispiel für einen Konfigurationsservice.

Answer 2

Zookeeper ist einer der besten Open-Source-Server und -Dienste, der dabei hilft, verteilte Prozesse zuverlässig zu koordinieren. Zookeeper ist ein CP-System (siehe CAP-Theorem), das Konsistenz und Partitionstoleranz bietet. Die Replikation des Zookeeper-Zustands über alle Knoten hinweg macht es zu einem letztlich konsistenten verteilten Dienst.

Zudem wird jeder neu gewählte Führer seinen Anhängern fehlende Vorschläge aktualisieren oder diesen einen Schnappschuss des Zustands bereitstellen, wenn den Anhängern viele Vorschläge fehlen.

Zookeeper bietet auch eine API, die sehr einfach zu verwenden ist. Dieser Blog-Beitrag, Zookeeper Java-API-Beispiele, enthält einige Beispiele, wenn Sie auf der Suche nach Beispielen sind.

Also, wo verwenden wir das? Wenn Ihr verteiltes System eine zentralisierte, zuverlässige und konsistente Konfigurationsverwaltung, Sperren, Warteschlangen usw. benötigt, werden Sie in Zookeeper eine zuverlässige Wahl finden.

Answer 3

Welches Problem löst es?

Stellen wir uns vor, wir haben eine Million Dateien in einem Dateispeicher und die Anzahl der Dateien nimmt jede Minute des Tages zu. Unsere Aufgabe ist es, diese Dateien zunächst zu verarbeiten und dann zu löschen. Ein Ansatz, den wir denken können, ist ein Skript zu schreiben, das diese Aufgabe erledigt und mehrere Instanzen parallel auf mehreren Servern ausführt. Wir können sogar die Anzahl der Server je nach Bedarf erhöhen oder verringern. Dies ist im Grunde eine verteilte Computer-/Datenverarbeitungsanwendung.

Wie können wir sicherstellen, dass dieselbe Datei nicht gleichzeitig von mehreren Servern ausgewählt und verarbeitet wird? Um dieses Problem zu lösen, sollten alle Server die Informationen darüber teilen, welche Datei gerade verarbeitet wird.

Hier können wir etwas wie ZooKeeper verwenden. Wenn der erste Server eine Datei lesen möchte, kann er dem Zookeeper den Dateinamen mitteilen, den er verarbeiten wird. Jetzt können die restlichen Server im ZooKeeper nachschauen und wissen, dass diese Datei bereits vom ersten Server ausgewählt wurde.

Oben ist ein grobes Beispiel und es müssen noch einige andere Sicherheitsvorkehrungen getroffen werden, aber ich hoffe, es gibt eine Vorstellung davon, was Zookeeper ist. ZK ist im Grunde ein Datenspeicher, der mit den ZK-APIs abgerufen werden kann. Aber es soll NICHT als Datenbank verwendet werden. Es sollte nur eine geringe Datenmenge gespeichert werden (normalerweise in KB). Die obere Grenze beträgt 1 MB pro ZNode. ZK ist speziell entwickelt worden, damit die verteilten Anwendungen miteinander kommunizieren können.

Anwendungen von ZK

Kann direkt verwendet werden für

• Konfiguration speichern: zur Speicherung von Konfigurationen, die in Ihrer verteilten Anwendung genutzt werden.
• Namensdienst: Speichern von Informationen wie Service-Name und IP-Adresszuordnung an einem zentralen Ort, der es Benutzern und Anwendungen ermöglicht, über das Netzwerk zu kommunizieren.
• Gruppenmitgliedschaft: alle Anwendungen, die auf verteilten Servern laufen, können eine Verbindung zu ZK herstellen und Heartbeats senden. Wenn ein Server/Anwendung ausfällt, kann ZK andere Server/Anwendungen über dieses Ereignis informieren.

Weitere Funktionen müssen auf der ZooKeeper-API aufgebaut werden.

• Sperren und Warteschlangen - nützlich zur verteilten Synchronisation.
• Zweiphasen-Commit - nützlich, wenn wir über Server hinweg commit/rollback durchführen müssen.
• Führerwahl - Ihre verteilten Anwendungen können ZK nutzen, um Führerwahlen für automatische Failovers durchzuführen.
• Gemeinsamer Zähler

Hier ist die Seite, die erklärt, wie diese Funktionen implementiert werden können https://zookeeper.apache.org/doc/current/recipes.html

ZooKeeper kann viele weitere Anwendungen haben. Die Funktionen müssen auf den ZK-APIs basierend auf den Anforderungen Ihres verteilten Systems aufgebaut werden.

HINWEIS: ZK sollte nicht verwendet werden, um große Datenmengen zu speichern. Es ist kein Cache/Datenbank. Verwenden Sie es, um kleine Informationsstücke auszutauschen, die Ihre verteilten Anwendungen zum Starten, Betreiben und für Failovers benötigen.

Wie werden Daten gespeichert?

Daten werden in einer hierarchischen Baumdatenstruktur gespeichert. Jeder Knoten im Baum wird als ZNode bezeichnet. Die maximale Größe eines ZNodes beträgt 1 MB. ZNodes können Daten und andere untergeordnete ZNodes enthalten. Denken Sie bei einem ZNode an einen Ordner auf Ihrem Computer, in dem der Ordner Dateien mit Daten haben kann, aber auch der Ordner selbst Daten enthalten kann, ähnlich wie eine Datei.

Warum ZK anstelle unseres eigenen benutzerdefinierten Dienstes verwenden?

• Atomarität und Langlebigkeit
• ZooKeeper selbst ist verteilt und fehlertolerant. Die Architektur umfasst einen Leader-Knoten und mehrere Follower-Knoten. Falls ein ZK-Followerknoten ausfällt, erfolgt automatisch ein Failover. Die Clientsitzungen werden repliziert, daher kann ZK Clients automatisch auf einen anderen Knoten verschieben. Wenn der Leaderknoten ausfällt, wird ein neuer Leader mithilfe des ZK consens-Algorithmus gewählt.
• Lesen erfolgt sehr schnell, da es aus dem Speicher abgerufen wird.
• Schreibvorgänge werden in der Reihenfolge geschrieben, in der sie eingegangen sind. Daher bleibt die Reihenfolge erhalten.
• Watches senden Benachrichtigungen an den Client, der die Beobachtung auf einige Daten gesetzt hat. Dies reduziert die Notwendigkeit, ZK abzufragen. Beachten Sie, dass Watches einmalige Auslöser sind und wenn Sie ein Watch-Ereignis erhalten und über zukünftige Änderungen informiert werden möchten, müssen Sie eine weitere Watch setzen.
• Es gibt persistente und temporäre ZNodes. Beide werden auf ZK-Festplatten gespeichert. Persistent bedeutet hier, dass die Daten erhalten bleiben, sobald der Client, der sie erstellt hat, die Verbindung trennt. Temporär bedeutet, dass die Daten automatisch entfernt werden, wenn der Client die Verbindung trennt. Temporäre ZNodes dürfen keine untergeordneten Elemente haben.
• Es gibt auch persistente sequenzielle und temporäre sequenzielle ZNodes. Hier können die Namen der ZNodes eine Suffix-Sequenznummer haben. Ähnlich wie bei DB-Autoinkrement-ID's, erhöhen und verwalten diese Sequenznummern und werden von ZK verwaltet. Dies kann nützlich sein, um Warteschlangen, Sperren usw. zu implementieren.

Gibt es eine Anwendung, die mit Zookeeper vergleichbar ist?

etcd - https://etcd.io/docs/v3.3/learning/why/#zookeeper

Answer 4

Ich verstehe den ZooKeeper im Allgemeinen, hatte aber Probleme mit den Begriffen "Quorum" und "Split-Brain", also vielleicht kann ich meine Erkenntnisse mit Ihnen teilen (ich betrachte mich selbst auch als Laie).

Angenommen, wir haben einen ZooKeeper-Cluster mit 5 Servern. Einer der Server wird zum Leader und die anderen werden zu Followern.

• Diese 5 Server bilden ein Quorum. Quorum bedeutet einfach "diese Server können darüber abstimmen, wer der Leader sein soll".

• Die Abstimmung basiert auf der Mehrheit. Mehrheit bedeutet einfach "mehr als die Hälfte", also muss mehr als die Hälfte der Anzahl der Server zustimmen, damit ein bestimmter Server zum Leader wird.

• Es gibt also diese schlechte Sache, die passieren kann, genannt "Split-Brain". Ein Split-Brain ist einfach das, soweit ich es verstehe: Der Cluster von 5 Servern teilt sich in zwei Teile, oder nennen wir es "Server-Teams", mit vielleicht einem Teil von 2 und dem anderen von 3 Servern. Das ist wirklich eine schlechte Situation, denn wenn beide "Server-Teams" eine spezifische Anweisung ausführen müssen, wie würde man entscheiden, welches Team bevorzugt werden sollte? Sie könnten unterschiedliche Informationen von den Clients erhalten haben. Es ist also wirklich wichtig zu wissen, welches "Server-Team" noch relevant ist und welches ignoriert werden kann/sollte.

• Mehrheit ist auch der Grund, warum man eine ungerade Anzahl von Servern verwenden sollte. Wenn Sie 4 Server haben und ein Split-Brain auftritt, bei dem sich 2 Server trennen, könnten beide "Server-Teams" sagen "hey, wir möchten entscheiden, wer der Leader wird!" aber wie soll man entscheiden, welche 2 Server man wählen soll? Bei 5 Servern ist es einfach: Das Server-Team mit 3 Servern hat die Mehrheit und darf den neuen Leader wählen.

• Auch wenn Sie nur 3 Server haben und einer davon ausfällt, bilden die anderen 2 immer noch die Mehrheit und können sich darauf einigen, dass einer von ihnen der neue Leader wird.

Ich merke, dass, sobald man eine Weile darüber nachdenkt und die Begriffe versteht, es nicht mehr so kompliziert ist. Ich hoffe, dass dies auch anderen dabei hilft, diese Begriffe zu verstehen.

Answer 5

Zookeeper ist ein zentralisierter Open-Source-Server zur Aufrechterhaltung und Verwaltung von Konfigurationsinformationen, Namenskonventionen und Synchronisation für verteilte Cluster-Umgebungen. Zookeeper hilft verteilten Systemen, ihre Verwaltungskomplexität zu reduzieren, indem es geringe Latenzzeiten und hohe Verfügbarkeit bietet. Zookeeper war zunächst ein Unterprojekt für Hadoop, ist aber jetzt ein eigenständiges Top-Level-Projekt der Apache Software Foundation.

Mehr Informationen