Zookeeper: Detaillierte Erklärung des Zab-Algorithmus

Das zab-Protokoll ist ein verteiltes Konsensprotokoll, das für Zookeeper entwickelt wurde .

1. Was ist die ZAB-Vereinbarung? Einführung in das ZAB-Abkommen

Der vollständige Name des ZAB-Protokolls: Zookeeper Atomic Broadcast ( Zookeeper Atomic Broadcast ).
Zookeeper ist ein effizienter und zuverlässiger verteilter Koordinierungsdienst für verteilte Anwendungen. Um die verteilte Konsistenz zu lösen, verwendete Zookeeper kein Paxos, sondern übernahm das ZAB-Protokoll.
Definition des ZAB-Protokolls: Das ZAB-Protokoll ist ein Support- Protokoll, das speziell für den verteilten Koordinierungsdienst Zookeeper entwickelt wurde 原子广播 和 崩溃恢复 . Im Folgenden werden wir uns auf diese beiden Dinge konzentrieren.
Basierend auf diesem Protokoll implementiert Zookeeper eine 主备模式 Systemarchitektur , um die Replikate im Cluster zu halten 数据一致性. Die Details sind in der folgenden Abbildung dargestellt:

Die obige Abbildung zeigt, wie Zookeeper Daten im Cluster verarbeitet:

Alle Client-Schreibdaten werden in den Hauptprozess (Leader genannt) geschrieben und dann vom Leader in den Sicherungsprozess (Follower genannt) kopiert. Um die Datenkonsistenz zu gewährleisten . Aus gestalterischer Sicht ähnelt es Raft.

5. Was ist also mit dem Kopiervorgang? Der Replikationsprozess ähnelt dem von 2PC . ZAB benötigt nur mehr als die Hälfte der Follower, um Ack-Informationen für die Übermittlung zurückzugeben, wodurch die Blockierung der Synchronisation erheblich reduziert wird. Es verbessert auch die Benutzerfreundlichkeit .

Konzentrieren Sie sich nach der kurzen Einführung auf 消息广播 und 崩溃恢复. Der gesamte Zookeeper wechselt zwischen diesen beiden Modi . Kurz gesagt, wenn der Leader-Dienst normal verwendet werden kann, wechselt er in den Nachrichtenübertragungsmodus, und wenn der Leader nicht verfügbar ist, wechselt er in den Absturzwiederherstellungsmodus .

2. Nachrichtensendung

Der Nachrichtenübertragungsprozess des ZAB-Protokolls verwendet ein atomares Übertragungsprotokoll , ähnlich einem zweiphasigen Festschreibungsprozess .

Alle vom Kunden gesendeten Schreibanforderungen werden vom Leader empfangen. Der Leader kapselt die Anfrage in einen Transaktionsvorschlag und sendet sie an alle Follower. Wenn dann nach dem Feedback aller Follower mehr als die Hälfte der Follower erfolgreich antworten, Die Festschreibungsoperation wird ausgeführt (zuerst senden). Senden Sie selbst eine Festschreibung an alle Follower.

Grundsätzlich ist der gesamte Sendevorgang in drei Schritte unterteilt:

1. Kopieren Sie alle Daten in den Follower

2. Warten Sie, bis der Follower auf Ack reagiert, und die Mindestanzahl beträgt mehr als die Hälfte, um erfolgreich zu sein

3. Wenn mehr als die Hälfte der Antwort erfolgreich ist, führen Sie das Commit aus und senden Sie sich gleichzeitig

Durch die obigen 3 Schritte kann die Datenkonsistenz zwischen Clustern aufrechterhalten werden. Tatsächlich gibt es eine Nachrichtenwarteschlange zwischen Leader und Follower, um die Kopplung zwischen ihnen zu entkoppeln, eine Synchronisation zu vermeiden und eine asynchrone Entkopplung zu erreichen.

Es gibt einige Details:

Nachdem der Leader die Client-Anfrage erhalten hat, kapselt er die Anfrage in eine Transaktion und weist der Transaktion eine global ansteigende eindeutige ID zu, die als Transaktions-ID (ZXID) bezeichnet wird. Das ZAB-Protokoll muss die Reihenfolge der Transaktion garantieren be Jede Transaktion wird nach ZXID sortiert und verarbeitet.
Es gibt auch eine Nachrichtenwarteschlange zwischen Leader und Follower, um die Kopplung zwischen ihnen zu entkoppeln und die Blockierungssynchronisation aufzuheben.
Um sicherzustellen, dass alle Prozesse in einer geordneten Reihenfolge ausgeführt werden können, kann im Zookeeper-Cluster nur der Leader-Server Schreibanforderungen akzeptieren. Selbst wenn der Follower-Server die Client-Anforderung empfängt, wird sie zur Verarbeitung an den Leader-Server weitergeleitet.
Tatsächlich ist dies eine vereinfachte Version von 2PC, die Einzelpunktprobleme nicht lösen kann. Später werden wir darüber sprechen, wie ZAB das Einzelpunktproblem (dh das Leader-Crash-Problem) löst.

3. Crash Recovery

Wir haben gerade gesagt, was soll ich tun, wenn der Leader während des Nachrichtenübertragungsprozesses abstürzt? Kann garantiert werden, dass die Daten konsistent sind? Was soll ich tun, wenn der Leiter zuerst lokal sendet und dann die Festschreibungsanforderung nicht gesendet wird?

Wenn der Leader abstürzt, wechselt er in den zuvor erwähnten Crash-Wiederherstellungsmodus (Crash bedeutet: Leader verliert den Kontakt zu mehr als der Hälfte der Follower). Lassen Sie uns unten im Detail sprechen.

