Der bequemste Weg, einen Zookeeper-Server in der Geschichte zu erstellen (empfohlen)

Was ist ZooKeeper

ZooKeeper ist ein Top-Level-Projekt von Apache, das effiziente und hochverfügbare verteilte Koordinierungsdienste für verteilte Anwendungen bereitstellt. Es bietet verteilte Basisdienste wie Datenveröffentlichung/-abonnement, Lastausgleich, Benennungsdienste, verteilte Koordinierung/Benachrichtigung und verteilte Sperren. Aufgrund seiner bequemen Nutzung, hervorragenden Leistung und guten Stabilität wird ZooKeeper häufig in großen verteilten Systemen wie Hadoop, HBase, Kafka und Dubbo verwendet.

Zookeeper hat drei Betriebsmodi: Standalone-Modus, Pseudocluster-Modus und Cluster-Modus.

• Standalone-Modus: Dieser Modus eignet sich im Allgemeinen für Entwicklungs- und Testumgebungen. Einerseits verfügen wir nicht über so viele Maschinenressourcen und andererseits ist für die tägliche Entwicklung und das Debuggen keine extrem gute Stabilität erforderlich.
• Clustermodus: Ein ZooKeeper-Cluster besteht normalerweise aus einer Gruppe von Maschinen. Im Allgemeinen können mehr als 3 Maschinen einen verfügbaren ZooKeeper-Cluster bilden. Jede Maschine, aus der der ZooKeeper-Cluster besteht, behält den aktuellen Serverstatus im Speicher bei und die Kommunikation zwischen den Maschinen bleibt aufrecht.
• Pseudoclustermodus: Dies ist ein spezieller Clustermodus, d. h. alle Server im Cluster werden auf einer Maschine bereitgestellt. Wenn Sie eine gute Maschine zur Verfügung haben und diese im Standalone-Modus einsetzen, werden Ressourcen verschwendet. In diesem Fall können Sie mit ZooKeeper mehrere ZooKeeper-Dienstinstanzen auf einer Maschine starten, indem Sie verschiedene Ports starten, um externe Dienste mit Clustereigenschaften bereitzustellen.

ZooKeeper-bezogenes Wissen

• Leiter bei Zookeeper: verantwortlich für die Einleitung und Abwicklung von Abstimmungen sowie die Aktualisierung des Systemstatus
• Follower: Wird verwendet, um Clientanfragen zu empfangen, Ergebnisse an den Client zurückzugeben und im Leader-Wahlprozess abzustimmen.
• Beobachter: Er kann Clientverbindungen annehmen und Schreibanforderungen an den Leiter weiterleiten, der Beobachter nimmt jedoch nicht am Abstimmungsprozess teil. Er wird nur verwendet, um das System zu erweitern und die Lesegeschwindigkeit zu erhöhen.

Zookeeper-Datenmodell

• Hierarchische Verzeichnisstruktur, benannt nach den herkömmlichen Dateisystem-Spezifikationen, ähnlich wie Linux
• Jeder Knoten in Zookeeper wird als Znode bezeichnet und verfügt über eine eindeutige Pfadkennung.
• Knoten Znode kann Daten und untergeordnete Knoten enthalten, aber Knoten vom Typ EPHEMERAL können keine untergeordneten Knoten haben
• Die Daten in einem Znode können mehrere Versionen haben. Wenn beispielsweise unter einem bestimmten Pfad mehrere Datenversionen vorhanden sind, ist die Versionsnummer erforderlich, um die Daten unter diesem Pfad abzufragen.
• Client-Anwendungen können Monitore auf Knoten einrichten
• Der Knoten unterstützt kein teilweises Lesen und Schreiben, sondern ein einmaliges vollständiges Lesen und Schreiben.

ZooKeeper-Knotenfunktionen

