In diesem Artikel geht es um das Prinzip von Zookeeper. Der Herausgeber findet es ziemlich gut. Ich werde es mit Ihnen für Ihre Referenz teilen. Die Details sind wie folgt:
Vorwort
Zookeeper ist ein von Yahoo erstellter Open -Source -Koordinierungsdienst und eine Open -Source -Implementierung von Google Chubby. Verteilte Anwendungen können Funktionen wie Datenveröffentlichung/Abonnement, Lastausgleich, Benennungsdienste, verteilte Koordination/Benachrichtigung, Clustermanagement, Masterwahlen, verteilte Sperren und verteilte Warteschlangen basierend auf Zookeeper implementieren.
1. Einführung
Zookeeper ist ein von Yahoo erstellter Open -Source -Koordinierungsdienst und eine Open -Source -Implementierung von Google Chubby. Verteilte Anwendungen können Funktionen wie Datenveröffentlichung/Abonnement, Lastausgleich, Benennungsdienste, verteilte Koordination/Benachrichtigung, Clustermanagement, Masterwahlen, verteilte Sperren und verteilte Warteschlangen basierend auf Zookeeper implementieren.
2. Grundlegende Konzepte
In diesem Abschnitt werden mehrere Kernkonzepte von Zookeeper eingeführt. Diese Konzepte werden später in Tiefe in Zookeeper erläutert, so dass es notwendig ist, diese Konzepte im Voraus zu verstehen.
2.1 Clusterrollen
In Zookeeper gibt es drei Zeichen:
Führer
Anhänger
Beobachter
Ein Zookeeper -Cluster hat nur einen Führer gleichzeitig, und die anderen werden Anhänger oder Beobachter sein.
Die Konfiguration von Zookeeper ist sehr einfach. Die Konfigurationsdatei (Zoo.cfg) jedes Knotens ist gleich, und nur die MyID -Datei ist unterschiedlich. Der Wert von MyID muss der {numerische} Teil des Servers sein. {Numerisch} in Zoo.cfg.
Beispiel für den Inhalt von Zoo.cfg -Datei:
Zookeeper
Führen Sie den Zookeeper-Server-Status am Terminal der Maschine mit Zookeeper aus. Sie können sehen, welche Rolle der Zookeeper des aktuellen Knotens ist (Führer oder Anhänger).
Zookeeper
Wie oben erwähnt, ist Node-20-104 der Anführer und Node-20-103 der Anhänger.
Zookeeper hat nur zwei Rollen: standardmäßig Anführer und Anhänger und keine Beobachterrolle. Um den Observer -Modus zu verwenden, fügen Sie hinzu: PeerType = Observer zur Konfigurationsdatei eines beliebigen Knotens, der ein Beobachter werden möchte und hinzufügen möchte: Beobachter in die Konfigurationslinie des Servers im Observer -Modus in der Konfigurationsdatei aller Server, zum Beispiel:
server.1:localhost:2888:3888:observer
Alle Maschinen im Zookeeper -Cluster wählen eine Maschine namens "Leader" im Rahmen eines Leiterwahlenprozesses. Der Leader Server bietet dem Client Lese- und Schreibdienste an.
Sowohl Anhänger als auch Beobachter können Lesedienste anbieten, jedoch nicht Schreibdienste. Der einzige Unterschied zwischen den beiden besteht darin, dass die Beobachtermaschine weder am Wahlerprozess für die Leiterin beteiligt ist noch an der "mehr als die Hälfte der erfolgreichen Schreibabführungen" des Schreibvorgangs beteiligt ist, sodass der Beobachter die Leseleistung des Clusters verbessern kann, ohne die Schreibleistung zu beeinflussen.
2.2 Sitzung
Sitzung bezieht sich auf eine Kundensitzung. Bevor Sie die Kundensitzung erläutern, verstehen wir zunächst die Kundenverbindung. In Zookeeper bezieht sich eine Client -Verbindung auf eine lange TCP -Verbindung zwischen dem Client und dem Zookeeper -Server.
Der Standard -Service -Port von Zookeeper beträgt 2181. Wenn der Client startet, wird eine TCP -Verbindung mit dem Server hergestellt. Ab dem ersten Verbindungsaufbau beginnt auch der Lebenszyklus der Kundensitzung. Durch diese Verbindung kann der Client eine gültige Sitzung mit dem Server über die Erkennung von Herzbecken beibehalten und auch Anforderungen an den Zookeeper -Server senden und Antworten akzeptieren. Gleichzeitig kann es auch über diese Verbindung vom Server Watch -Ereignisbenachrichtigungen vom Server empfangen.
Mit dem SessiontimeOut -Wert der Sitzung wird die Zeitüberschreitungszeit einer Client -Sitzung festgelegt. Wenn die Clientverbindung aufgrund eines übermäßigen Serverdrucks, des Netzwerkausfalls oder eines aktiven Trennung des Clients getrennt wird, solange der Server auf dem Cluster innerhalb der von SessiontimeOut angegebenen Zeit wieder in Verbindung gebracht werden kann, ist die zuvor erstellte Sitzung weiterhin gültig.
2.3 Datenknoten (Znode)
Wenn Sie über Verteilte sprechen, beziehen Sie sich im Allgemeinen "Knoten" auf jede Maschine, die einen Cluster bildet. Der Datenknoten in Zookeeper bezieht sich auf die Dateneinheit im Datenmodell, die als Znode bezeichnet wird. Zookeeper speichert alle Daten im Speicher. Das Datenmodell ist ein Baum (Znode -Baum). Der durch Schrägstriche (/) geteilte Pfad ist ein Znode wie/HBase/Master, wobei HBase und Master beide Znodes sind. Jeder Znode speichert seinen eigenen Dateninhalt, und es wird eine Reihe von Attributinformationen gespeichert.
Notiz:
Der Znode hier kann sowohl als Datei in UNIX als auch als Verzeichnis in UNIX verstanden werden. Da jeder Znode nicht nur Daten selbst schreiben kann (entspricht Dateien in UNIX), sondern auch Dateien oder Verzeichnisse der nächsten Ebene (gleichwertig zu Verzeichnissen in UNIX).
In Zookeeper kann Znode in zwei Kategorien unterteilt werden: anhaltende Knoten und temporäre Knoten.
Anhaltender Knoten
Der sogenannte anhaltende Knoten bedeutet, dass der Znode, sobald dieser Znode erstellt wurde, auf Zookeeper gespeichert wird, es sei denn, der Znode wird aktiv entfernt.
Temporäre Knoten
Der Lebenszyklus eines temporären Knotens ist an die Client -Sitzung gebunden. Sobald die Client -Sitzung fehlschlägt, werden alle von diesem Client erstellten temporären Knoten entfernt.
Darüber hinaus können Benutzer mit Zookeeper auch ein spezielles Attribut hinzufügen: sequentiell zu jedem Knoten. Sobald der Knoten mit diesem Attribut markiert ist, fügt Zookeeper beim Erstellen dieses Knotens nach seinem Knoten automatisch eine Ganzzahl -Nummer hinzu, was eine autoinkrementelle Zahl ist, die vom übergeordneten Knoten verwaltet wird.
Version 2.4
Daten werden auf jedem Znode Zookeeper gespeichert. Zookeeper entspricht jedem Znode und führt eine Datenstruktur bei, die als Statistik bezeichnet wird. ST STRAGE DREI DATEN VERSIONS DIESER ZNODE, nämlich Version (die aktuelle Znode -Version), Cversion (die aktuelle Version der Znode Child Node -Version) und eine Aversion (die aktuelle Znode -ACL -Version).
2.5 Statussinformationen
Neben dem Speichern von Dateninhalten speichert jeder Znode auch einige Statusinformationen des Znode selbst. Verwenden Sie den Befehl GET, um die Inhalts- und Statussinformationen eines bestimmten Znode gleichzeitig zu erhalten. wie folgt:
Zookeeper
In Zookeeper wird das Versionsattribut verwendet, um die "Schreibüberprüfung" im optimistischen Sperrmechanismus zu implementieren (um den atomaren Betrieb verteilter Daten sicherzustellen).
2.6 Transaktionsbetrieb
In Zookeeper wird ein Vorgang, der den Status des Zookeeper -Servers ändern kann, als Transaktionsoperation bezeichnet. Es umfasst im Allgemeinen Vorgänge wie Datenknotenerstellung und -Löhe, Dateninformationsaktualisierung von Dateninhalten, Erstellung von Client -Sitzungen und -ausfällen. Für jede Transaktionsanforderung weist Zookeeper ihm eine weltweit eindeutige Transaktions-ID zu, die von ZXID dargestellt wird, normalerweise eine 64-Bit-Nummer. Jedes ZXID entspricht einer Aktualisierungsoperation, aus der Zookeeper indirekt die globale Reihenfolge identifizieren kann, in der diese Transaktionsbetriebsanforderungen verarbeitet werden.
2.7 Beobachter
Watcher (Event -Listener) ist eine sehr wichtige Funktion in Zookeeper. Mit Zookeeper können Benutzer einige Beobachter an bestimmten Knoten registrieren. Wenn einige bestimmte Ereignisse ausgelöst werden, informiert der Zookeeper -Server das Ereignis dem interessierten Client. Dieser Mechanismus ist ein wichtiges Merkmal von Zookeeper zur Implementierung verteilter Koordinierungsdienste.
2.8 ACL
Zookeeper verwendet die ACL -Richtlinie (Access Control Lists), um die Berechtigungen zu kontrollieren. Zookeeper definiert die folgenden 5 Berechtigungen.
Erstellen: Erlaubnis zum Erstellen von untergeordneten Knoten.
Lesen Sie: Erhalten Sie Berechtigungen für Knotendaten und untergeordnete Knotenliste.
Schreiben: Erlaubnis zum Aktualisieren von Knotendaten.
Löschen: Berechtigungen von Kinderknoten löschen.
Admin: Legen Sie die Berechtigungen für Knoten ACL fest.
Hinweis: Erstellen und Löschen sind beide Berechtigungssteuerungen für untergeordnete Knoten.
3. Typische Anwendungsszenarien von Zookeeper
Zookeeper ist ein hoch verfügbares verteiltes Datenmanagement- und Koordinationsrahmen. Basierend auf der Implementierung des ZAB -Algorithmus kann dieses Rahmen die Konsistenz von Daten in einer verteilten Umgebung sicherstellen. Es basiert auch auf dieser Funktion, die Zookeeper zu einem leistungsstarken Tool zur Lösung des verteilten Konsistenzproblems macht.
3.1 Datenveröffentlichung und Abonnement (Konfigurationszentrum)
Datenveröffentlichung und Abonnement, das sogenannte Konfigurationszentrum, wie der Name schon sagt, ist, dass der Publisher Daten für Abonnenten an den Zookeeper-Knoten veröffentlicht und damit den Zweck des dynamischen Erhalts von Daten und zur Realisierung von zentralem Verwaltungsverwaltungen und dynamischem Update von Konfigurationsinformationen erreicht.
In unserer üblichen Anwendungssystementwicklung begegnen wir häufig auf diese Anforderung: Einige häufige Konfigurationsinformationen sind im System erforderlich, z. B. Informationen zur Maschinenliste, Datenbankkonfigurationsinformationen usw. Diese globalen Konfigurationsinformationen verfügen normalerweise über die folgenden drei Funktionen.
Die Datenmenge ist normalerweise relativ gering.
Der Dateninhalt ändert sich zur Laufzeit dynamisch.
Alle Maschinen im Cluster werden gemeinsam genutzt und die Konfiguration ist konsistent.
Solche globalen Konfigurationsinformationen können auf Zookeeper veröffentlicht werden, sodass der Client (Cluster -Computer) die Nachricht abonniert.
Es gibt im Allgemeinen zwei Entwurfsmodi für Veröffentlichungs-/Abonnementsysteme, nämlich Drücken und Ziehen.
Push: Der Server sendet aktiv Datenaktualisierungen an alle abonnierten Clients.
Pull: Der Client initiiert aktiv eine Anfrage, um die neuesten Daten zu erhalten. Normalerweise nimmt der Kunde eine zeitgesteuerte Umfrag- und Pull -Methode an.
Zookeeper verwendet eine Kombination aus Druck und Zug. wie folgt:
Der Client möchte, dass der Server die Knoten registriert, auf die er achten muss. Sobald sich die Daten des Knotens ändert, sendet der Server eine Beobachterereignisbenachrichtigung an den entsprechenden Client. Nachdem der Client diese Nachrichtenbenachrichtigung erhalten hat, muss er aktiv zum Server gehen, um die neuesten Daten zu erhalten (kombiniert durch Push and Pull).
3.2 Namensservice
Benennungsdienste sind auch eine häufige Art von Szenario in verteilten Systemen. In einem verteilten System können Client -Anwendungen durch Verwendung eines Namensdienstes Informationen wie die Adresse der Ressource oder des Dienstes, des Anbieters usw. basierend auf dem angegebenen Namen erhalten. Benannte Entitäten können in der Regel Maschinen im Cluster, den erbrachten Diensten, Remote -Objekten usw. sein - wir können sie gemeinsam Namen (Name) nennen.
Unter ihnen ist die am häufigsten am häufigsten zuständige Service -Adressliste in einigen verteilten Service -Frameworks (wie RPC, RMI). Durch das Erstellen von sequentiellen Knoten in Zookeeps ist es einfach, einen global eindeutigen Pfad zu erstellen, der als Name verwendet werden kann.
Der Namensnamen von Zookeeper generiert eine weltweit eindeutige ID.
3.3 Verteilte Koordination/Benachrichtigung
Zookeeper verfügt über einen einzigartigen Beobachterregistrierung und einen asynchronen Benachrichtigungsmechanismus, der die Benachrichtigung und Koordination zwischen verschiedenen Maschinen und sogar in einer verteilten Systeme durchaus realisieren und damit die Verarbeitung von Datenänderungen in Echtzeit realisiert. Die Verwendungsmethode ist normalerweise, dass verschiedene Clients denselben Znode auf dem ZK registrieren, um Änderungen im Znode zu hören (einschließlich des Inhalts von Znode selbst und untergeordneten Knoten). Wenn sich der Znode ändert, können alle abonnierten Clients die entsprechende Beobachterbenachrichtigung erhalten und die entsprechende Verarbeitung vornehmen.
Die verteilte Koordination/Benachrichtigung von ZK ist eine gemeinsame Kommunikation zwischen verteilten Systemen und Maschinen.
3.3.1 Erkennung von Herzschlag
Der Herzschlag -Erkennungsmechanismus zwischen Maschinen bedeutet, dass in einer verteilten Umgebung unterschiedliche Maschinen (oder Prozesse) feststellen müssen, ob einander normal läuft. Zum Beispiel muss Maschine A wissen, ob Maschine B normal läuft. In der traditionellen Entwicklung beurteilen wir normalerweise, ob der Gastgeber sich direkt gegenseitig pingen kann. Wenn es komplizierter ist, werden wir einen langen Zusammenhang zwischen Maschinen herstellen und den Herzschlag-Nachweis der Maschinen der oberen Ebene durch den inhärenten Herzschlag-Nachweismechanismus der TCP-Verbindung erkennen. Dies sind sehr häufige Methoden zur Erkennung von Herzschlag.
Schauen wir uns an, wie Sie ZK verwenden, um die Erkennung von Herzschlag zwischen verteilten Maschinen (Prozessen) zu implementieren.
Basierend auf den Eigenschaften der temporären Knoten von ZK können verschiedene Prozesse temporäre untergeordnete Knoten unter einem bestimmten Knoten in ZK erzeugen. Verschiedene Prozesse können direkt beurteilen, ob der entsprechende Prozess basierend auf diesem temporären Kinderknoten lebt. Auf diese Weise müssen die Erkennung und das erkannte System nicht direkt miteinander verbunden sein, sondern über einen bestimmten Knoten am ZK zugeordnet werden, wodurch die Systemkopplung stark reduziert wird.
3.3.2 Arbeitsfortschrittsbericht
In einem gemeinsamen Aufgabenverteilungssystem müssen normalerweise nach der Verteilung der Aufgabe die Ausführung auf verschiedene Maschinen verteilt werden, um den Fortschritt seiner Aufgabenausführung in Echtzeit an das Verteilungssystem zu melden. Diesmal kann es durch ZK erreicht werden. Wählen Sie einen Knoten auf ZK aus, und jeder Task -Client erstellt temporäre untergeordnete Knoten unter diesem Knoten, damit zwei Funktionen erzielt werden können:
Stellen Sie fest, ob die Task -Maschine überlebt, indem Sie beurteilen, ob der temporäre Knoten existiert.
Jede Task -Maschine schreibt den Fortschritt der Aufgabenausführung in Echtzeit in diesen temporären Knoten, damit das zentrale System den Fortschritt der Aufgabenausführung in Echtzeit erhalten kann.
3.4 Meisterwahlen
Master -Wahlen können als das typischste Anwendungsszenario von Zookeeper bezeichnet werden. Zum Beispiel die Wahl des aktiven Namenode in HDFs, die Wahl von aktivem Ressourcenanager im Garn und die Wahl des aktiven HMaster in HBase.
Als Reaktion auf die Anforderungen der Master -Wahl können wir normalerweise die wichtigste Schlüsselfunktion in gemeinsamen relationalen Datenbanken auswählen: Wenn die Maschinen, die Masters werden, einen Aufzeichnung derselben Primärschlüssel -ID in die Datenbank einfügen, hilft uns die Datenbank dabei, Primärschlüsselkonfliktprüfungen durchzuführen, dh nur ein Maschine kann erfolgreich einfügen - wir können dann erfolgreich einfügen.
Wenn Sie sich auf die primären Schlüsselmerkmale von relationalen Datenbanken stützen, kann dies tatsächlich sicherstellen, dass der einzige Master im Cluster gewählt wird.
Aber was soll ich tun, wenn der derzeit gewählte Meister tot ist? Wer wird mir sagen, dass der Meister tot ist? Offensichtlich kann die relationale Datenbank uns nicht über dieses Ereignis informieren. Aber Zookeeper kann es tun!
Durch die starken Konsistenz von Zookeeps kann sichergestellt werden, dass die Erstellung von Knoten die globale Einzigartigkeit bei verteilten hohen Parallelität sicherstellen kann, dh Zookeeper wird sicherstellen, dass der Client keinen vorhandenen Znode erstellen kann.
Das heißt, wenn mehrere Clients beantragt werden, gleichzeitig denselben temporären Knoten zu erstellen, kann am Ende nur eine Clientanforderung erfolgreich erstellt werden. Mit dieser Funktion können Master -Wahlen in einer verteilten Umgebung problemlos durchgeführt werden.
Die Maschine, auf der der Client, der den Knoten erfolgreich erstellt hat, sich befindet, wird zum Meister. Gleichzeitig werden andere Kunden, die den Knoten nicht erfolgreich erstellt haben, einen Beobachter für die Änderung des Knotens für untergeordnete Knoten auf dem Knoten registrieren, um zu überwachen, ob die aktuelle Master -Maschine lebt. Sobald sich der aktuelle Master als tot befindet, werden andere Kunden wieder entscheiden.
Dies ermöglicht die dynamische Wahl des Meisters.
3.5 verteiltes Schloss
Verteilte Schlösser sind eine Möglichkeit, den synchronen Zugriff auf gemeinsame Ressourcen zwischen verteilten Systemen zu steuern.
Verteilte Schlösser werden in exklusive Schlösser und gemeinsam genutzte Schlösser unterteilt.
3.5.1 Exklusive Schloss
Exklusive Schlösser (kurz X -Sperren), auch als Schreibschlösser oder exklusive Schlösser bezeichnet.
Wenn Transaktion T1 dem Data -Objekt O1 eine exklusive Sperre hinzufügt, darf während des gesamten Sperrzeitraums nur Transaktion T1 O1 lesen und aktualisieren, und keine andere Transaktion kann eine Art von Operation für dieses Datenobjekt ausführen (das Objekt kann nicht gesperrt werden), bis T1 die ausschließliche Sperre veröffentlicht.
Es ist zu erkennen, dass der Kern des exklusiven Schlosses darin besteht, sicherzustellen, dass derzeit nur eine Transaktion das Schloss erwirbt. Nachdem das Schloss freigegeben ist, können alle Transaktionen, die darauf warten, das Schloss zu erwerben, benachrichtigt werden.
Wie kann ich Zookeeper verwenden, um ein exklusives Schloss zu erreichen?
Lock definieren
Ein Znode auf Zookeeper kann ein Schloss darstellen. Zum Beispiel kann der Knoten /exklusiv_lock /sperren als Sperre definiert werden.
Das Schloss erhalten
Wie oben erwähnt, betrachten Sie einen Znode auf Zookeeper als Schloss, und das Erhalten des Schlosses wird durch Erstellen eines Znode erreicht. Alle Clients gehen zu /exklusiv_lock /sperren, um temporäre untergeordnete Knoten /exklusiv_lock /sperren unter /exklusiv_lock zu erstellen. Zookeeper wird sicherstellen, dass bei allen Kunden nur ein Kunde erfolgreich erstellt werden kann, und dann kann berücksichtigt werden, dass der Kunde das Schloss erhalten hat. Gleichzeitig müssen alle Clients, die die Sperre nicht erhalten haben, einen Beobachter für Kinderknotenänderungen auf dem Knoten /exklusiv_lock registrieren, um die Änderungen der Sperrenknoten in Echtzeit anzuhören.
Lösen Sie das Schloss
Da /exclusive_lock /lock ein temporärer Knoten ist, ist es möglich, die Sperre in beiden Fällen freizugeben.
Wenn der Client -Computer, der derzeit die Sperre erhält, fehlschlägt oder neu gestartet wird, wird der temporäre Knoten gelöscht und die Sperre wird freigegeben.
Nachdem die Geschäftslogik normal ausgeführt wurde, löscht der Kunde den erstellten temporären Knoten aktiv und löst die Sperre frei.
Unabhängig davon, unter welchen Umständen der Sperrenknoten entfernt wird, benachrichtigt Zookeeper alle Clients, die den Knoten ändern. Nach Erhalt der Benachrichtigung integrieren diese Clients die verteilte Sperrakquisition erneut, dh die "Erwerb von Schlössern" wiederholen.
3.5.2 Shared Lock
Freigegebene Sperren (S -Sperren, die als S -Sperren bezeichnet), auch als Leseschlösser bezeichnet. Wenn die Transaktion T1 dem Data -Objekt O1 eine gemeinsame Sperre hinzufügt, kann T1 nur O1 lesen, und andere Transaktionen können O1 auch gleichzeitig eine gemeinsam genutzte Sperre hinzufügen (nicht ausschließliche Sperre). O1 kann nur zu einem exklusiven Schloss hinzugefügt werden, bis alle gemeinsam genutzten Schlösser auf O1 veröffentlicht werden.
Zusammenfassung: Mehrere Transaktionen können gleichzeitig eine gemeinsame Sperre für ein Objekt erhalten (gleichzeitig gelesen). Wenn es ein gemeinsames Schloss gibt, können Sie keine exklusive Schloss hinzufügen (da das exklusive Schloss ein Schreibschloss ist)
4. Anwendung von Zookeeper in großen verteilten Systemen
Die typischen Anwendungsszenarien von Zookeeper wurden früher eingeführt. In diesem Abschnitt wird die Anwendung von Zookeeper in den gemeinsamen Big Data Products Hadoop und HBase als Beispiele einführen, die allen helfen, die verteilten Anwendungsszenarien von Zookeeper besser zu verstehen.
4.1 Anwendung von Zookeeper in Hadoop
In Hadoop wird Zookeeper hauptsächlich zur Implementierung von HA (Hive -Verfügbarkeit) verwendet, einschließlich HDFS von Namanode und Garns Resourcemanager HA. Gleichzeitig wird Zookeepr in Garn auch verwendet, um den Betriebsstatus der Anwendung zu speichern.
Das Prinzip der Verwendung von Zookeepr zur Implementierung von HA ist in HDFS 'Namanode und Garns Resourcemanager gleich. Daher wird dieser Abschnitt als Beispiel mit Garn vorgestellt.
Zookeeper
Wie aus der obigen Abbildung hervorgeht, besteht Garn hauptsächlich aus vier Teilen: Resourcemanager (RM), NodeManager (NM), ApplicationMaster (AM) und Container. Der Kern von ihnen ist Resourcemanager.
ResourceManager ist für die einheitliche Verwaltung und Zuteilung aller Ressourcen im Cluster verantwortlich. Es empfängt auch Informationen zur Ressourcenberichterstattung von jedem Knoten (NodeManager) und zuteilt diese Informationen jeder Anwendung (Anwendungsmanager) gemäß bestimmten Richtlinien. Es verwaltet die ApplicationMaster -Informationen, die NodeManager -Informationen und die Ressourcenverbrauchsinformationen jeder Anwendung.
Um HA zu implementieren, müssen mehrere Ressourcenager koexistieren (normalerweise zwei), und nur ein Ressourcenanager befindet sich im aktiven Zustand, während sich die anderen im Standby -Zustand befinden. Wenn der aktive Knoten nicht ordnungsgemäß funktionieren kann (z. B. Maschinenausfallzeiten oder Neustart), konkurriert der Standby um einen neuen aktiven Knoten.
4.2 Haupt- und Sicherungsschalter
Schauen wir uns an, wie Garn die Master-Subventionierung zwischen mehreren Ressourcenagern implementiert.
1. Erstellen Sie einen Schließknoten. Auf Zookeeper gibt es einen A /Garn-Leader-Wahlen /Appcluster-Marn-Lock-Knoten. Wenn alle Ressourcenager gestartet werden, werden sie sich um einen Lock Child Node/Garn-Leader-Wahlen/Appcluster-Yarn/ActiveBeadcrumb konkurrieren. Dieser Knoten ist ein temporärer Knoten.
Zookeepr kann sicherstellen, dass am Ende nur ein Ressourcenanager erfolgreich erstellt werden kann. Der erfolgreich erstellte Ressourcenanager wird in den aktiven Zustand umgestellt, während diejenigen, die nicht erfolgreich waren, in den Standby -Zustand umgestellt werden.
Zookeeper
Sie können sehen, dass RessourcenManager2 im Cluster zu diesem Zeitpunkt aktiv ist.
Registrieren Sie den Beobachtermonitor
Alle Ressourcenager in Standby-Staaten registrieren einen Beobachter für den Knotenwechsel zum/Garn-Leader-Wahlen/Appcluster-Yarn/ActiveBeadcrumb-Knoten. Mit den Eigenschaften temporärer Knoten können Sie den Betrieb von Ressourcenagern in aktiven Zuständen schnell erfassen.
Haupt- und Sicherungsschalter
Wenn ein Active State ResourceManager eine Ausnahme wie eine Ausfallzeit oder einen Neustart hat, ist die mit Zookeeper angeschlossene Client-Sitzung ungültig, sodass der Knoten mit/yarn-Leader-Wahlen/Appcluster-Yarn/ActiveBreadcrumb-Knoten gelöscht wird. Zu diesem Zeitpunkt erhalten die anderen Ressourcenager im Standby -Status die Beobachterereignisbenachrichtigung vom Zookeeper -Server und wiederholen dann den Betrieb von Schritt 1.
Das obige ist der Prozess der Verwendung von Zookeeper, um die Haupt- und Sicherungswechsel von Resourcemanager zu realisieren, die den HA von Resourcemanager realisiert.
Das Implementierungsprinzip des Namenode HA in HDFS entspricht dem Implementierungsprinzip des Ressourcenanageres HA im Garn. Sein Schleusenknoten ist/hadoop-ha/mycluster/activeBeadcrumb.
4.3 Ressourcenmanager -Statusspeicher
In ResourceManager kann RMStatESTORE einige interne staatliche Informationen zu RM speichern, einschließlich der Anwendung und deren Versuchsinformationen, Delegationstoken, Versionsinformationen usw. Im Speicherkonstruktionsschema werden drei mögliche Implementierungen wie folgt bereitgestellt.
Basierend auf der Speicherimplementierung wird es im Allgemeinen für die tägliche Entwicklung und Tests verwendet.
Dateisystembasierte Implementierungen wie HDFs.
Basierend auf der Implementierung von Zookeeper.
Da die Datenmenge dieser staatlichen Informationen nicht sehr groß ist, empfiehlt Hadoop offiziell, dass sie die Speicherung staatlicher Informationen auf der Grundlage von Zookeeper erkennt. Auf Zookeepr werden die Statussinformationen des Resourcemanager unter dem Stammknoten von /rmstore gespeichert.
Zookeeper
Der RMUCPOOT -Knoten speichert Informationen zu jeder Anwendung, und die RMDTSecretManagerRoot -Informationen zu Sicherheit und anderen Informationen. Der Resourcemanager jedes aktiven Zustands liest diese Statussinformationen während der Initialisierungsphase von Zookeeper und verarbeitet weiterhin entsprechend auf diesen Statussinformationen.
4.4 Zusammenfassung:
Die Hauptanwendungen von Zookeepr in Hadoop sind:
HA von Namenode in HDFs und HA von Resourcemanager in Garn.
Speichern Sie die RMStatestore -Statusinformationen
5. Anwendung von Zookeeper in HBase
HBase verwendet hauptsächlich Zookeper
Splitwal Task Management usw.
5.1 HMASTER -Wahl- und Hauptsicherungsschalter
Das Prinzip der Hmaster-Wahl und des Master-Support-Umschusses entspricht dem HA-Prinzip von Namenode in HDFs und Resourcemanager in Garn.
5.2 Systemfehlertoleranz
Wenn HBase gestartet wird, erstellt jeder Regionserver einen Informationsknoten unter dem Knoten/HBase/RS -Knoten von Zookeeper (im Folgenden nennen wir diesen Knoten einen "RS -Statusknoten") wie/hbase/rs/[Hostname]. Gleichzeitig wird sich HMaster diesen Knoten registrieren und hören. Wenn ein Regionserver fehlschlägt, löscht Zookeeper den RS -Statusknoten, der dem RegionServer -Server entspricht, da er seinen Herzschlag für einen bestimmten Zeitraum nicht akzeptieren kann (d. H. Die Sitzung ist ungültig).
Gleichzeitig erhält HMaster eine Nodedelete-Benachrichtigung von Zookeeper, wodurch ein Knoten getrennt ist und sofort fehlertolerante Arbeiten beginnt.
Warum lässt HBase HMaster nicht direkt für die Überwachung der RegionServer verantwortlich sein? Wenn Hmaster den Status des Regionservers durch Herzschlagmechanismen direkt verwaltet, da der Cluster immer größer wird, wird die Managementlast von HMaster schwerer und kann auch fehlschlagen, sodass die Daten bestehen müssen. In diesem Fall wird Zookeeper zur idealen Wahl.
5.3 Rootregion -Management
Für HBase -Cluster werden die Standortinformationen der Datenspeicherung in der Metadatenregion aufgezeichnet, dh der Stammregion. Jedes Mal, wenn der Client eine neue Anfrage initiiert und den Ort der Daten kennen muss, wird er die Rootregion abfragen, und der eigene Standort des Rootregion wird auf Zookeeper aufgezeichnet (standardmäßig wird er im Zookeeper-Knoten von Zookeeper /HBase /Meta-Region-Server aufgezeichnet).
Wenn sich die Rootregion ändert, wie z. B. manuelle Bewegung des Region, das Wiederladen des Ausgleichs oder ein Ausfall des Rootregion -Servers, kann diese Änderung durch Zookeeper erkennen und eine Reihe entsprechender Disaster -Wiederherstellungsmaßnahmen durchführen, um sicherzustellen, dass der Client immer die richtigen Rootregion -Informationen erhalten kann.
5.4 Region Management
Regionen in HBase werden oft geändert. Die Gründe für diese Änderungen sind Systemausfälle, Lastausgleich, Konfigurationsänderung, Regionspaltung und Verschmelzung usw. Sobald sich die Region bewegt, durchläuft sie den Prozess von Offline und Online.
Daten können während der Offline nicht zugegriffen werden, und diese Zustandsänderung in der Region muss auf globaler Ebene bekannt sein, ansonsten können Transaktionsausnahmen auftreten.
Für große HBase -Cluster kann die Anzahl der Regionen bis zu 100.000 oder sogar mehr betragen. Es ist auch eine gute Wahl, das Regionsstaat Management in dieser Skala Zookeeper zu überlassen.
5.5 Distributed Splitwal Task Management
Wenn ein RegionServer -Server aufgehängt wird, da es immer einen Teil der neu geschriebenen Daten gibt, die bei der Migration des RegionServer -Dienstes nicht in die HFILE aufgenommen wurden, besteht eine wichtige Aufgabe darin, diesen Teil der Daten wiederherzustellen, die sich noch im Speicher aus dem Wal befinden. Der kritischste Schritt in diesem Teil der Arbeit ist Splitwal, dh der HMaster muss den Wal des RegionServer -Servers durchqueren, in kleine Stücke unterteilen und an die neue Adresse verschieben und das Protokoll wiederholen.
Da das Protokollvolumen eines einzelnen Regionservers relativ groß ist (es kann Tausende von Regionen mit GB von Protokollen geben), hoffen Benutzer häufig, dass das System die Log -Wiederherstellungsarbeiten schnell abschließen kann. Daher besteht eine praktikable Lösung darin, diese Aufgabe zuzuordnen, die Wal mit mehreren Regionserver-Servern für die Zusammenarbeit übernimmt. Dies erfordert eine anhaltende Komponente, um Hmaster bei der Abschluss der Aufgabenallokation zu unterstützen.
Die aktuelle Praxis ist, dass HMaster einen Splitwal -Knoten auf Zookeeper erstellt (standardmäßig ist es /Hbase /Splitwal -Knoten), Informationen wie "Welche Regionserver, die Region, welche Region" auf dem Knoten in einer Liste, in einer Liste in einer Liste erstellt, und dann wird jeder Regionserver -Server, um die Aufgaben zu sammeln, und die Aufgaben. Zookeeper spielt hier die Rolle der gegenseitigen Benachrichtigung und der Informationsdauer in verteilten Clustern.
5.6 Zusammenfassung:
Die oben genannten sind einige typische Szenarien in HBase, die auf Zookeeper stützen, um verteilte Koordinationsfunktionen zu vervollständigen. Tatsächlich hat HBase mehr als diese Abhängigkeit von Zookeeper. Beispielsweise verlässt sich HMaster auch auf Zookeeper, um den Statusdatensatz der Tabelle aktivieren/zu deaktivieren, und fast alle Metadatenspeicher in HBase werden auf Zookeeper platziert.
Aufgrund der hervorragenden verteilten Koordinierungsfunktionen und des guten Benachrichtigungsmechanismus von Zookeeper hat HBase in der Entwicklung jeder Version zunehmend Zookeeper -Anwendungsszenarien hinzugefügt, und aus der Trendperspektive haben die beiden immer mehr Kreuzungen. Alle Operationen auf Zookeeper in HBase sind im org.apache.hadoop.hbase.zookeeper -Paket eingekapselt. Interessierte Schüler können es selbst studieren.
Das obige ist das Spring -Boot -Modul, das der Editor Ihnen vorgestellt hat. Ich hoffe, es wird Ihnen hilfreich sein. Wenn Sie Fragen haben, hinterlassen Sie mir bitte eine Nachricht und der Editor wird Ihnen rechtzeitig antworten!