Raft ist ein Konsens-Algorithmus für verteilte Systeme, entwickelt von Diego Ongaro und John Ousterhout (Stanford University). Das Paper „In Search of an Understandable Consensus Algorithm“ erschien 2014 auf der USENIX ATC — der Name ist Programm: Das primäre Design-Ziel war Verständlichkeit, nicht nur Korrektheit. Raft zerlegt das Problem in klar getrennte Teilprobleme: Leader-Wahl, Log-Replikation und Sicherheit.
Rollen und Terme
Jeder Knoten ist zu jedem Zeitpunkt Leader, Follower oder Candidate. Der Leader bearbeitet alle Schreibvorgänge und sendet regelmäßige Heartbeats; die Follower replizieren sein Log. Die Zeit ist in fortlaufende Terme eingeteilt, die bei jeder Wahl beginnen. Ein Follower, der innerhalb eines zufällig gewählten Election-Timeout keinen Heartbeat erhält, erklärt sich zum Candidate, erhöht den Term und fordert Stimmen an — die Zufalls-Timeout verhindern Split Votes, bei denen mehrere Kandidaten gleich viele Stimmen erhalten.
Log-Replikation
Der Leader hängt jeden Client-Befehl als Eintrag an sein Log und schickt ihn an die Follower. Ein Eintrag gilt als committed, sobald eine Mehrheit (Quorum) der Knoten ihn auf einer aktuellen Term-Stufe gespeichert hat — erst dann wird er in die deterministische Zustandsmaschine übernommen. Dadurch bleiben alle Knoten trotz Ausfällen konsistent; ein neuer Leader übernimmt exakt das Log seines Vorgängers und bringt langsamere Knoten per Nachführung auf den Stand.
Warum Raft?
Paxos galt lange als Standard, war aber schwer zu implementieren. Raft erreicht dieselben Garantien mit einfacheren Regeln und wurde dadurch zum meistgenutzten Konsens-Algorithmus neuerer Systeme: etcd (Konfigurationsspeicher von Kubernetes), Consul (Service Discovery), CockroachDB und TiKV (pro Datenbereich), HashiCorp Vault und viele weitere setzen Raft oder Varianten davon ein. Es ist die praktische Verwirklichung von Konsens — und ein Paradebeispiel dafür, wie das CAP-Theorem in der Realität ausgelegt wird: Bei einer Partition bleibt Raft mit der Mehrheit verfügbar und opfert die Minderheit, bis die Verbindung wiederhergestellt ist.
Verwandte Grundlagen: Cluster, Datenbank-Replikation, Eventual Consistency, Hochverfügbarkeit.