Ein Quorum ist die Mindestanzahl von Knoten (oder Stimmen), die eine Operation in einem verteilten System bestätigen muss, bevor sie als ausgeführt gilt. Ohne Quorum-Regeln könnten gleichzeitige Lese- und Schreibzugriffe auf verschiedenen Replikaten auseinanderlaufen — mit ihnen lässt sich steuern, wie stark Konsistenz und Verfügbarkeit gewichtet werden.
Die Grundidee
Ein Cluster hält N Replikate eines Datums. Statt mit allen zu synchronisieren, verlangt das System nur eine Teilmenge: Das Schreib-Quorum (W) ist die Zahl der Replikate, die einen Schreibzugriff bestätigen müssen, das Lese-Quorum (R) die Zahl, die bei einer Leseanfrage befragt werden. Die zentrale Regel lautet:
R + W > NÜberlappen sich Lese- und Schreib-Quorum in mindestens einem Knoten, ist jede gelesene Antwort garantiert aktuell: Der eine Knoten, der beide Quoren bedient, kennt den neuesten Stand. Bei N = 3 Replikaten ist die übliche Wahl R = 2, W = 2 (eine Mehrheit).
Mehrheit und flexible Quoren
Das klassische Majority-Quorum verlangt mehr als die Hälfte der Knoten (bei N = 3 also 2). Es ist die Grundlage vieler Konsens-Algorithmen wie Raft. Flexible Quoren erlauben dagegen beliebige R- und W-Werte, solange R + W > N gilt — etwa W = 1 für schnelles Schreiben und R = N für starke Lese-Konsistenz. Ein großes W erhöht die Haltbarkeit: Ein Write gilt erst als bestätigt, wenn genügend Kopien existieren, die einen späteren Ausfall überleben.
Quorum und tunable Consistency
Datenbanken wie Cassandra und DynamoDB machen die Quoren pro Anfrage einstellbar (tunable consistency). Eine Anwendung kann für kritische Schreibvorgänge ein großes W wählen, für unkritische Lesezugriffe ein kleines R. Das schafft den CAP-Trade-off zwischen Konsistenz und Latenz bewusst konfigurierbar und ist eng mit Eventual Consistency verzahnt: Ohne garantierte Überlappung der Quoren liefert ein System nur irgendwann aktuelle Werte.
Grenzen
Quoren garantieren keine lineare Konsistenz, wenn Schreibvorgänge parallel laufen, Uhren nicht synchron sind oder Hinted Handoff und Read Repair die Daten später nachreichen. Sie sind ein wichtiger Baustein, aber kein Ersatz für die Konsens-Mechanismen, die sich darüberlegen lassen.
Verwandte Grundlagen: Sharding, Cluster, Datenbank-Replikation, Hochverfügbarkeit.