ZooKeeper-Knoten haben einen Lebenszyklus, der vom Knotentyp abhängt. In ZooKeeper können Knoten entsprechend ihrer Dauer in persistente Knoten (PERSISTENT) und temporäre Knoten (EPHEMERAL) unterteilt werden und je nachdem, ob sie geordnet sind, in sequenzielle Knoten (SEQUENTIAL) und ungeordnete Knoten (standardmäßig ungeordnet).

Sobald ein persistenter Knoten erstellt wurde, verbleibt er in Zookeeper, sofern er nicht entfernt wird (er verschwindet nicht aufgrund der Ungültigkeitserklärung der Sitzung des Clients, der den Knoten erstellt hat).

Anwendungsszenarien von Zookeeper

ZooKeeper ist ein hochverfügbares Framework für verteiltes Datenmanagement und Systemkoordination. Basierend auf der Implementierung des Paxos-Algorithmus gewährleistet das Framework eine starke Datenkonsistenz in einer verteilten Umgebung. Auf dieser Funktion basiert auch, dass ZooKeeper viele verteilte Probleme lösen kann.

Es ist anzumerken, dass ZooKeeper nicht für diese Anwendungsszenarien entwickelt wurde. Stattdessen erkundeten viele Entwickler später typische Verwendungsmethoden basierend auf den Merkmalen des Frameworks und der Reihe von API-Schnittstellen (oder primitiven Sätzen), die es bietet.

Datenveröffentlichung und -abonnement (Konfigurationscenter)

Das Publish-and-Subscribe-Modell, auch als Konfigurationscenter bezeichnet, bedeutet, dass der Herausgeber Daten an den ZK-Knoten veröffentlicht, damit der Abonnent dynamisch Daten abrufen kann, wodurch die zentrale Verwaltung und dynamische Aktualisierung von Konfigurationsinformationen realisiert wird. Beispielsweise eignen sich globale Konfigurationsinformationen, Serviceadresslisten von servicebasierten Service-Frameworks usw. sehr gut zur Verwendung.

Einige in der Anwendung verwendete Konfigurationsinformationen werden zur zentralen Verwaltung auf ZK abgelegt. Diese Art von Szenario sieht normalerweise so aus: Die Anwendung erhält die Konfiguration einmal aktiv, wenn sie gestartet wird, und registriert gleichzeitig einen Watcher auf dem Knoten. Auf diese Weise wird der abonnierte Client bei jeder Aktualisierung der Konfiguration in Echtzeit benachrichtigt, um den Zweck zu erreichen, die neuesten Konfigurationsinformationen abzurufen. Im verteilten Suchdienst werden die Indexmetadaten und der Knotenstatus der Serverclustermaschinen in einigen dafür vorgesehenen Knoten von ZK gespeichert, damit verschiedene Clients sie abonnieren können. Verteiltes System zur Protokollsammlung. Die Hauptaufgabe dieses Systems besteht darin, auf verschiedenen Maschinen verteilte Protokolle zu sammeln. Der Collector weist die Sammelaufgabeneinheiten normalerweise entsprechend der Anwendung zu. Daher ist es notwendig, einen Knoten P auf ZK mit dem Anwendungsnamen als Pfad zu erstellen und alle Maschinen-IPs dieser Anwendung auf dem Knoten P als untergeordnete Knoten zu registrieren. Auf diese Weise kann der Collector bei einer Maschinenänderung in Echtzeit benachrichtigt werden, um die Aufgabenzuweisung anzupassen. Einige Informationen im System müssen dynamisch abgerufen werden und es besteht auch das Problem, diese Informationen manuell zu ändern. Normalerweise wird eine Schnittstelle bereitgestellt, beispielsweise eine JMX-Schnittstelle, um einige Laufzeitinformationen zu erhalten. Nach der Einführung von ZK müssen Sie keine Lösung mehr selbst implementieren, sondern diese Informationen einfach auf dem angegebenen ZK-Knoten speichern. Hinweis: In den oben genannten Anwendungsszenarien gibt es eine Standardprämisse: Das Datenvolumen ist gering, aber die Datenaktualisierung kann relativ schnell erfolgen.

