Zookeeper ist ein Teilprojekt von Hadoop, und obwohl es von Hadoop abgeleitet ist, habe ich festgestellt, dass Zookeeper zunehmend verteilte Frameworks außerhalb von Hadoop verwendet. Heute möchte ich über Zookeeper sprechen. Dieser Artikel wird nicht darauf eingehen, wie man Zookeeper verwendet, sondern welche praktischen Anwendungen Zookeeper nutzen, welche Anwendungen die Vorteile von Zookeeper nutzen können, und schließlich die Rolle von Zookeeper in der verteilten Website-Architektur eingehen.
Zookeeper ist ein äußerst zuverlässiges Koordinationssystem für große verteilte Systeme. Aus dieser Definition wissen wir, dass Zookeeper ein koordiniertes System ist, das auf verteilten Systemen wirkt. Warum benötigen verteilte Systeme ein Koordinationssystem? Die Gründe sind wie folgt:
Die Entwicklung eines verteilten Systems ist eine sehr schwierige Sache, und die Schwierigkeit spiegelt sich hauptsächlich im "teilweisen Ausfall" des verteilten Systems wider. "Teilfehler" bezeichnet die Übertragung von Informationen zwischen zwei Netzwerkknoten: Wenn das Netzwerk ausfällt, kann der Sender nicht wissen, ob der Empfänger die Nachricht empfangen hat, und die Ursache dieses Ausfalls ist komplex, der Empfänger hat die Nachricht möglicherweise vor dem Netzwerkfehler empfangen oder auch nicht, oder der Prozess des Empfängers ist tot. Die einzige Möglichkeit, wie der Sender das echte Bild bekommen kann, besteht darin, sich wieder mit dem Empfänger zu verbinden und ihn zu fragen, warum der Fehler aufgetreten ist – was das "partielle Ausfall"-Problem in der Entwicklung verteilter Systeme ist.
Zookeeper ist der Rahmen zur Lösung des "teilweisen Fehlers" verteilter Systeme. Zookeeper ermöglicht es verteilten Systemen nicht, "partielle Fehler"-Probleme zu vermeiden, erlaubt es jedoch verteilten Systemen, solche Probleme bei partiellen Ausfällen korrekt zu behandeln, sodass verteilte Systeme normal funktionieren können.
Sprechen wir über die praktische Nutzung von Zookeeper:
Szenario 1: Es gibt eine Gruppe von Servern, die einen bestimmten Dienst für den Client bereitstellen (zum Beispiel ist die Serverseite der zuvor erstellten verteilten Website ein Cluster, der aus vier Servern besteht, um dem Frontend-Cluster Dienste bereitzustellen), und wir hoffen, dass der Client jedes Mal, wenn der Client ihn anfordert, einen Server im Server-Cluster findet, sodass der Server dem Client die vom Client benötigten Dienste bereitstellen kann. Für dieses Szenario müssen wir eine Liste von Servern in unserem Programm haben, aus der wir jedes Mal die Liste der Server lesen, wenn der Client sie anfordert. Dann kann diese Unterliste natürlich nicht auf einem einzelnen Node-Server gespeichert werden, sonst hängt der Knoten auf und der gesamte Cluster fällt aus, und wir hoffen, dass diese Liste zu diesem Zeitpunkt sehr verfügbar sein wird. Wenn ein Server in der Speicherliste defekt ist, können andere Server den defekten Server sofort ersetzen, und der defekte Server kann aus der Liste entfernt werden, sodass der ausgefallene Server sich aus dem Betrieb des gesamten Clusters zurückziehen kann und all diese Operationen nicht vom ausgefallenen Server, sondern vom normalen Server im Cluster betrieben werden. Dies ist eine aktive verteilte Datenstruktur, die den Zustand von Datenelementen aktiv verändern kann, wenn sich externe Bedingungen ändern. Das Zookeeper-Framework bietet diesen Service an. Der Name dieses Dienstes lautet: Unified Naming Service, der dem JNDI-Dienst in javaEE sehr ähnlich ist.
Szenario 2: Verteilter Lock-Service. Wenn ein verteiltes System Daten bearbeitet, wie zum Beispiel das Lesen von Daten, die Analyse von Daten und schließlich das Ändern von Daten. Im verteilten System können diese Operationen auf verschiedene Knoten im Cluster verteilt werden, dann gibt es ein Konsistenzproblem im Datenbetriebsprozess. Wenn dieser inkonsistent ist, erhält man ein falsches Operationsergebnis. In einem einzelnen Prozessprogramm ist das Problem der Konsistenz leicht zu lösen, aber es ist schwieriger, das verteilte System zu erreichen, da die Operationen der verschiedenen Server im verteilten System in unabhängigen Prozessen stattfinden und die Zwischenergebnisse und Prozesse des Betriebs über das Netzwerk übertragen werden müssen. Dann ist es viel schwieriger, die Konsistenz der Datenoperationen zu erreichen. Zookeeper bietet einen Sperrdienst, der dieses Problem löst und es uns ermöglicht, die Konsistenz der Datenoperationen bei verteilten Datenoperationen sicherzustellen.
Szenario 3: Konfigurationsmanagement. In einem verteilten System setzen wir eine Serviceanwendung separat auf n Server aus, und die Konfigurationsdateien dieser Server sind gleich (zum Beispiel gibt es im von mir entworfenen Frameworks für verteilte Webseiten 4 Server auf der Serverseite, die Programme auf den 4 Servern sind gleich und die Konfigurationsdateien sind gleich). Wenn sich die Konfigurationsoptionen der Konfigurationsdateien ändern, müssen wir diese Dateien einzeln ändern; wenn wir die Server relativ klein ändern müssen, sind diese Operationen nicht allzu problematisch, Wenn wir eine große Anzahl verteilter Server haben, wie zum Beispiel der Hadoop-Cluster eines großen Internetunternehmens mit Tausenden von Servern, kann das Ändern der Konfigurationsoptionen problematisch und gefährlich sein. Zu diesem Zeitpunkt kann Zookeeper nützlich sein: Wir können Zookeeper als hochverfügbaren Konfigurationsspeicher nutzen, so etwas zur Verwaltung an Zookeeper übergeben, die Konfigurationsdatei des Clusters auf einen Knoten im Dateisystem des Zookeepers kopieren und dann Zookeeper nutzen, um den Status der Konfigurationsdatei in allen verteilten Systemen zu überwachen, sobald festgestellt wird, dass sich die Konfigurationsdatei geändert hat, Jeder Server erhält eine Benachrichtigung von Zookeeper, um die Konfigurationsdateien in Zookeeper zu synchronisieren, und der Zookeeper-Dienst stellt außerdem sicher, dass die Synchronisationsoperation atomar ist, damit die Konfigurationsdatei jedes Servers korrekt aktualisiert wird.
Szenario 4: Bereitstellung von Fehlerbehebungsfunktionen für verteilte Systeme. Das Clustermanagement ist schwierig, und die Integration des Zookeeper-Dienstes in das verteilte System erleichtert die Verwaltung des Clusters. Das Problematischste bei der Clusterverwaltung ist das Knotenfehlermanagement: Zookeeper kann dem Cluster erlauben, einen gesunden Knoten als Master auszuwählen, der Masterknoten kennt den aktuellen Gesundheitsstatus jedes Servers im Cluster; sobald ein Knoten ausfällt, benachrichtigt der Master die anderen Server im Cluster, um die Rechenaufgaben der verschiedenen Knoten neu zu verteilen. Zookeeper kann nicht nur Fehler finden, sondern auch den fehlerhaften Server überprüfen, sehen, um welche Art von Fehlerserver es sich handelt; wenn der Fehler behoben werden kann, kann Zookeeper automatisch den Fehlergrund beheben oder dem Systemadministrator mitteilen, damit der Administrator das Problem schnell finden und den Fehler des Knotens beheben kann. Du hast vielleicht trotzdem eine Frage: Was soll ich tun, wenn der Master defekt ist? Zookeeper berücksichtigt das ebenfalls: Zookeeper hat einen internen "Algorithmus zur Wahl von Leitern", Masters können dynamisch ausgewählt werden, und wenn der Master fehlschlägt, kann Zookeeper sofort einen neuen Master auswählen, der den Cluster verwaltet.
Lassen Sie uns über die Funktionen von Zookeeper sprechen:
ZooKeeper ist ein schlankes Dateisystem. Das ist etwas ähnlich wie Hadoop, aber das ZooKeeper-Dateisystem verwaltet kleine Dateien, während Hadoop sehr große Dateien verwaltet.
Zookeeper bietet eine Fülle von "Artefakten", die viele Operationen zur Koordinierung von Datenstrukturen und Protokollen ermöglichen. Zum Beispiel: verteilte Warteschlangen, verteilte Sperren und der "Leader Election"-Algorithmus einer Gruppe von Knoten auf derselben Ebene.
ZooKeeper ist hoch verfügbar, seine eigene Stabilität ist recht gut, verteilte Cluster können auf das Management von Zookeeper-Clustern angewiesen sein, und ZooKeeper wird eingesetzt, um das Problem des Einzelausfalls verteilter Systeme zu vermeiden.
Zookeeper verwendet einen lose gekoppelten Interaktionsmodus. Dies zeigt sich am deutlichsten darin, dass Zookeeper verteilte Schlösser bereitstellt, die als Terminvereinbarungsmechanismus genutzt werden können, um teilnehmenden Prozessen zu ermöglichen und miteinander zu interagieren, ohne die anderen Prozesse (oder das Netzwerk) zu kennen, und die teilnehmenden Parteien müssen nicht einmal gleichzeitig existieren, solange sie eine Nachricht in Zookeeper hinterlassen, und nachdem der Prozess beendet ist, kann ein anderer Prozess diese Nachricht lesen und so die Beziehung zwischen den Knoten entkoppeln.
ZooKeeper stellt ein gemeinsames Repository für den Cluster bereit, aus dem der Cluster zentral gemeinsame Informationen lesen und schreiben kann, wodurch die Programmierung gemeinsamer Operationen für jeden Knoten vermieden und die Entwicklungsschwierigkeit verteilter Systeme reduziert wird.
Zookeeper ist hauptsächlich dafür verantwortlich, die Daten zu speichern und zu verwalten, die allen wichtig sind, und dann die Registrierung der Beobachter zu akzeptieren; sobald sich der Status dieser Daten ändert, wird Zookeeper dafür verantwortlich sein, die Beobachter, die sich bei Zookeeper registriert haben, zu benachrichtigen, damit sie entsprechend reagieren, um einen Master/Slave-Management-Modus ähnlich dem Cluster zu erreichen.
Man sieht, dass Zookeeper sehr förderlich für die Entwicklung verteilter Systeme ist, was verteilte Systeme robuster und effizienter machen kann.
Vor nicht allzu langer Zeit habe ich an der Hadoop-Interessengruppe der Abteilung teilgenommen und Hadoop, Mapreduce, Hive und Hbase in der Testumgebung installiert und Zookeeper im Voraus installiert, als ich Hbase installiert habe. Zookeeper kann Dienste bereitstellen, sodass mehr als die Hälfte der drei Server 2 ist und mehr als die Hälfte der 4 ebenfalls zwei, sodass die Installation von drei Servern den Effekt von 4 Servern erzielen kann. Im Prozess des Lernens von Hadoop habe ich das Gefühl, dass Zookeeper das schwierigste Teilprojekt zu verstehen ist; der Grund ist nicht, dass es technisch verantwortlich ist, sondern dass die Anwendungsrichtung für mich sehr verwirrend ist. Deshalb beginnt mein erster Artikel über Hadoop-Technologie mit Zookeeper und spricht nicht über spezifische technische Implementierungen, aber aus den Anwendungsszenarien von Zookeeper verstehe ich das Feld der Zookeeper-Anwendung; ich denke, das Lernen von Zookeeper wird mit der Hälfte des Engagements effektiver sein.
Der Grund, warum ich heute über Zookeeper sprechen möchte, ist, das Framework für verteilte Webseiten in meinem vorherigen Artikel zu ergänzen. Obwohl ich die Website-Architektur als verteilte Struktur entworfen habe, habe ich auch einen einfachen Fehlerbehandlungsmechanismus entwickelt, wie zum Beispiel den Heartbeat-Mechanismus, aber es gibt immer noch keine Möglichkeit, den Single Point of Failure des Clusters zu lösen; wenn ein Server defekt ist, versucht der Client, sich mit diesem Server zu verbinden, was zu der Blockierung einiger Anfragen und zur Verschwendung von Serverressourcen führt. Im Moment möchte ich mein Framework jedoch nicht ändern, weil ich immer das Gefühl habe, dass das Hinzufügen von Zookeeper-Diensten zu bestehenden Diensten die Effizienz der Website beeinträchtigen würde. Glücklicherweise hat auch unsere Abteilung ein solches Problem festgestellt: Unsere Abteilung wird ein leistungsstarkes Remote-Call-Framework entwickeln, das Clustermanagement und das Kommunikationsmanagement trennen und effiziente, verfügbare Dienste zentral bereitstellen.
Versetzt von ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Veröffentlicht am 18.07.2017 14:19:01
|
|
|
