Hallo zusammen, in diesem Video geht es darum, welche Eigenschaften die Replikation von Sookieper

anbietet, sowie um Saab, das dafür im Hintergrund verwendet wird.

Wenn man eine Anwendung mit Zustand, wie etwa einen Koordinationsdienst, repliziert, muss

man dafür sorgen, dass die Zustände der Replikate auch tatsächlich konsistent bleiben.

Was nicht funktioniert, ist, wie im folgenden Beispiel, Anfragen einfach direkt nach dem

Empfang auszuführen.

Nehmen wir mal an, wir haben zwei Clients, die jeweils die Daten eines Knotens auf 47

bzw. 48 setzen möchten.

Dazu schicken wir jetzt einfach ihre Anfrage direkt an die beiden Replikate los.

Die Anfrage A1 vom linken Client kommt jetzt zuerst bei Replikat 1 an und Anfrage A2 zuerst

bei Replikat 2.

Beide Replikate aktualisieren jetzt ihren Zustand und anschließend kommt jeweils noch

fehlende Anfrage an und überschreibt die Daten erneut.

Und voilá, der Zustand der Replikate ist in Konsistent.

So, wie macht man das Replizieren jetzt richtig, sodass die Replikate auch tatsächlich konsistent

bleiben?

Die Grundidee bei der Art der Replikation, wie sie in Suchebar verwendet wird, ist, dass

alle Replikate exakt dieselben Zustandsänderungen in exakt derselben Reihenfolge durchlaufen

müssen.

Und dafür gibt's grob zwei Verfahren, wie man das hinbekommen kann.

Bei der aktiven Replikation würde man Anfragen zuverlässig in einer bestimmten Reihenfolge

an alle Replikate verteilen und dort ausführen.

Suchebar verwendet die sogenannte passive Replikation, bei der ein Anführerreplikat

die Anfragen ausführt und dann nur die Zustandsänderungen an alle Replikate verteilt.

Für den Betrieb von Suchebar ist eine Gruppe von 2F plus 1 Replikaten notwendig, von denen

maximal F ausfallen oder nicht erreichbar sein dürfen.

Es muss also immer eine Mehrheit, also mehr als die Hälfte der Replikate irgendwie funktionsfähig

sein.

Ein Client kann sich jetzt zu irgendeinem Replikat verbinden, das dann im Folgenden

als Kontaktreplikat für den Client fungiert.

Für die Schreibanfragen, die stark konsistent verarbeitet werden, läuft die Replikation

dann wie folgt ab.

Der Client schickt die Anfrage an sein Kontaktreplikat und das leitet die dann an das aktuelle Anführerreplikat

weiter.

Der Anführer nimmt die Anfrage her, bearbeitet die und schreibt die Änderungen, die sich

durch die Anfrage ergeben in eine Zustandstransaktion.

Falls beim Bearbeiten der Anfrage ein Fehler auftritt, also z.B. wenn ein Knoten, der gelöscht

werden sollte, gar nicht existiert, dann muss hier eine Fehlertransaktion erstellt werden.

Anschließend wird mit dem Replikationsprotokoll Zap die Transaktion in der vom Anführer vorgegebenen

Reihenfolge verteilt.

Sobald Zap die Transaktion intern an eine Mehrheit von Replikaten verteilt hat, fängt

es dann an, die Transaktion auf allen Replikaten inklusive auch dem Anführer auszuliefern.

Und erst jetzt aktualisieren die Replikate dann auch tatsächlich ihren Zustand anhand

der Transaktion.

Der Grund warum das erst jetzt passiert ist, dass erst jetzt, wo mehr als die Hälfte

der Replikate die Transaktion bekommen haben, diese auch im Fehlerfall nicht mehr verloren

gehen kann.

Und das liegt einfach daran, dass laut Annahme nur weniger als die Hälfte der Replikate

ausfallen dürfen.

Und damit findet Zap jetzt dann auch im Fehlerfall immer eins der Replikate wieder, das die Transaktion