Lastenausgleich

Bei dem hier erwähnten Lastausgleich handelt es sich um einen sanften Lastausgleich. Um in einer verteilten Umgebung eine hohe Verfügbarkeit sicherzustellen, stellt der Anbieter derselben Anwendung oder desselben Dienstes normalerweise mehrere Kopien bereit, um einen Peer-to-Peer-Dienst zu erreichen. Verbraucher müssen einen dieser Peer-Server auswählen, um die zugehörige Geschäftslogik auszuführen. Der typischere davon ist der Lastenausgleich zwischen Produzent und Verbraucher in der Nachrichten-Middleware.

Benennungsdienst

Auch Namensgebungsdienste sind in verteilten Systemen ein gängiges Szenario. In einem verteilten System können Client-Anwendungen durch die Verwendung eines Benennungsdienstes die Adresse, den Anbieter und andere Informationen einer Ressource oder eines Dienstes basierend auf dem angegebenen Namen abrufen. Bei den benannten Entitäten kann es sich normalerweise um Maschinen in einem Cluster, bereitgestellte Serviceadressen, Remoteobjekte usw. handeln. Wir können sie gemeinsam als Namen bezeichnen. Zu den gebräuchlichsten gehören die Serviceadresslisten in einigen verteilten Service-Frameworks. Durch Aufrufen der von ZK bereitgestellten API zur Knotenerstellung können Sie ganz einfach einen global eindeutigen Pfad erstellen, der als Name verwendet werden kann.

Dubbo, das Open-Source-Framework für verteilte Dienste der Alibaba Group, verwendet ZooKeeper als Namensdienst, um eine globale Serviceadressliste zu verwalten. In der Dubbo-Implementierung: Wenn der Dienstanbieter startet, schreibt er seine URL-Adresse in das angegebene Verzeichnis /dubbo/${serviceName}/providers auf ZK. Dieser Vorgang schließt die Dienstfreigabe ab. Wenn der Service-Consumer startet, abonniert er die Provider-URL-Adresse im Verzeichnis /dubbo/${serviceName}/providers und schreibt seine eigene URL-Adresse in das Verzeichnis /dubbo/${serviceName} /consumers . Beachten Sie, dass alle bei ZK registrierten Adressen temporäre Knoten sind. Dadurch wird sichergestellt, dass Dienstanbieter und Verbraucher Ressourcenänderungen automatisch erkennen können.

Darüber hinaus bietet Dubbo auch eine Überwachung auf Serviceebene, indem es die Informationen aller Anbieter und Verbraucher im Verzeichnis /dubbo/${serviceName} abonniert.

Verteilte Benachrichtigung/Koordination

Die einzigartige Watcher-Registrierung und der asynchrone Benachrichtigungsmechanismus von ZooKeeper können Benachrichtigungen und Koordination zwischen verschiedenen Systemen in einer verteilten Umgebung effektiv implementieren und eine Echtzeitverarbeitung von Datenänderungen realisieren. Die Verwendungsmethode besteht normalerweise darin, dass verschiedene Systeme denselben Znode auf ZK registrieren und die Änderungen des Znode überwachen (einschließlich des Inhalts des Znode selbst und seiner untergeordneten Knoten). Wenn ein System den Znode aktualisiert, kann das andere System die Benachrichtigung empfangen und entsprechende Verarbeitungsvorgänge durchführen.

Ein weiterer Mechanismus zur Erkennung von Heartbeats: Das Erkennungssystem und das erkannte System sind nicht direkt miteinander verbunden, sondern über einen Knoten auf zk, was die Systemkopplung erheblich reduziert. Ein weiterer Systemplanungsmodus: Ein System besteht aus zwei Teilen: einer Konsole und einem Push-System. Die Konsole ist dafür verantwortlich, das Push-System zu steuern, um entsprechende Push-Arbeiten auszuführen. Einige von Managern in der Konsole ausgeführte Vorgänge ändern tatsächlich den Status bestimmter Knoten auf ZK, und ZK benachrichtigt die Clients, die ihre Watcher registrieren, d. h. das Push-System, über diese Änderungen und führt dann entsprechende Push-Aufgaben aus.

