OpenRaft: Raft-Konsens in Rust jenseits des Standard-Papiers

Ein Raft-Fork aus async-raft mit eigenem Anspruch

OpenRaft ist eine in Rust geschriebene Implementierung des Raft-Konsensalgorithmus, die auf jedem async-Runtime-Umfeld laufen soll. Die Wurzeln liegen in der Crate async-raft, von der sich das Projekt abgeleitet hat; ein eigenes Dokument im Repository listet die Fehler auf, die dabei behoben wurden. Das erklärte Ziel reicht weiter als eine weitere Portierung: Raft soll zum Konsensprotokoll der nächsten Generation für verteilte Datenspeicher werden, genannt werden SQL, NoSQL, KV-, Streaming- und Graph-Systeme.

Ein Produktionsbeleg liegt auf der Hand: OpenRaft ist laut README die Konsens-Engine der Metaservice-Cluster in Databend, der Cloud-Datenanalyseplattform desselben Herausgebers databendlabs. Die Metadaten vom August 2026 weisen 2037 Sterne, 237 Forks und 24 offene Issues aus; zuletzt wurde am 5. August am main-Zweig gearbeitet. Die Dokumentation liegt auf docs.rs, ergänzt durch eine FAQ und eine Architekturübersicht auf DeepWiki.

Verallgemeinerte Mitgliedschaft und das neue Vote-Design

Zwei Entwurfsentscheidungen trennen OpenRaft vom Standard-Raft. Erstens die verallgemeinerte Mitgliedschaftsänderung: Die erweiterte gemeinsame Mitgliedschaft verändert eine beliebige Menge von Knoten in einem einzigen Vorgang, während klassisches Raft nur einen Knoten nach dem anderen umkonfiguriert; die Einzelschritt-Änderung wird im README ausdrücklich als eingeschränkter Sonderfall des gemeinsamen Konsens beschrieben.

Zweitens das überarbeitete Vote-Design, das die Rate von Wahlkonflikten senken soll: Eine geteilte Wahl erzwingt keine neue Amtszeit mehr, sodass ein unnötiger Term-Anstieg ausbleibt. Wer das klassische Verhalten bevorzugt, schaltet den Standard-Raft-Leader-ID-Modus zu. Auf der Roadmap steht außerdem Pre-Vote, ein Verfahren, bei dem ein Knoten seine Peers vor einer Term-Erhöhung fragt, ob sie ihm eine Stimme gewähren würden; es ist seit dem 12. Juni 2026 abgehakt und wird über Config::enable_pre_vote eingeschaltet. Vorgemerkt sind flexible Quoren etwa nach dem Vorbild hierarchischer ZooKeeper-Quoren sowie getrennte Lese- und Schreibquoren für Cluster mit gerader Knotenzahl.

Zweige, Alpha-Status und die Commit-Präfixe

Die Versionspflege folgt einem klaren Muster. Der main-Zweig gehört zur release-0.10-Linie, deren aktuellste crates.io-Fassung die Alpha v0.10.0-alpha.34 ist; das README warnt, dass sich die 0.10-API vor dem endgültigen Release noch ändern kann. Für die stabile Linie steht release-0.9 mit der Fassung v0.9.25 vom Juli 2026, die laut README keine neuen Funktionen mehr annimmt, sondern nur Fehlerbehebungen. Die Zweige release-0.8, release-0.7 und release-0.6 sind geschlossen, ihre Upgrade-Anleitungen bleiben veröffentlicht.

Bis zur Version 1.0.0 gilt die API ausdrücklich als nicht stabil, ein Upgrade kann inkompatible Änderungen enthalten. Um solche Brüche erkennbar zu machen, beginnen Commit-Nachrichten mit Schlüsselwörtern: data-change markiert Änderungen an On-Disk-Datenformaten, die manuelle Migration erfordern können; change kennzeichnet inkompatible Änderungen; feat steht für kompatible neue Funktionen und fix für reine Fehlerbehebungen. Für den Wechsel von 0.9 auf 0.10 existiert eine eigene Upgrade-Anleitung.

Benchmarkzahlen mit bewusster Einschränkung

Die Leistungszahlen des README stammen aus einem Benchmark, der nur das OpenRaft-Framework selbst misst, auf einem minimierten Speicher und Netzwerk. Das README bezeichnet diese Begrenzung mit Nachdruck mit Nachdruck: Es handelt sich nicht um einen Benchmark für reale Anwendungen. Gemessen wurden Einzelschreibvorgänge von 33000 pro Sekunde bei einem Client, 912000 bei 64 Clients, 1808000 bei 256 Clients, 3006000 bei 1024 Clients und 3548000 bei 4096 Clients.

