ZooKeeper-Datenmodell

ZooKeeper verfügt über einen hierarchischen Namespace, ähnlich einem verteilten Dateisystem. Der einzige Unterschied zwischen ihnen besteht darin, dass jeder Knoten im Namespace Datenzuordnungen als untergeordnete Knoten haben kann. Es ist, als hätte man ein Dateisystem, das es Dateien ermöglicht, auch Dateiverzeichnisse zu sein. Knotenpfade werden normalerweise als kanonische, durch Schrägstriche getrennte absolute Pfade ausgedrückt. Sie haben keine relativen Pfade. Alle im Pfad enthaltenen Unicode-Zeichen müssen den folgenden Einschränkungen entsprechen:
1) Nullzeichen können nicht als Pfadnamen verwendet werden.
2) Die folgenden Zeichenfolgen können nicht verwendet werden, da sie nicht anzeigefreundlich genug sind oder zu Problemen führen können Verwechslung (u0001 - u001F und u007F - u009F)
3) Die folgenden Zeichenfolgen sind nicht zulässig. (ud800 – uF8FF, uFFF0 – uFFFF)
4) Das „.“-Zeichen kann als Teil des Namens verwendet werden, aber „.“ und „..“ können nicht alleine existieren, um den Pfad eines Knotens darzustellen, da ZooKeeper verwendet keine relativen Pfade. Die folgenden Beispiele sind ungültig: „/a/b/./c“ oder „/a/b/../c“
5) Das Schlüsselwort „zookeeper“ ist reserviert

ZNodes

Jeder Knoten in der ZooKeeper-Baumstruktur kann als Znode bezeichnet werden. Znodes verwalten eine Statusdatenstruktur, einschließlich der Versionsnummer der Datenänderung, der ACL-Änderung und des Zeitstempels. Mithilfe der Versionsnummer und eines Zeitstempels kann ZooKeeper den Cache ersetzen und Aktualisierungen koordinieren. Immer wenn sich die Daten eines Znodes ändern, wird die Versionsnummer erhöht. Wenn beispielsweise ein Client Daten empfängt, erhält er auch eine Version dieser Daten. Wenn der Client einen Aktualisierungs- oder Löschvorgang ausführt, muss er gleichzeitig die Datenversion des sich ändernden Znode-Knotens bereitstellen. Wenn die vom znode bereitgestellte Versionsnummer nicht mit der tatsächlichen Versionsnummer der aktuellen Daten übereinstimmt, schlägt die Aktualisierung fehl.

Hinweis:

In einem verteilten Anwendungsprojekt kann der Wortknoten als einzelner Host, als Server, als Mitglied des Ganzen und als Client-Prozessor betrachtet werden und so weiter. In der ZooKeeper-Dokumentation werden Znodes als Datenknoten betrachtet. Server gelten als Hosts, aus denen der ZooKeeper-Dienst besteht. Quorum-Peers gelten als Server, die ein Ganzes bilden, und Clients gelten als Host oder Prozess, der den ZooKeeper-Dienst nutzt.

Znodes sind die Hauptentitäten, auf die Programmierer zugreifen. Sie verfügen über viele wissenswerte Funktionen:

Uhren (Listener)

Kunden können auf Znodes zuhören. Änderungen am Znode lösen diesen Listener aus und löschen ihn anschließend. Wenn ein Listener ausgelöst wird, sendet ZooKeeper eine Benachrichtigung an den Client.

Datenzugriff (Datenzugriff)

Die im Znode im Namespace gespeicherten Daten werden atomar gelesen oder geschrieben. Lesevorgänge lesen alle mit dem Znode verknüpften Datenbytes und Schreibvorgänge ersetzen alle Daten. Jeder Knoten verfügt über eine Datenzugriffsliste der Access Control List (ACL), die einschränkt, wer was tun kann.

ZooKeeper ist nicht für den Einsatz als Datenbank oder Speicher für große Objekte konzipiert, sondern dient der Verwaltung und Koordinierung von Daten. Die Quellform der Daten können Konfigurationsinformationen, Statusinformationen, Regionsinformationen usw. sein. Eine gemeinsame Eigenschaft der verschiedenen Formen von Koordinationsdaten besteht darin, dass sie relativ klein sind und im Bereich von KB-Bytes liegen. Sowohl der ZooKeeper-Client als auch der Server verfügen über Plausibilitätsprüfungen, um sicherzustellen, dass Znodes kleiner als 1 MB Daten sind, die Daten können jedoch viel kleiner als dieser Durchschnitt sein. Das Arbeiten mit relativ großen Datenmengen führt dazu, dass der Vorgang lange dauert und sich somit auf die Verzögerung anderer Vorgänge auswirkt, da diese zusätzliche Zeit eine Datenmigration über das Netzwerk oder Speichermedien erfordert. Wenn die Speicherung großer Datenmengen erforderlich ist, besteht der übliche Umgang mit diesen Daten darin, sie in einem großen Speichersystem wie NFS oder HDFS aufzubewahren und dann einen Zeiger auf den Datenspeicherort in ZooKeeper zu speichern.

Ephemere Knoten (temporäre Knoten)

ZooKeeper hat das Konzept der ephemeren Knoten. Solange die Sitzung, die den Knoten erstellt hat, aktiv ist, sind diese Knoten noch vorhanden. Wenn die Sitzung geschlossen wird, werden diese Knoten ebenfalls gelöscht. Aufgrund dieses Verhaltens dürfen temporäre Knoten keine untergeordneten Knoten haben.

Sequenzknoten – Eindeutige Benennung (Sequenzknoten – Eindeutige Benennung)

Beim Erstellen eines Knotens können Sie ZooKeeper bitten, am Ende des Pfads einen monoton ansteigenden Zähler hinzuzufügen. Dieser Zähler gilt nur für diesen übergeordneten Knoten. Das Format des Zählers ist %010d (Dezimalzahl aufgefüllt mit Nullen), formatiert für eine einfache Sortierung. Zum Beispiel „0000000001“. Ein Beispiel für die Verwendung dieser Funktion finden Sie im Queue-Rezept. Hinweis: Der zum Speichern der nächsten Sequenznummer verwendete Zähler ist ein vorzeichenbehafteter Int, der vom übergeordneten Knoten verwaltet wird. Dieser Zähler läuft über, wenn er über 2147483647 hinaus erhöht wird (das Ergebnis sollte „-2147483647“ sein).

Das obige ist der detaillierte Inhalt vonZooKeeper-Datenmodell. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!