Ein weiterer Arbeitsberichtsmodus: Er ähnelt in gewisser Weise dem Aufgabenverteilungssystem. Nachdem die Unteraufgabe gestartet wurde, geht sie zu zk, um einen temporären Knoten zu registrieren, und meldet regelmäßig ihren Fortschritt (schreibt den Fortschritt zurück an diesen temporären Knoten), sodass der Aufgabenmanager den Aufgabenfortschritt in Echtzeit kennen kann.

Verteilte Sperren

Verteilte Sperren sind hauptsächlich auf die starke Datenkonsistenz zurückzuführen, die ZooKeeper garantiert. Sperrdienste können in zwei Kategorien unterteilt werden: Eine dient der Wahrung der Exklusivität und die andere der Kontrolle des Zeitpunkts.

Der sogenannte exklusive Besitz bedeutet, dass von allen Clients, die versuchen, das Schloss zu erhalten, nur einer das Schloss erfolgreich erhalten kann. Die übliche Vorgehensweise besteht darin, einen Znode auf ZK als Sperre zu betrachten und ihn durch create znode zu implementieren. Alle Clients erstellen einen /distribute_lock Knoten und der Client, der den Knoten erfolgreich erstellt, besitzt die Sperre. Die Steuerung des Timings bedeutet, dass für alle Clients, die versuchen, die Sperre zu erhalten, letztendlich eine Ausführung geplant wird. Es gibt jedoch ein globales Timing. Der Ansatz ähnelt dem oben beschriebenen, außer dass /distribute_lock bereits vorhanden ist und der Client darunter einen temporären geordneten Knoten erstellt (dies kann durch die Eigenschaften des Knotens gesteuert werden: zur Angabe CreateMode.EPHEMERAL_SEQUENTIAL ). Der übergeordnete Knoten von Zk ( /distribute_lock ) verwaltet eine Sequenz, um den Zeitpunkt der Erstellung des untergeordneten Knotens sicherzustellen und so den globalen Zeitpunkt jedes Clients zu bilden.

Da die Namen der Unterknoten unter demselben Knoten nicht identisch sein können, bedeutet eine erfolgreiche Erstellung, dass die Sperre erfolgreich ist, solange unter einem bestimmten Knoten ein Z-Knoten erstellt wird. Registrieren Sie einen Listener, um diesen Znode zu überwachen, und benachrichtigen Sie andere Clients, ihn zu sperren, sobald dieser Znode gelöscht wird. Temporäre sequentielle Knoten erstellen: Erstellen Sie einen Knoten unter einem bestimmten Knoten. Wenn eine Anforderung eingeht, wird ein Knoten erstellt. Da es sequentiell ist, erhält der Knoten mit der kleinsten Sequenznummer die Sperre. Wenn die Sperre freigegeben wird, wird die nächste Sequenznummer benachrichtigt, um die Sperre zu erhalten.

Verteilte Warteschlangen

Was Warteschlangen betrifft, gibt es vereinfacht gesagt zwei Typen. Eine davon ist die normale First-In-First-Out-Warteschlange, und bei der anderen wird gewartet, bis alle Warteschlangenmitglieder zusammengekommen sind, bevor die Ausführung der Reihe nach erfolgt. Das Grundprinzip des ersten Warteschlangentyps ist dasselbe wie das des Zeitsteuerungsszenarios im oben erwähnten verteilten Sperrdienst, daher werde ich hier nicht näher darauf eingehen.

