Raft

Wenn du Kubernetes betreibst. Der etcd Key-Value Store speichert den gesamten Cluster-Zustand. Wenn der etcd-Leader ausfällt, wählen die Follower per Raft sofort einen neuen. Dauert 2-3 Sekunden. Dein Cluster überlebt den Ausfall nahtlos. Auch Consul, CockroachDB, RabbitMQ nutzen Raft.

1. Term & Index

Die Zeit in Raft wird in "Terms" gemessen (Wahlperioden). Jeder Log-Eintrag hat (Term, Index). Wenn ein Follower ein Log-Update bekommt, prüft er: "Habe ich den Vorgänger-Eintrag?" Wenn ja -> Append. Wenn nein -> Reject -> Leader schickt ältere Einträge nach. Das garantiert, dass alle Logs irgendwann identisch sind.

2. Strong Leader

Im Gegensatz zu Paxos (wo jeder Proposer sein kann), gehen in Raft alle Writes über den Leader. Clients müssen den Leader finden. Read-Requests können optimiert werden (Read-Index), müssen aber wissen, ob der Leader noch Leader ist (Lease).

1. Log Matching Property & Uncommitted State

Ein kritisches Raft-Design ist die Safety-Garantie: Wenn zwei Logs (Leader und Follower) einen Eintrag mit derselben Index-Nummer und derselben Term-Wahlperiode enthalten, beweist Raft mathematisch, dass alle vorherigen Einträge bis Index 0 ebenfalls bitweise absolut identisch sind. Das ist die Log Matching Property. Das Problem in Prod: Der Leader schiebt den Eintrag ins Log (Index 5) und stürzt 0,1ms vor dem Versenden des Append-Requests ab. Der Eintrag ist im lokalen Leader-Log, aber die Welt weiß davon nichts ("Uncommitted"). Der neue Nachfolger-Leader wählt ein Update auf Index 5 per Client-Request. Kehrt der alte tote Leader als besiegter Follower zurück ans Netz, bemerkt der neue State-Machine Master den abweichenden History-Term bei Index 5. Er rollt den armen Follower aggressiv wie eine Dampfwalze platt: Dessen unbestätigter Eintrag wird sofort gelöscht und mit dem validierten Term hart überschrieben. Das bedeutet für Devs: Client-Request API's dürfen dem Frontend erst dann ein "Success 200 HTTP" returnieren, wenn die Commit-Quittung durch die Leader-Engine offiziell deklariert ist.

2. Read-Index & Lease (Bypass the Quorum)

Raft verbietet "Stale Reads". Wenn ein Client den Leader nach $X$ fragt, darf dieser eigentlich nicht einfach blind antworten! Was, wenn er durch eine massive Netzwerk-Partition abgeschnitten wurde, sein Cluster lauthals einen neuen Leader gewählt hat (Split Brain) und jemand drüben den $X$ geändert hat? Um zu beweisen, dass er noch König ist, müsste er für den simplen "Read" das Quorum fragen (Heartbeat Roundtrip) – das ist massiv ineffizient! Raft optimiert mit dem Lease-Readi-Patter / Read-Index: Der Leader speichert beim letzten Quorum-Sieg eine Timestamp "Lease" (z.B. $500$ ms). Innerhalb des Zeitfensters garantiert Raft, dass mathematisch bedingt kein Pundit ohne seine Stimme zum neuen Leader gewählt werden konnte! Damit greift der Leader den State O(1) aus dem RAM ab. Ist die Lease abgelaufen, stoppt er, pollt die Majority mit extrem schlanken Heartbeats nach ("Read-Index Phase") und liefert darauf den garantiert linearen Top-State aus.

3. The etcd Database Size Limit Trigger (8GB)

Kubernetes speichert alles im Raft-Backend von etcd. Eine bittere Lektion klassischer SRE-Einsätze ist das MVCC (Multi-Version) Append-Only Paradigma von Raft. Ein gelöschter Pod löscht die Zeile nicht aus etcd, sie fügt einen Tombstone ans Raft Log. Bei starker Churn-Rate bläht sich die etcd Speicher-DB massiv auf (Space Exploit). Raft hat ein in Stein gemeißeltes Quota (oft 2 GB bis 8 GB hard-limit). Sobald Kubernetes durch HPA Scaling dieses Log-Limit erreicht, wechselt Raft panisch in den Read-Only "ALARM" Zustand. Der gesamte K8s Cluster friert ein (Keine Pod-Deployments oder Deletes mehr möglich!) bis der Operator nachts manuell einen Hardcore etcdctl defrag & compaction Trimm über den WAL (Write-Ahead-Log) treibt.