![[Empfohlene Sammlung] Seelenfolter! Die 31-Schuss-Kanone des Tierpflegers](https://img.php.cn/upload/article/001/273/727/77277e0c45b71f73ee319bcf8a6ed2e7-0.png)
Wie viele Antworten kannst du geben?
ZooKeeper ist ein verteilter Open-Source-Koordinierungsdienst. Es handelt sich um eine Software, die Konsistenzdienste für verteilte Anwendungen bereitstellt. Verteilte Anwendungen können Aufgaben wie Datenveröffentlichung/-abonnement, Lastausgleich, Benennungsdienst, verteilte Koordination/Benachrichtigung, Clusterverwaltung, Master-Wahl, verteilte Sperren und verteilte Warteschlangen sowie andere Funktionen implementieren.
Das Ziel von ZooKeeper besteht darin, komplexe und fehleranfällige Schlüsseldienste zu kapseln und Benutzern einfache und benutzerfreundliche Schnittstellen sowie ein System mit effizienter Leistung und stabilen Funktionen bereitzustellen.
Zookeeper garantiert die folgenden verteilten Konsistenzfunktionen:
Die Lektüre des Kunden Die Anfrage kann von jedem Computer im Cluster verarbeitet werden. Wenn für die Leseanforderung ein Listener auf dem Knoten registriert ist, wird dieser Listener auch vom verbundenen Zookeeper-Computer verarbeitet. Bei Schreibanfragen werden diese Anfragen gleichzeitig an andere Zookeeper-Maschinen gesendet und erst nach Erreichen eines Konsenses wird die Anfrage erfolgreich zurückgegeben. Wenn daher die Anzahl der Zookeeper-Cluster-Maschinen zunimmt, steigt der Durchsatz der Leseanforderungen, der Durchsatz der Schreibanforderungen nimmt jedoch ab.
Ordnung ist eine sehr wichtige Funktion in Zookeeper. Alle Updates werden global geordnet. Dieser Zeitstempel heißt zxid (Zookeeper-Transaktions-ID). Die Leseanforderung ist nur in der Reihenfolge der Aktualisierung, das heißt, das Rückgabeergebnis der Leseanforderung enthält die neueste ZXID des Zookeepers.
Der Kern von Zookeeper ist der atomare Broadcast-Mechanismus, der die Synchronisierung zwischen Servern gewährleistet. Das Protokoll, das diesen Mechanismus implementiert, wird Zab-Protokoll genannt. Das Zab-Protokoll verfügt über zwei Modi, nämlich den Wiederherstellungsmodus und den Broadcast-Modus.
Wenn der Dienst startet oder nachdem der Anführer abstürzt, wechselt Zab in den Wiederherstellungsmodus. Wenn der Anführer ausgewählt wird und die meisten Server die Statussynchronisierung mit dem Anführer abschließen, endet der Wiederherstellungsmodus. Durch die Statussynchronisierung wird sichergestellt, dass Leader und Server denselben Systemstatus haben.
Sobald der Anführer seinen Status mit der Mehrheit der Follower synchronisiert hat, kann er mit dem Senden von Nachrichten beginnen, d. h. er wechselt in den Broadcast-Status. Wenn zu diesem Zeitpunkt ein Server dem ZooKeeper-Dienst beitritt, startet er im Wiederherstellungsmodus, erkennt den Anführer und synchronisiert seinen Status mit dem Anführer. Wenn die Synchronisierung abgeschlossen ist, nimmt es auch an der Nachrichtenübertragung teil. Der ZooKeeper-Dienst bleibt im Broadcast-Status, bis der Anführer abstürzt oder der Anführer den größten Teil seiner Follower-Unterstützung verliert.
Zookeeper ermöglicht es dem Client, einen Watcher bei einem Znode auf dem Server zu registrieren. Wenn bestimmte Ereignisse auf dem Server diesen Watcher auslösen, sendet der Server eine Nachricht An den angegebenen Client wird eine Ereignisbenachrichtigung verwendet, um die verteilte Benachrichtigungsfunktion zu implementieren. Anschließend nimmt der Client Geschäftsänderungen basierend auf dem Watcher-Benachrichtigungsstatus und dem Ereignistyp vor. Folgen Sie gerne der „Interview-Kolumne“, um weitere Tipps für Vorstellungsgespräche zu erhalten.
Arbeitsmechanismus:
(1) Client registriert Beobachter
(2) Server verarbeitet Beobachter
(3) Client ruft Beobachter zurück
Beobachter Funktionsübersicht:
(1) Einmalig
Ganz egal ein Dienst Egal, ob es sich um den Client oder den Client handelt: Sobald ein Watcher ausgelöst wird, entfernt Zookeeper ihn aus dem entsprechenden Speicher. Dieses Design reduziert effektiv den Druck auf den Server. Andernfalls sendet der Server bei Knoten, die sehr häufig aktualisiert werden, kontinuierlich Ereignisbenachrichtigungen an den Client, was sowohl das Netzwerk als auch den Server stark belastet.
(2) Serielle Client-Ausführung
Der Prozess des Client-Watcher-Rückrufs ist ein serieller Synchronisationsprozess.
(3) Lightweight
3.1. Die Watcher-Benachrichtigung ist sehr einfach. Sie teilt dem Kunden nur mit, dass ein Ereignis aufgetreten ist, erklärt jedoch nicht den spezifischen Inhalt des Ereignisses.
3.2. Wenn der Client einen Watcher beim Server registriert, übergibt er die tatsächliche Watcher-Objektentität des Clients nicht an den Server. Sie wird in der Clientanforderung nur mit einem booleschen Typattribut gekennzeichnet.
(4) Watcher-Ereignis wird asynchron gesendet
Das Watcher-Benachrichtigungsereignis wird asynchron vom Server an den Client gesendet. Dies führt zu einem Problem, das durch Netzwerkverzögerungen oder andere Faktoren verursacht werden kann. Der Client überwacht Ereignisse zu nicht verfügbaren Zeiten, da Zookeeper selbst eine Bestellgarantie bietet, d. h. erst nachdem der Client das Ereignis überwacht hat, erkennt er Änderungen im überwachten Znode. Wenn wir Zookeeper verwenden, können wir daher nicht erwarten, jede Änderung des Knotens überwachen zu können. Zookeeper kann nur eine letztendliche Konsistenz garantieren, jedoch keine starke Konsistenz.
(5) Watcher „getData“ registrieren, existiert, „getChildren“
(6) Watcher „erstellen, löschen, setData“ auslösen
(7) Wenn ein Client eine Verbindung zu einem neuen Server herstellt, wird die Überwachung durch jedes Sitzungsereignis ausgelöst. Wenn die Verbindung zu einem Server unterbrochen wird, können keine Uhren empfangen werden. Wenn sich der Client erneut verbindet, werden bei Bedarf alle zuvor registrierten Uhren erneut registriert. Normalerweise ist dies völlig transparent. Es gibt nur einen Sonderfall, in dem eine Überwachung verloren gehen kann: Bei einer vorhandenen Überwachung auf einem nicht erstellten Knoten kann dieses Überwachungsereignis verloren gehen, wenn sie erstellt wurde, während die Verbindung zum Client getrennt und anschließend gelöscht wurde.
(1) Rufen Sie die drei APIs getData()/getChildren()/exist() auf und übergeben Sie das Watcher-Objekt
(2) Markieren Sie die Anfrage Anfrage, kapseln Sie den Watcher in WatchRegistration
(3) Kapseln Sie ihn in ein Packet-Objekt, senden Sie die Anfrage an den Server
(4) Nachdem Sie die Antwort vom Server erhalten haben, registrieren Sie den Watcher bei ZKWatcherManager zur Verwaltung
(5) Die Anfrage wird zurückgegeben und die Registrierung ist abgeschlossen.
(1) Der Server empfängt den Watcher und speichert ihn
Empfängt die Client-Anfrage, verarbeitet die Anfrage, um festzustellen, ob der Watcher registriert werden muss, und Bei Bedarf werden der Datenknotenknotenpfad und ServerCnxn (ServerCnxn stellt eine Verbindung zwischen Client und Server dar, implementiert die Prozessschnittstelle von Watcher und kann zu diesem Zeitpunkt als Watcher-Objekt betrachtet werden) in WatchTable und watch2Paths von WatcherManager gespeichert . 2) Watcher-Trigger Pfad zu einem WatchedEvent-Objekt
2.4 Suchen; extrahieren und löschen Sie den entsprechenden Watcher aus WatchTable und Watch2Paths (hier ist ersichtlich, dass der Watcher einmalig auf der Serverseite ist und nach einmaligem Auslösen ungültig wird)
(3) Rufen Sie die Prozessmethode auf Den Watcher auslösen
Hier ist der Prozess. Der Hauptzweck besteht darin, Watcher-Ereignisbenachrichtigungen über die TCP-Verbindung zu senden, die ServerCnxn entspricht.
Der SendThread-Thread des Clients empfängt die Ereignisbenachrichtigung und der EventThread-Thread ruft den Watcher zurück.
Der Watcher-Mechanismus des Clients ist ebenfalls einmalig. Sobald er ausgelöst wird, wird der Watcher ungültig.
UGO (Benutzer/Gruppe/Andere)
wird derzeit in Linux/Unix-Dateisystemen verwendet und ist auch die am weitesten verbreitete Methode zur Berechtigungskontrolle. Es handelt sich um einen grobkörnigen Dateisystem-Berechtigungskontrollmodus.
ACL (Access Control List) Zugriffskontrollliste
umfasst drei Aspekte:
(1) IP: Berechtigungskontrolle anhand der IP-Adressgranularität
(2) Digest: Am häufigsten Verwendet werden Berechtigungen mithilfe von Berechtigungskennungen ähnlich wie Benutzername:Passwort konfiguriert, was zur Unterscheidung verschiedener Anwendungen zur Berechtigungskontrolle geeignet ist
(3) Welt: Die offenste Berechtigungskontrollmethode, ein spezieller Digest-Modus mit nur einer Berechtigungsidentifikation „Welt: Jeder“
(4) Super: Superuser
Das Autorisierungsobjekt bezieht sich auf den Benutzer oder eine bestimmte Entität, der die Berechtigung erteilt wurde, beispielsweise eine IP-Adresse oder eine Maschinenleuchte.
(1) CREATE: Berechtigung zum Erstellen von Datenknoten, die es autorisierten Objekten erlaubt, unter diesem Znode untergeordnete Knoten zu erstellen
(2) DELETE: Berechtigung zum Löschen von untergeordneten Knoten, die es autorisierten Objekten erlaubt, die untergeordneten Knoten dieser Daten zu löschen Knoten Knoten
(3) LESEN: Leseberechtigung des Datenknotens, wodurch das autorisierte Objekt auf den Datenknoten zugreifen und dessen Dateninhalt oder Unterknotenliste usw. lesen kann.
(4) SCHREIBEN: Aktualisierungsberechtigung der Daten Knoten, der es dem autorisierten Objekt ermöglicht, Aktualisierungsvorgänge durchzuführen Feature
12. Kennen Sie sich mit der Sitzungsverwaltung aus?
Bucketing-Strategie: Legen Sie ähnliche Sitzungen zur Verwaltung in den gleichen Block, damit Zookeeper Sitzungen in verschiedenen Blöcken und im gleichen Block isolieren kann.(1) Der einzige Planer und Prozessor von Transaktionsanforderungen, der die Reihenfolge der Cluster-Transaktionsverarbeitung sicherstellt. (2) Der Planer jedes Dienstes innerhalb des Clusters
Follower
(1) Nicht-Transaktionsanfragen von Clients verarbeiten und Transaktionsanfragen an den Leader-Server weiterleiten
(2) An der Abstimmung von Transaktionsanforderungsvorschlägen teilnehmen
(3) An der Leader-Wahlabstimmung teilnehmen
Observer
(1) Version 3.0 Eine Serverrolle wird später eingeführt, um die Nicht-Transaktionsverarbeitungsfunktionen des Clusters zu verbessern, ohne die Transaktionsverarbeitungsfunktionen des Clusters zu beeinträchtigen
(2) Verarbeiten Sie die Nicht-Transaktionsanforderungen des Clients und leiten Sie Transaktionsanforderungen an den weiter Leader-Server
(3) Nehmen Sie an keiner Form der Abstimmung teil
14. Server-Arbeitsstatus unter Zookeeper(2) FOLGEND: Follower-Status. Zeigt an, dass die aktuelle Serverrolle „Follower“ ist.
(3) FÜHREND: Führungsstatus. Zeigt an, dass die aktuelle Serverrolle Leader ist.
(4) BEOBACHTEN: Beobachterstatus. Gibt an, dass die aktuelle Serverrolle Beobachter ist.
Nachdem der gesamte Cluster die Leader-Wahl abgeschlossen hat, registriert sich der Lernende (der Sammelname von Follower und Observer) wieder beim Leader-Server. Nachdem der Learner-Server die Registrierung beim Leader-Server abgeschlossen hat, tritt er in die Datensynchronisierungsphase ein.
Datensynchronisationsprozess: (alles wird durch Messaging durchgeführt)
Lerner registriert sich bei Learder
Datensynchronisation
Synchronisationsbestätigung
Die Datensynchronisation von Zookeeper ist normalerweise in vier Kategorien unterteilt:
(1) Direkte differenzielle Synchronisation (DIFF-Synchronisation)
(2) Zuerst Rollback und dann differenzielle Synchronisierung (TRUNC+DIFF-Synchronisierung)
(3) Nur Rollback-Synchronisierung (TRUNC-Synchronisierung)
(4) Vollständige Synchronisierung (SNAP-Synchronisierung)
In Bearbeitung Vor der Datensynchronisierung der Leader Der Server vervollständigt die Initialisierung der Datensynchronisation:
PeerLastzxid:
Maximale ZXID in der Vorschlags-Cache-Warteschlange des Leader-Servers commitedLog Direkte differenzielle Synchronisation (DIFF-Synchronisation)
Vollständige Synchronisierung (SNAP-Synchronisierung)
zookeeper verwendet eine global inkrementelle Transaktions-ID, um sie zu identifizieren. Wenn sie vorgeschlagen werden, handelt es sich bei zxid um eine 64-Bit-Zahl, und die oberen 32 Bits sind Epoche; ; neue Ära) wird verwendet, um den Leader-Zyklus zu identifizieren. Wenn ein neuer Leader generiert wird, wird die Epoche automatisch erhöht und die unteren 32 Bits werden zum Erhöhen der Anzahl verwendet. Wenn ein neuer Vorschlag generiert wird, wird basierend auf dem zweistufigen Prozess der Datenbank zunächst eine Transaktionsausführungsanforderung an andere Server ausgegeben. Wenn mehr als die Hälfte der Maschinen ihn erfolgreich ausführen können, beginnt die Ausführung.
In einer verteilten Umgebung müssen einige Geschäftslogiken nur von einer bestimmten Maschine im Cluster ausgeführt werden, und andere Maschinen können die Ergebnisse teilen, was wiederholte Berechnungen erheblich reduzieren und die Leistung verbessern kann, sodass eine Wahl des Leiters erforderlich ist. .
Zookeeper selbst ist ebenfalls ein Cluster und es wird empfohlen, nicht weniger als 3 Server zu konfigurieren. Zookeeper selbst muss auch sicherstellen, dass andere Knoten weiterhin Dienste bereitstellen, wenn ein Knoten ausfällt.
Wenn ein Follower ausfällt, gibt es immer noch 2 Server, die den Zugriff ermöglichen. Da es mehrere Kopien der Daten auf Zookeeper gibt, gehen die Daten nicht verloren.
Wenn ein Leader ausfällt, wählt Zookeeper einen neuen Leader.
Der Mechanismus des ZK-Clusters besteht darin, dass der Cluster Dienste normal bereitstellen kann, solange mehr als die Hälfte der Knoten normal sind. Der Cluster schlägt nur dann fehl, wenn zu viele ZK-Knoten vorhanden sind und nur die Hälfte oder weniger als die Hälfte der Knoten funktionieren kann.
Also
Ein Cluster aus 3 Knoten kann 1 Knoten scheitern lassen (Anführer kann 2 Stimmen>1,5 erhalten)
Ein Cluster aus 2 Knoten kann keinen Knoten scheitern lassen (Anführer kann 1 Stimme erhalten<=1)
20. Welche Einsatzmodi gibt es von Zookeeper?
22. Unterstützt der Cluster das dynamische Hinzufügen von Maschinen?
Alle neu starten: Schließen Sie alle Zookeeper-Dienste, ändern Sie die Konfiguration und starten Sie sie. Hat keinen Einfluss auf frühere Client-Sitzungen.
Einen nach dem anderen neu starten: Unter dem Grundsatz, dass mehr als die Hälfte der Maschinen aktiv und verfügbar sind, hat der Neustart einer Maschine keine Auswirkungen auf die externen Dienste des gesamten Clusters. Dies ist die am häufigsten verwendete Methode.
Version 3.5 beginnt mit der Unterstützung der dynamischen Erweiterung.
Nein. Offizielle Aussage: Ein Watch-Ereignis ist ein einmaliger Auslöser. Wenn sich die Daten, für die die Watch eingestellt ist, ändern, sendet der Server die Änderung an den Client, für den die Watch eingestellt ist, um ihn zu benachrichtigen.
Warum ist es nicht dauerhaft? Wenn sich beispielsweise der Server häufig ändert und die Überwachungsclients in vielen Fällen alle Clients über jede Änderung benachrichtigt werden, was eine große Belastung für das Netzwerk und den Server darstellt.
Im Allgemeinen führt der Client getData("/node A", true) aus. Wenn Knoten A geändert oder gelöscht wird, erhält der Client sein Überwachungsereignis, aber dann ändert sich Knoten A erneut und der Client Wenn das Überwachungsereignis nicht erfolgt gesetzt, wird es nicht mehr an den Client gesendet.
In praktischen Anwendungen muss unser Client in vielen Fällen nicht jede Änderung auf dem Server kennen, ich benötige nur die neuesten Daten.
Java-Client: zks eigener zkclient und Apaches Open-Source-Curator.
chubby stammt von Google, implementiert den Paxos-Algorithmus vollständig und ist kein Open Source. Zookeeper ist eine Open-Source-Implementierung von Chubby, die das ZAB-Protokoll verwendet, eine Variante des Paxos-Algorithmus.
Allgemeine Befehle: ls get set create delete usw.
Gleiche Punkte:
(1) Beide haben eine ähnliche Rolle wie der Leader-Prozess, der für die Koordinierung der Ausführung mehrerer Follower-Prozesse verantwortlich ist
(2) Der Leader-Prozess wartet mehr als die Hälfte davon Follower müssen eine Entscheidung treffen. Erst nach korrektem Feedback wird ein Vorschlag eingereicht. (3) Im ZAB-Protokoll enthält jeder Vorschlag einen Epochenwert, der den aktuellen Leader-Zyklus darstellt. Der Name in Paxos lautet Ballot Es wird zum Aufbau eines hochverfügbaren verteilten Datenmaster- und Backup-Systems (Zookeeper) verwendet, und Paxos wird zum Aufbau eines verteilten Konsistenzzustandsmaschinensystems verwendet.
28. Typische Anwendungsszenarien von Zookeeper(2) Lastausgleich
(3) Benennungsdienst
(4) Verteilte Koordination/Benachrichtigung
(5) Clusterverwaltung
(6) Masterwahl
(7) Verteilte Sperre
(8) Verteilte Warteschlange
Cluster-Verwaltung: Überwachen Sie den Knotenüberlebensstatus, die Ausführung von Anforderungen usw.;
Master-Knotenwahl: Nachdem der Masterknoten aufgelegt hat, können Sie eine neue Runde der Leiterwahl vom Backup-Knoten aus starten Bei der Wahl des Master-Knotens kann die Verwendung von Zookeeper bei der Vervollständigung dieses Prozesses hilfreich sein.
Verteilte Sperre: Zookeeper bietet zwei Arten von Sperren: exklusive Sperren und gemeinsame Sperren. Eine exklusive Sperre bedeutet, dass jeweils nur ein Thread die Ressource verwenden kann. Eine gemeinsame Sperre bedeutet, dass Lesesperren gemeinsam genutzt werden und sich Lese- und Schreibsperren gegenseitig ausschließen, dh mehrere Threads können gleichzeitig dieselbe Ressource lesen Wird eine Schreibsperre verwendet, kann diese nur von einem Thread verwendet werden. Zookeeper kann verteilte Sperren steuern.
Namensdienst: In einem verteilten System kann die Clientanwendung mithilfe des Namensdienstes die Adresse, den Anbieter und andere Informationen der Ressource oder des Dienstes basierend auf dem angegebenen Namen abrufen.
Der Client erstellt ein Watcher-Ereignis für einen bestimmten Znode. Wenn sich der Znode ändert, erhalten diese Clients ZK-Benachrichtigungen, und dann kann der Client geschäftliche Änderungen basierend auf den Znode-Änderungen vornehmen.
zookeeper dient der Registrierung von Diensten und der Durchführung des Lastausgleichs, dem Anrufer muss bekannt sein, welche IP-Adressen vorhanden sind Adresse und der Dienstname. Natürlich kann diese Korrespondenz auch durch Hartcodierung in den Geschäftscode des Anrufers implementiert werden. Wenn der Dienstanbieter jedoch auflegt, hat der Anrufer keine Möglichkeit, dies zu erfahren. Wenn der Code nicht geändert wird, wird er weiterhin anfragen die tote Maschine, um Dienste bereitzustellen. Zookeeper kann den hängenden Computer über den Heartbeat-Mechanismus erkennen und die entsprechende Beziehung zwischen der IP und dem Dienst des hängenden Computers aus der Liste löschen. Was die Unterstützung hoher Parallelität betrifft, bedeutet dies einfach ausgedrückt eine horizontale Erweiterung, also eine Erhöhung der Rechenleistung durch Hinzufügen von Maschinen, ohne den Code zu ändern. Durch das Hinzufügen neuer Maschinen zur Registrierung von Diensten bei ZooKeeper gilt: Je mehr Dienstanbieter vorhanden sind, desto mehr Kunden können sie bedienen.
ist ein Tool zur Verwaltung der mittleren Schicht und des Data Warehouse. Es gibt viele Servicezugänge und Serviceanbieter, die einen Rahmen zur Lösung dieses Problems bereitstellen müssen.
Beachten Sie, dass es sich bei dem Dubbo hier nur um einen Rahmen handelt. Was Sie ins Regal stellen, liegt ganz bei Ihnen, genau wie bei einem Autogerüst müssen Sie zu Ihrem Radmotor passen. Um die Planung in diesem Framework abzuschließen, muss ein verteiltes Registrierungszentrum vorhanden sein, in dem die Metadaten aller Dienste gespeichert werden. Sie können zk oder andere verwenden, aber jeder verwendet zk.
Dubbo abstrahiert das Registrierungszentrum und kann verschiedene Speichermedien extern verbinden, um Dienste für das Registrierungszentrum bereitzustellen, einschließlich ZooKeeper, Memcached, Redis usw.
Die Einführung von ZooKeeper als Speichermedium führt auch die Funktionen von ZooKeeper ein. Der erste ist der Lastausgleich, der durch eine ZooKeeper-Gruppe erreicht werden kann, wenn der Datenverkehr ein bestimmtes Niveau erreicht Die entsprechende Webanwendung reicht nicht aus, der Lastausgleich reicht nicht aus, Daten und Ressourcen zwischen Knoten müssen synchronisiert werden, und ZooKeeper-Cluster verfügen natürlich über eine solche Funktion, die eine Baumstruktur verwendet, um eine globale Dienstadressliste zu verwalten. Dienstanbieter Schreiben Sie beim Start Ihre eigene URL-Adresse in das Verzeichnis /dubbo/${serviceName}/providers des angegebenen Knotens auf ZooKeeper. Dieser Vorgang schließt die Freigabe des Dienstes ab. Weitere Funktionen sind Mastwahl, verteilte Sperren usw.
![[Empfohlene Sammlung] Seelenfolter! Die 31-Schuss-Kanone des Tierpflegers](https://img.php.cn/upload/article/001/273/727/d1c2498c21060c678324dd90c83125e4-1.jpg)
Das obige ist der detaillierte Inhalt von[Empfohlene Sammlung] Seelenfolter! Die 31-Schuss-Kanone des Tierpflegers. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