Der zweite Warteschlangentyp ist eigentlich eine Erweiterung basierend auf der FIFO-Warteschlange. Normalerweise können Sie einen /queue/num Knoten unter dem /queue -Znode vorab erstellen und einen Wert von n zuweisen (oder n direkt /queue zuweisen), um die Warteschlangengröße anzugeben. Danach wird bei jedem Beitritt eines Warteschlangenmitglieds ermittelt, ob die Warteschlangengröße erreicht wurde, um zu entscheiden, ob die Ausführung beginnen kann. Ein typisches Szenario für diese Verwendung ist, dass in einer verteilten Umgebung eine große Aufgabe, Aufgabe A, erst ausgeführt werden kann, wenn viele Unteraufgaben abgeschlossen sind (oder die Bedingungen erfüllt sind). Wenn zu diesem Zeitpunkt eine der Unteraufgaben abgeschlossen (bereit) ist, wird sie ihren eigenen temporären Sequenzknoten ( CreateMode.EPHEMERAL_SEQUENTIAL ) unter /taskList erstellen. Wenn /taskList feststellt, dass die Anzahl der untergeordneten Knoten die angegebene Zahl erreicht, kann sie mit dem nächsten Schritt fortfahren und sie der Reihe nach verarbeiten.

Verwenden Sie dokcer-compose, um einen Cluster zu erstellen

Wir haben oben so viele Anwendungsszenarien von ZooKeeper vorgestellt. Als Nächstes lernen wir zunächst, wie man einen ZooKeeper-Cluster erstellt, und üben dann die oben genannten Anwendungsszenarien.

Die Verzeichnisstruktur der Datei ist wie folgt:

├── docker-compose.yml

Schreiben Sie die Datei docker-compose.yml

Der Inhalt der Datei docker-compose.yml ist wie folgt:

Version: '3.4'
Leistungen:
 zoo1:
 Bild: Tierpfleger
 Neustart: immer
 Hostname: zoo1
 Häfen:
  - 2181:2181
 Umfeld:
  ZOO_MY_ID: 1
  ZOO_SERVERS: server.1=0.0.0.0:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=zoo3:2888:3888;2181
 zoo2:
 Bild: Tierpfleger
 Neustart: immer
 Hostname: zoo2
 Häfen:
  - 2182:2181
 Umfeld:
  ZOO_MY_ID: 2
  ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=0.0.0.0:2888:3888;2181 server.3=zoo3:2888:3888;2181
 zoo3:
 Bild: Tierpfleger
 Neustart: immer
 Hostname: zoo3
 Häfen:
  - 2183:2181
 Umfeld:
  ZOO_MY_ID: 3
  ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=0.0.0.0:2888:3888;2181

In dieser Konfigurationsdatei führt Docker drei Zookeeper-Images aus und bindet die lokalen Ports 2181, 2182 und 2183 über das Ports-Feld an den Port 2181 des entsprechenden Containers.

ZOO_MY_ID und ZOO_SERVERS sind zwei Umgebungsvariablen, die zum Erstellen eines Zookeeper-Clusters erforderlich sind. ZOO_MY_ID identifiziert die Service-ID, die eine Ganzzahl zwischen 1 und 255 ist und im Cluster eindeutig sein muss. ZOO_SERVERS ist eine Liste von Hosts im Cluster.

Führen Sie docker-compose up im Verzeichnis aus, in dem sich docker-compose.yml befindet, um das Startprotokoll anzuzeigen.

Herstellen einer Verbindung mit ZooKeeper

Nach dem Starten des Clusters können wir eine Verbindung mit ZooKeeper herstellen, um knotenbezogene Vorgänge darauf auszuführen.

Zuerst müssen wir ZooKeeper herunterladen. ZooKeeper-Downloadadresse. Entpacken Sie es in das conf -Verzeichnis und ändern Sie zoo_sample .cfg zoo.cfg

Beschreibung der Konfigurationsdatei

# Die Anzahl der Millisekunden jedes Ticks
# tickTime: CS-Kommunikations-Heartbeat-Nummer # Das Zeitintervall für die Aufrechterhaltung von Heartbeats zwischen Zookeeper-Servern oder zwischen Clients und Servern, d. h. jedes Mal wird ein Heartbeat gesendet. TickTime wird in Millisekunden angegeben.
tickZeit=2000