Mit Batching von vier Einträgen je Aufruf erreicht die Messung 5615000 Schreibvorgänge pro Sekunde bei 4096 Clients. Details zum Messaufbau liegen im Verzeichnis benchmarks/minimal des Repositorys. Für die eigene Kapazitätsplanung bedeutet das: Diese Werte zeigen das Potenzial des Frameworks unter Idealbedingungen, ersetzen aber keine Messung in der geplanten Anwendung mit realen Storage-Treibern und Netzlatenzen.

Chaostests in jeder CI-Pipeline

Zur Robustheitsprüfung setzt das Projekt auf zwei Ebenen. Ein deterministischer Simulationsfuzzer auf Basis von turmoil läuft bei jedem CI-Build und schaltet den Cluster Schritt für Schritt durch, wobei nach jedem Schritt die Raft-Invarianten aus dem Paper und der TLA+-Spezifikation geprüft werden. Die Unit-Test-Abdeckung gibt das README mit 92 Prozent an.

Die zweite Ebene ist eine Jepsen-Suite, die bei jedem Push auf main acht Störszenarien fährt: Netzwerkpartition, Prozesspause, Prozessabschuss, langsame Pakete, unzuverlässige Pakete, Uhrabweichung, Mitgliedschaftsumbau sowie alle Szenarien kombiniert. Das README hält zugleich fest, dass der Chaostest noch nicht vollständig ist und weitere Tests zur Absicherung von Robustheit und Zuverlässigkeit nötig bleiben. Diese Mischung aus automatisierten Störtests und offener Selbstbewertung ist ein ehrlicherer Statusbericht als ein bloßes Grüner-Badge-Bild.

Was die API betriebsbereit stellt

Das README zählt die Operationen auf, die der Raft-Typ bereitstellt: Leader-Wahl nach Richtlinie oder manuell ausgelöst, Leader-Transfer, eine Nichtwähler-Rolle namens Learner, Log-Kompaktierung über Snapshots der Zustandsmaschine, Snapshot-Replikation, dynamische Mitgliedschaft über gemeinsamen Konsens, linearisierbares Lesen über ensure_linearizable sowie Metriken über drei getrennte Methoden. Heartbeat- und Wahlverhalten lassen sich zur Laufzeit umschalten, Snapshots, Wahlen und Logbereinigung auch manuell anstoßen.

Die Konfiguration läuft über RaftTypeConfig, mit dem Speicher, Netzwerk und Kerntypen ausgetauscht werden. Als Laufzeiten nennt das README tokio als Voreinstellung sowie compio und monoio über das AsyncRuntime-Trait, dazu einen Single-Thread-Modus ohne Send-Anforderungen. Die Implementierung arbeitet asynchron und ereignisgesteuert ohne periodische Ticks, bündelt Nachrichten und streamt Metriken über Watch-Kanäle; die tracing-Instrumentierung erlaubt eine Filterung der Ausführlichkeit bereits zur Compilezeit.

Nutzerliste und die Lizenzlage im Repository

Als Anwender nennt das README neben Databend unter anderem CnosDB, RobustMQ, RocketMQ-rust und Hiqlite, also Zeitreihendatenbanken, Message-Queues und eingebettetes SQLite. Projekte sind eingeladen, über ein Issue oder einen Pull Request in die Liste aufgenommen zu werden. Diese Mischung zeigt, dass die Bibliothek über den eigenen Produktverbund hinaus produktiv eingesetzt wird, wenngleich die Liste eine Selbstauskunft der Projekte bleibt.

Bei der Lizenz weisen die Repository-Metadaten die SPDX-Kennung Apache-2.0 aus. Fragen zu Support, Gewährleistung oder Sicherheitsprozessen beantworten weder README noch Lizenztext; wer einen produktiven Konsenskern plant, sollte zusätzlich die Issue-Tracker-Aktivität und die Upgrade-Anleitungen zwischen den Linien als Indiz für die Pflegequalität heranziehen. Für den Einstieg verweist das Projekt auf den Getting-Started-Leitfaden auf docs.rs und die Beispiele je Linie im Repository.

Redaktionelles Fazit

OpenRaft eignet sich für Rust-Projekte, die einen Konsenskern mit austauschbaren Laufzeiten und Speicherbindungen suchen und bereit sind, Alphaversionen mit gelegentlich inkompatiblen Änderungen zu verfolgen; die Commit-Präfixe data-change und change im change-log machen solche Brüche nachvollziehbar. Wer stabile Verträge braucht, bleibt bei v0.9.25 auf dem release-0.9-Zweig, der laut README nur noch Fehlerbehebungen erhält, und prüft vor dem Upgrade auf 0.10 die zugehörige Upgrade-Anleitung.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes