Konsens
Konsens lässt mehrere Teilnehmer denselben verbindlichen Zustand oder dieselbe Reihenfolge festlegen. Ein Protokoll muss dafür auch mit Ausfällen und verzögerten Nachrichten umgehen.
- MehrheitMehr als die Hälfte aller Knoten.
- LeaderOrdnet Werte einer Logposition zu.
- Pause statt Split BrainMinderheit nimmt keine Einträge an.
Einordnung
Warum das wichtig ist
Wenn mehrere Replikate gleichzeitig verschiedene Änderungen vorschlagen, braucht das System eine verbindliche Reihenfolge, sonst laufen die Stände auseinander. Das Protokoll muss auch Ausfälle und verzögerte Nachrichten verkraften. Quorum und Replikation vertiefen eigene Bausteine.
Dieser Baustein behandelt Einigung auf einen geordneten Zustand. Quorumzahlen beschreiben Bestätigungsgruppen; Saga koordiniert fachliche Schritte über mehrere Transaktionen.
Auf einen Blick · Leader repliziert Log an Mehrheit
Mehrheit bei Ausfall und Trennung
Variante: Ein separat betriebener Inventardienst verwendet mehrere Replikate, um Änderungen an gemeinsam genutzten Lagerständen geordnet zu protokollieren. Der Shop selbst bleibt ein modularer Monolith.
So liest du das Bild
- Mehrheit Die Angabe „Mehrheit: 3 von 5“ über den Knoten.
- Leader Der dunkle Knoten; nach der Trennung wird K3 neuer Leader.
- Pause statt Split Brain Die Gruppe mit K1 und K2 zeigt „keine Mehrheit – pausiert“.
Mehrheit: 3 von 5
5 von 5 · schreibt fest: Position 84
Eine Mehrheit ist erreichbar: Der Leader schreibt den Eintrag fest, sobald sie ihn bestätigt.
Konsens über eine Logposition
- Runde 12 beginnt
Leader und Position festlegen
Der gewählte Leader bearbeitet Logposition 84 für den Inventardienst.
- Vorschlag A
Ersten Wert aufnehmen
Leader ordnet „Bestand −1 für SKU-42“ Position 84 zu.
- gleichzeitig
Konkurrierenden Vorschlag behandeln
„Bestand −2 für SKU-42“ konkurriert; das Protokoll hält ihn von Position 84 fern.
- Bestätigung
Einen Wert verbindlich machen
Teilnehmer bestätigen in Runde 12 den Wert A für Position 84.
- Anwendung
Reihenfolge übernehmen
Replikate wenden den bestätigten Eintrag an derselben Logposition an; Vorschlag B bleibt separat zu behandeln.
Nutzen & Grenzen
Hilft, wenn
- Verteilte Zustandsänderungen mit verbindlicher Reihenfolge benötigen eine gemeinsame Entscheidung der Knoten.
- Mehrheitsbestätigung schützt bestätigte Logeinträge bei zulässigen einzelnen Knotenausfällen.
- Die fehlende Mehrheit definiert die Grenze, an der neue verbindliche Einträge pausieren.
Grenzen
- Ohne Mehrheit nimmt das Cluster keine neuen verbindlichen Einträge an; plane diese Pause als Teil des Betriebs.
- Konsens ordnet nur den replizierten Log; Wirkungen nach außen brauchen eigene Wiederholungs- und Zustandsbehandlung, etwa Idempotenz.
- Weit verteilte Mehrheiten verlängern jede Bestätigung; prüfe Platzierung der Knoten gegen Zeitziele und Quorum.
In der Praxis
- Bestimme, welcher Zustand eine verbindliche Reihenfolge verlangt und wer dem Cluster angehört. Verwende eine etablierte Protokollimplementierung statt eigener Abstimmungslogik.
- Prüfe Commitgrenze, Mehrheitsverlust und Leaderwechsel anhand des Logs. Bestätigte Einträge müssen nach zulässigem Wechsel in derselben Reihenfolge erhalten bleiben.
- Übe Mitgliederwechsel, Snapshot-Wiederanlauf und fehlende Mehrheit. Quorum erklärt Schwellen; Wiederherstellung behandelt Betriebsfortsetzung.
Ausführliche Erklärung lesen
Ein Konsensprotokoll lässt verteilte Teilnehmer einen gemeinsamen geordneten Logstand festlegen. Raft trennt Leaderwahl, Replikation und Sicherheitsregeln. Bestätigte Einträge bleiben bei erlaubten Leaderwechseln maßgeblich.
Eine erreichbare Mehrheit ermöglicht Fortschritt; ohne sie kann das Cluster keine neue verbindliche Entscheidung bestätigen. Zeitannahmen beeinflussen Verfügbarkeit, während Protokollregeln widersprüchliche Historien verhindern sollen. Konsens koordiniert den Log, aber externe Nebenwirkungen brauchen weiterhin eigene Behandlung.
Quorum beschreibt erforderliche Antwortmengen; Wiederherstellung behandelt den Betrieb nach Ausfall. Konsensprotokolle verbinden Mehrheitsregeln mit einer verbindlichen Logordnung.
Paxos ist das ältere, Raft das verständlicher beschriebene Verfahren. Eine erreichbare Mehrheit ermöglicht neue verbindliche Entscheidungen; fehlt sie, pausiert das Cluster. Diese Pause schützt eine einzige maßgebliche Logordnung und verhindert widersprüchliche Historien. Deshalb nutzt man ungerade Knotenzahlen wie drei oder fünf.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Das Netz trennt K1 und K2 vom Rest. Welche Gruppe schreibt Position 84 fest, und wer führt sie?
Lösung mit Begründung ansehen
Die Gruppe aus K3, K4 und K5, denn sie hat 3 von 5 Knoten. K3 wird dort neuer Leader; K1 und K2 pausieren.
AnwendenAuf eine neue Lage übertragen
Ohne Trennung fallen K4 und K5 aus. Kann der Inventardienst noch Lagerbuchungen festschreiben? Und wenn zusätzlich K3 ausfällt?
Lösung mit Begründung ansehen
Mit K1, K2 und K3 ja, das sind 3 von 5. Fällt auch K3 aus, bleiben 2 von 5: Das Cluster pausiert, bis ein Knoten zurück ist.
BewertenEine Alternative abwägen
Ein Team will statt fünf nur vier Knoten betreiben, um Kosten zu sparen. Was spricht dafür, was dagegen?
Lösung mit Begründung ansehen
Dafür: ein Knoten weniger Betrieb. Dagegen: Die Mehrheit liegt bei 3 von 4, also verkraftet das Cluster wie bei drei Knoten nur einen Ausfall. Ich empfehle drei oder fünf Knoten.
Vertiefen
Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.
Lease und Fencing-Token
Eine Lease gewährt einem Besitzer für begrenzte Zeit das Recht, eine Aufgabe zu steuern. Nach Ablauf kann ein neuer Besitzer übernehmen; ein pausierter alter Besitzer könnte später dennoch weiterarbeiten. Vergib bei jeder Übernahme ein steigendes Fencing-Token und lass den geschützten Speicher alle Schreibvorgänge mit einem Token ablehnen, das kleiner als das bereits für diese Ressource akzeptierte Token ist.
Eine Lease allein ersetzt weder Konsens noch die Prüfung am Ressourcenzugriff. Das Fencing verhindert, dass ein verspäteter Besitzer nach der Übernahme mit einem älteren Token noch schreiben kann.
Zum AusprobierenLass im Shop einen Lager-Worker seine Lease verlieren und danach verspätet mit einer Reservierung zurückkehren. Prüfe, dass der neue Worker ein höheres Fencing-Token erhält und die Datenbank nach dessen Annahme den alten Schreibversuch ablehnt, auch wenn der frühere Worker wieder erreichbar ist.
Weiterführende Bausteine
Quellen
- Raft – In Search of an Understandable Consensus Algorithm (öffnet in neuem Tab)Originalarbeit zu Leader-Wahl, Log-Replikation und Sicherheitsgarantien.
- Leslie Lamport – Paxos Made Simple (öffnet in neuem Tab)Leitet die Voraussetzungen und Sicherheitsidee von Paxos her.
- Google SRE – Managing Critical State (öffnet in neuem Tab)Verbindet Konsensverfahren mit zuverlässiger Verwaltung kritischer Zustände.
- Unmesh Joshi · Lease (öffnet in neuem Tab)Zeitlich begrenzte und erneuerbare Berechtigung zur Koordination.
- Martin Kleppmann · How to do distributed locking (öffnet in neuem Tab)Verspätete Besitzer und die Durchsetzung monotoner Fencing-Tokens am Speicher.