# Die Anzahl der Ticks, die der anfängliche
# Die Synchronisationsphase kann dauern
# initLimit: LF – anfängliches Kommunikationszeitlimit # Die maximale Anzahl von Heartbeats (Anzahl der TickTimes), die während der anfänglichen Verbindung zwischen dem Follower-Server (F) und dem Leader-Server (L) im Cluster toleriert werden kann.
initLimit=5

# Die Anzahl der Ticks, die zwischen
# Senden einer Anfrage und Erhalten einer Bestätigung
# syncLimit: Zeitlimit für die LF-Synchronisierungskommunikation # Die maximale Anzahl von Heartbeats (Anzahl der TickTimes), die zwischen Anforderungen und Antworten zwischen dem Follower-Server und dem Leader-Server im Cluster toleriert werden kann.
syncLimit=2

# das Verzeichnis, in dem der Snapshot gespeichert ist.
# benutze /tmp nicht zur Speicherung, /tmp ist hier nur
# Beispiel sei Dank.
# dataDir: Datendateiverzeichnis #Das Verzeichnis, in dem Zookeeper Daten speichert. Standardmäßig speichert Zookeeper auch die Protokolldateien zum Schreiben von Daten in diesem Verzeichnis.
dataDir=/data/soft/zookeeper-3.4.12/data


# dataLogDir: Protokolldateiverzeichnis #Das Verzeichnis, in dem Zookeeper Protokolldateien speichert.
dataLogDir=/data/soft/zookeeper-3.4.12/logs

# der Port, an dem die Clients eine Verbindung herstellen
# clientPort: Client-Verbindungsport# Der Port, über den der Client eine Verbindung zum Zookeeper-Server herstellt. Zookeeper überwacht diesen Port und akzeptiert Zugriffsanforderungen vom Client.
clientPort=2181

# die maximale Anzahl von Clientverbindungen.
# Erhöhen Sie diesen Wert, wenn Sie mehr Kunden bedienen müssen
#maxClientCnxns=60
#
# Lesen Sie unbedingt den Wartungsabschnitt der
# Administratorhandbuch vor dem Aktivieren der automatischen Bereinigung.
#
# http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#
# Die Anzahl der Snapshots, die im Datenverzeichnis aufbewahrt werden sollen
#autopurge.snapRetainCount=3
# Bereinigungsaufgabenintervall in Stunden
# Auf „0“ setzen, um die automatische Bereinigungsfunktion zu deaktivieren
#autopurge.purgeInterval=1


# Servername und -adresse: Clusterinformationen (Servernummer, Serveradresse, LF-Kommunikationsport, Wahlport)
# Das Schreibformat dieses Konfigurationselements ist speziell, die Regeln lauten wie folgt:

# server.N=YYY:A:B

# Wobei N die Servernummer, YYY die Server-IP-Adresse und A der LF-Kommunikationsport ist, der den Port für den Informationsaustausch zwischen dem Server und dem Leader im Cluster angibt. B ist der Wahlport, der den Port angibt, über den Server bei der Wahl eines neuen Anführers miteinander kommunizieren (wenn der Anführer ausfällt, kommunizieren die verbleibenden Server miteinander, um einen neuen Anführer auszuwählen). Im Allgemeinen ist der A-Port jedes Servers im Cluster derselbe und der B-Port jedes Servers ist ebenfalls derselbe. Bei Verwendung eines Pseudoclusters sind die IP-Adressen jedoch gleich, lediglich der A-Port und der B-Port sind unterschiedlich.

Sie müssen zoo.cfg nicht ändern, die Standardkonfiguration ist ausreichend. Führen Sie als Nächstes den Befehl ./zkCli.sh -server 127.0.0.1:2181 im entpackten Bin-Verzeichnis aus, um eine Verbindung herzustellen.

