Hallo zusammen, dieses Video dreht sich um Replikation im Allgemeinen und das Rought-Protocol.

Bevor wir aber zu den beiden Themen kommen, werfen wir erst noch einen kurzen Blick darauf,

was in dieser Übungsaufgabe überhaupt gemacht werden soll.

Wenn ihr euch an die dritte Übungsaufgabe zurückerinnert, hatten wir uns dort damit

beschäftigt Netzwerkprobleme zwischen Sender und Empfänger zu törieren.

Allerdings helfen die Maßnahmen nichts gegen Server-Ausfälle.

Daher wollen wir uns in dieser Übungsaufgabe mit Replikation beschäftigen, damit ein Dienst

dann trotz Server-Ausfällen immer noch funktioniert.

Ganz konkret wollen wir einen Zählerdienst mit Hilfe des Protokolls Raft replizieren.

Der Zählerdienst selbst ist bereits von uns vorgegeben und bietet einen Zähler an, den

ein Kleint incrementieren und auslesen kann.

Die Server-Seite des Zählerdienstes soll dann mit Hilfe von Raft repliziert werden.

Und letztes ist im Rahmen der Übungsaufgabe zu implementieren.

Zum Einstieg werfen wir jetzt erstmal einen etwas generelleren Blick auf Replikation

an sich.

Im Prinzip gibt's grob zwei Spielarten.

Zum einen die aktive Replikation und zum anderen die passive Replikation.

Bei der aktiven Replikation bearbeiten alle Replikate aktiv alle Anfragen, daher auch

der Name, was dann auch dafür sorgt, dass im Fall von Ausfällen jedes Replikat praktisch

sofort einspringen könnte.

Das hat allerdings den Nachteil, dass dadurch, dass jedes Replikat alles ausführen muss,

es dann auch zu einem erhöhten Ressourcenverbrauch kommt.

Bei der passiven Replikation hingegen sieht es dann so aus, dass nur ein einziges Replikat

Anfragen bearbeitet und die sich daraus ergebenden Änderungen oder Sicherungspunkte an die anderen

Replikate verteilt.

Wichtig dabei ist, dass die Antwort auf eine Anfrage erst dann gesendet werden darf, nachdem

die Änderungen gespeichert bzw. an die anderen Replikate verteilt wurden.

Bei passiver Replikation lässt sich außerdem zwischen warm passive replication und cold

passive replication unterscheiden.

Der Hauptunterschied liegt darin, wann oder wie häufig Sicherungspunkte eingespielt werden.

Also ob die Replikate in regelmäßigen Intervallentesicherungspunkte einspielen oder ob die Sicherungspunkte

nur ausfallssicher hinterlegt werden und erst bei Bedarf eingespielt werden.

Die Vorgehensweise sorgt dafür, dass sich der Aufwand im fehlerfreien Fall reduziert,

wenn man höchstens hin und wieder einen Sicherungspunkt anwenden muss.

Im Umkehrschluss sorgt es dann aber auch dafür, dass falls ein Fehler auftritt, man ein Replikat

erst auf den aktuellen Zustand bringen muss, bevor das Replikat dann tatsächlich Anfragen

verarbeiten kann.

Allgemein ist das Ziel beim Replizieren eines Dienstes, die die Replikation so transparent

wie möglich zu gestalten.

Idealerweise merkt der Nutzer nur wenig bis nichts davon, dass der Dienst repliziert

ist.

Das ist abgesehen vielleicht davon, dass es im Fehlerfall ein paar Verzögerungen gibt.

Replikatausfälle sollen folglich vor dem Nutzer verborgen werden, indem dann automatisch

zu anderen funktionierenden Replikaten gewechselt wird.

Beim Replizieren von Diensten muss man zwischen zustandslosen und zustandsbehafteten Diensten

unterscheiden.

Das Replizieren eines zustandslosen Dienstes ist dabei relativ simpel.

Ganz ohne Zustand bzw. nur mit einem unveränderlichen Zustand braucht man logischerweise keine Koordination

zwischen den Replikaten.

Dementsprechend kann sich ein Klein dann einfach eines der Replikate auswählen, also z.B.