Annahme 1: Leader stürzt ab, nachdem Daten an alle Follower kopiert wurden. Was soll ich tun?
Hypothese 2: Was ist, wenn der Anführer abstürzt, nachdem er eine Bestätigung erhalten und sich selbst eingereicht und gleichzeitig einige Commits gesendet hat?

Als Reaktion auf diese Probleme hat das ZAB zwei Prinzipien definiert:

Das ZAB-Protokoll stellt sicher, dass Transaktionen, die in Leader festgeschrieben wurden, schließlich von allen Servern festgeschrieben werden.
Das ZAB-Protokoll stellt sicher, dass Transaktionen, die nur vom Leader vorgeschlagen / repliziert, aber nicht festgeschrieben werden, verworfen werden.

Aus diesem Grund hat ZAB den folgenden Wahlalgorithmus entwickelt:
Es kann sicherstellen, dass vom Leiter übermittelte Transaktionen übermittelt werden, während übersprungene Transaktionen verworfen werden.

Wenn der Leader-Wahlalgorithmus in Reaktion auf diese Anforderung sicherstellen kann, dass der neu gewählte Leader-Server die Transaktion aller Maschinennummern im Cluster hat (dh die ZXID ist die größte), kann garantiert werden, dass der neu gewählte Der Leiter muss über alle eingereichten Vorschläge verfügen.
Dies hat den Vorteil , dass der Leader-Server gespeichert werden kann, um das Transaktions-Commit zu überprüfen und die Arbeit dieses Schritts zu verwerfen.

Auf diese Weise können die beiden Probleme, die wir gerade angenommen haben, gelöst werden. Annahme 1 verwirft schließlich die Daten, die nicht vom Aufruf übermittelt wurden, und Annahme 2 synchronisiert schließlich die Daten aller Server. Zu diesem Zeitpunkt stellt sich die Frage, wie synchronisiert werden soll.

4. Datensynchronisation

Nachdem der Absturz wiederhergestellt ist, bestätigt der Leader-Server vor der formellen Arbeit (Empfang der Client-Anfrage) zunächst, ob die Transaktion von mehr als der Hälfte des Followers gesendet wurde, dh ob die Datensynchronisation abgeschlossen ist. Der Zweck ist es, die Daten konsistent zu halten.

Wenn alle Follwer-Server erfolgreich synchronisiert wurden, fügt Leader diese Server der Liste der verfügbaren Server hinzu.

Tatsächlich ist der Leader-Server auf ZXID angewiesen, um Transaktionen zu verarbeiten oder zu verwerfen. Wie wird diese ZXID generiert?

Antwort: Beim ZXID-Entwurf der Transaktionsnummer des ZAB-Protokolls ist ZXID eine 64-Bit-Nummer, von der die unteren 32 Bit als einfacher inkrementeller Zähler angesehen werden können. Für jede Transaktionsanforderung des Clients generiert der Leader eine neue Transaktion. Vorschlag und +1 Operation auf dem Zähler.

Die oberen 32 Bits stellen die ZXID des größten Transaktionsvorschlags im lokalen Protokoll dar, das vom Leader-Server stammt, und der entsprechende Epochenwert wird von der ZXID analysiert, und dieser Wert wird dann um eins addiert.

Die hohen 32 Bits repräsentieren die Eindeutigkeit jeder Leader-Generation, und die niedrigen 32 Bits repräsentieren die Eindeutigkeit von Transaktionen in jeder Leader-Generation. Gleichzeitig kann es Follower auch ermöglichen, verschiedene Leader über die oberen 32 Bits zu identifizieren. Vereinfachte den Datenwiederherstellungsprozess.

Basierend auf dieser Strategie: Wenn Follower eine Verknüpfung zu Leader herstellt, vergleicht der Leader-Server die zuletzt auf seinem eigenen Server übermittelte ZXID mit der ZXID bei Follower, und das Ergebnis des Vergleichs wird entweder zurückgesetzt oder mit Leader synchronisiert.

5. Zusammenfassung

Es ist Zeit zusammenzufassen.

Das ZAB-Protokoll und das Raft-Protokoll, die wir zuvor gesehen haben, sind tatsächlich ähnlich. Beispielsweise gibt es einen Leader, um die Konsistenz sicherzustellen (Paxos verwendet den Leader-Mechanismus nicht, um die Konsistenz sicherzustellen). Dann gibt es einen Mechanismus, um sicherzustellen, dass der Dienst verfügbar ist (tatsächlich tun dies sowohl Paxos als auch Raft).

Mit ZAB kann der gesamte Zookeeper-Cluster zwischen den beiden Modi Message Broadcast und Crash Recovery wechseln. Message Broadcast kann als vereinfachte Version von 2PC bezeichnet werden. Es löst das Einzelpunktproblem von 2PC durch Crash Recovery und löst das Problem der Synchronisationsblockierung von 2PC durch Warteschlangen.

Die Datengenauigkeit nach der Wiederherstellung nach einem Absturz wird durch die Datensynchronisation unterstützt, die aufgrund der Eindeutigkeit der ZXID der Transaktion garantiert wird. Durch die + 1-Operation kann die Reihenfolge der Transaktionen unterschieden werden.

Referenz:

Zookeeper Quellcode;

Verteilte Theorie (7) -ZAB des Konsensprotokolls

"Von Paxos zum Zookeeper-Prinzip und zur Praxis verteilter Konsistenz"