Willkommen bei ZooKeeper!
2020-06-01 15:03:52,512 [myid:] - INFO [main-SendThread(localhost:2181):ClientCnxn$SendThread@1025] - Socket-Verbindung zum Server localhost/127.0.0.1:2181 wird geöffnet. Es wird kein Versuch unternommen, sich mit SASL zu authentifizieren (unbekannter Fehler)
JLine-Unterstützung ist aktiviert
2020-06-01 15:03:52,576 [myid:] - INFO [main-SendThread(localhost:2181):ClientCnxn$SendThread@879] - Socket-Verbindung zu localhost/127.0.0.1:2181 hergestellt, Sitzung wird initiiert
2020-06-01 15:03:52,599 [myid:] - INFO [main-SendThread(localhost:2181):ClientCnxn$SendThread@1299] - Sitzungsaufbau abgeschlossen auf Server localhost/127.0.0.1:2181, Sitzungs-ID = 0x100001140080000, ausgehandeltes Timeout = 30000

BEOBACHTER::

WatchedEvent-Status: SyncConnected Typ: Keiner Pfad: null
[zk: 127.0.0.1:2181(VERBUNDEN) 0]

Als nächstes können wir den Befehl verwenden, um den Knoten anzuzeigen

Verwenden Sie den Befehl ls, um den Inhalt des aktuellen ZooKeeper anzuzeigen

Befehl: ls /

[zk: 127.0.0.1:2181(VERBUNDEN) 10] ls /

[Tierpfleger] ```

Ein neuer Znode „zk“ wird erstellt und ihm wird eine Zeichenfolge zugeordnet.

Befehl: create /zk myData

[zk: 127.0.0.1:2181(VERBUNDEN) 11] create /zk myData

Erstellt /zk [zk: 127.0.0.1:2181(VERBUNDEN) 12] ls / [zk, zookeeper] [zk: 127.0.0.1:2181(VERBUNDEN) 13] ```

Holen Sie sich den Znode-Knoten zk

Befehl: get /zk

[zk: 127.0.0.1:2181(VERBUNDEN) 13] get /zk

myData cZxid = 0x400000008 ctime = Montag, 1. Juni 2020, 15:07:50 CST mZxid = 0x400000008 mtime = Montag, 1. Juni 2020, 15:07:50 CST pZxid = 0x400000008 cversion = 0 dataVersion = 0 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 6 numChildren = 0

```

Znode-Knoten zk löschen

Befehl: delete /zk

[zk: 127.0.0.1:2181(VERBUNDEN) 14] löschen /zk

[zk: 127.0.0.1:2181(VERBUNDEN) 15] ls / [zookeeper] ```

Aus Platzgründen werden im nächsten Artikel die oben genannten ZooKeeper-Anwendungsszenarien nacheinander mit Code implementiert.

Wo werden die Docker-Konfigurationsdateien von ZooKeeper gespeichert?

Wo werden die Docker-Konfigurationsdateien von ZooKeeper gespeichert?

Wo werden die Docker-Konfigurationsdateien von ZooKeeper gespeichert?

Sie können das Projekt direkt von oben abrufen. Um RocketMQ zu starten, sind nur zwei Schritte erforderlich.

Rufen Sie das Projekt von GitHub ab und führen Sie den Befehl docker-compose up im ZooKeeper-Ordner aus.

Verweise

http://www.jucaiylzc.cn /2011/10/08/1232/
http://www.dongdongrji.cn /2019/04/25/1_Zookeeper%E8%AF%A6%E8%A7%A3/
https://www.jintianxuesha.com/cyfonly/p/5626532.html
http://www.hengxuangyul.com .com/docker-zookeeper-cluster/
https://www.qiaoheibpt.com maizitoday.github.io/post/zookeeper%E5%85%A5%E9%97%A8/

Zusammenfassen

Dies ist das Ende dieses Artikels über die bequemste Art, einen Zookeeper-Server zu erstellen, die es je gab. Weitere relevante Inhalte zum Erstellen eines Zookeeper-Servers finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!