Zookeeper - Grundlagen
Bevor wir uns eingehend mit der Arbeit von ZooKeeper befassen, werfen wir einen Blick auf die grundlegenden Konzepte von ZooKeeper. Wir werden die folgenden Themen in diesem Kapitel diskutieren -
- Architecture
- Hierarchischer Namespace
- Session
- Watches
Architektur von ZooKeeper
Schauen Sie sich das folgende Diagramm an. Es zeigt die „Client-Server-Architektur“ von ZooKeeper.
Jede der Komponenten, die Teil der ZooKeeper-Architektur sind, wurde in der folgenden Tabelle erläutert.
| Teil | Beschreibung |
|---|---|
| Klient | Clients, einer der Knoten in unserem verteilten Anwendungscluster, greifen vom Server auf Informationen zu. Für ein bestimmtes Zeitintervall sendet jeder Client eine Nachricht an den Server, um den Server darüber zu informieren, dass der Client am Leben ist. Ebenso sendet der Server eine Bestätigung, wenn ein Client eine Verbindung herstellt. Wenn der verbundene Server keine Antwort gibt, leitet der Client die Nachricht automatisch an einen anderen Server weiter. |
| Server | Server, einer der Knoten in unserem ZooKeeper-Ensemble, bietet alle Services für Clients. Gibt dem Client eine Bestätigung, dass der Server aktiv ist. |
| Ensemble | Gruppe von ZooKeeper-Servern. Die Mindestanzahl von Knoten, die zur Bildung eines Ensembles erforderlich sind, beträgt 3. |
| Führer | Serverknoten, der eine automatische Wiederherstellung durchführt, wenn einer der verbundenen Knoten ausfällt. Führungskräfte werden beim Start des Dienstes gewählt. |
| Anhänger | Serverknoten, der der Anweisung des Leiters folgt. |
Hierarchischer Namespace
Das folgende Diagramm zeigt die Baumstruktur des ZooKeeper-Dateisystems, das für die Speicherdarstellung verwendet wird. Der ZooKeeper-Knoten wird als bezeichnetznode. Jeder Knoten wird durch einen Namen identifiziert und durch eine Folge von Pfaden (/) getrennt.
Im Diagramm haben Sie zuerst eine Wurzel znodegetrennt durch "/". Unter root haben Sie zwei logische Namespacesconfig und workers.
Das config Der Namespace wird für das zentrale Konfigurationsmanagement und das verwendet workers Der Namespace wird zur Benennung verwendet.
Unter configIm Namespace kann jeder Znode bis zu 1 MB Daten speichern. Dies ähnelt dem UNIX-Dateisystem, außer dass der übergeordnete Knoten auch Daten speichern kann. Der Hauptzweck dieser Struktur besteht darin, synchronisierte Daten zu speichern und die Metadaten des znode zu beschreiben. Diese Struktur heißtZooKeeper Data Model.
Jeder Knoten im ZooKeeper-Datenmodell verwaltet a statStruktur. Eine Statistik liefert einfach diemetadataeines znode. Es besteht aus Versionsnummer, Aktionssteuerungsliste (ACL), Zeitstempel und Datenlänge.
Version number- Jeder znode hat eine Versionsnummer, dh jedes Mal, wenn sich die mit dem znode verknüpften Daten ändern, wird auch die entsprechende Versionsnummer erhöht. Die Verwendung der Versionsnummer ist wichtig, wenn mehrere Zookeeper-Clients versuchen, Vorgänge über denselben Knoten durchzuführen.
Action Control List (ACL)- ACL ist im Grunde ein Authentifizierungsmechanismus für den Zugriff auf den znode. Es regelt alle Lese- und Schreibvorgänge von znode.
Timestamp- Der Zeitstempel gibt die Zeit an, die seit der Erstellung und Änderung des Knotens vergangen ist. Es wird normalerweise in Millisekunden dargestellt. ZooKeeper identifiziert jede Änderung an den Znodes anhand der „Transaktions-ID“ (zxid).Zxid ist einzigartig und behält die Zeit für jede Transaktion bei, sodass Sie die von einer Anfrage zu einer anderen Anfrage verstrichene Zeit leicht identifizieren können.
Data length- Die Gesamtmenge der in einem Knoten gespeicherten Daten ist die Datenlänge. Sie können maximal 1 MB Daten speichern.
Arten von Znodes
Znodes werden in Persistenz, sequentiell und kurzlebig eingeteilt.
Persistence znode- Der Persistenz-Knoten ist auch dann aktiv, wenn der Client, der diesen bestimmten Knoten erstellt hat, die Verbindung getrennt hat. Standardmäßig sind alle Znodes persistent, sofern nicht anders angegeben.
Ephemeral znode- Vergängliche Knoten sind aktiv, bis der Client lebt. Wenn ein Client vom ZooKeeper-Ensemble getrennt wird, werden die kurzlebigen Knoten automatisch gelöscht. Aus diesem Grund dürfen nur kurzlebige Knoten keine weiteren Kinder haben. Wenn ein kurzlebiger Knoten gelöscht wird, füllt der nächste geeignete Knoten seine Position. Vergängliche Knoten spielen eine wichtige Rolle bei der Wahl des Führers.
Sequential znode- Sequentielle Knoten können entweder persistent oder kurzlebig sein. Wenn ein neuer Knoten als sequentieller Knoten erstellt wird, legt ZooKeeper den Pfad des Knotens fest, indem dem ursprünglichen Namen eine 10-stellige Sequenznummer hinzugefügt wird. Zum Beispiel, wenn ein Knoten mit Pfad/myapp wird als sequentieller Znode erstellt, ZooKeeper ändert den Pfad zu /myapp0000000001und setzen Sie die nächste Sequenznummer auf 0000000002. Wenn zwei aufeinanderfolgende Knoten gleichzeitig erstellt werden, verwendet ZooKeeper niemals dieselbe Nummer für jeden Knoten. Sequentielle Knoten spielen eine wichtige Rolle beim Sperren und Synchronisieren.
Sitzungen
Sitzungen sind für den Betrieb von ZooKeeper sehr wichtig. Anforderungen in einer Sitzung werden in FIFO-Reihenfolge ausgeführt. Sobald ein Client eine Verbindung zu einem Server herstellt, wird die Sitzung eingerichtet und asession id wird dem Kunden zugewiesen.
Der Client sendet heartbeatsin einem bestimmten Zeitintervall, um die Sitzung gültig zu halten. Wenn das ZooKeeper-Ensemble nicht länger als den zu Beginn des Dienstes angegebenen Zeitraum (Sitzungszeitlimit) Herzschläge von einem Client empfängt, entscheidet es, dass der Client gestorben ist.
Sitzungszeitlimits werden normalerweise in Millisekunden dargestellt. Wenn eine Sitzung aus irgendeinem Grund endet, werden auch die kurzlebigen Knoten gelöscht, die während dieser Sitzung erstellt wurden.
Uhren
Uhren sind ein einfacher Mechanismus für den Client, um Benachrichtigungen über die Änderungen im ZooKeeper-Ensemble zu erhalten. Clients können Uhren einstellen, während sie einen bestimmten Knoten lesen. Uhren senden eine Benachrichtigung an den registrierten Client über Änderungen des Znodes (auf dem sich der Client registriert).
Znode-Änderungen sind Änderungen von Daten, die dem znode zugeordnet sind, oder Änderungen in den untergeordneten Knoten des znode. Uhren werden nur einmal ausgelöst. Wenn ein Client erneut eine Benachrichtigung wünscht, muss dies durch einen anderen Lesevorgang erfolgen. Wenn eine Verbindungssitzung abgelaufen ist, wird der Client vom Server getrennt und die zugehörigen Überwachungsfunktionen werden ebenfalls entfernt.