Quorum

In Cassandra oder MongoDB. Du kannst pro Request konfigurieren:

• Write(Consistency=ONE): Schnell, aber unsicher. (Reicht, wenn einer "Ja" sagt).
• Write(Consistency=QUORUM): Sicher, aber langsamer. (Braucht Mehrheit).
• Write(Consistency=ALL): Paranoid. (Fällt aus, wenn nur einer down ist). Quorum ist der Sweet Spot zwischen Availability und Consistency.

1. Sloppy Quorum

In DynamoDB (Amazon). Wenn die eigentlichen Nodes (A, B, C) down sind, schreibt man temporär auf D (Hinted Handoff). Das erfüllt $W=2$, aber nicht auf den richtigen Nodes. Daten sind sicher, aber man muss sie später zurückspielen. Gibt High Availability, opfert aber kurzzeitig Konsistenz.

2. Majority

Warum meistens $N/2 + 1$? Um "Split Brain" zu verhindern. Wenn das Netzwerk durchgeschnitten wird (Partition), kann nur eine Seite die Mehrheit haben. Die andere Seite muss schweigen (oder Read-Only gehen).

1. Vector Clocks und Konfliktauflösung (LWW)

Wenn zwei parallele Updates in DynamoDB auf genau gegenüberliegenden Seiten des Quorums landen (Netzwerk-Split), welches Update gewinnt beim Merge? Manche verteilte Systeme nützen Last-Write-Wins (LWW). Der Node mit dem höchsten Timestamp (timestamp=1502) überschreibt den anderen gnadenlos. Problem: System-Uhren sind asynchron (NTP Clock Drift). LWW führt unweigerlich zu massiven Datenverlusten bei hohen Transactions. Professionell gelöst wird dies mit Vector Clocks: Jedes gesicherte Datenbank-Tuple führt einen Vektor aller Änderungen mit, z.B. [NodeA:2, NodeC:1]. Wenn Client X etwas Neues pusht und sein Vektor konvergierend ist, fügt sich der Branch. Befinden sich zwei konfligierende Vektoren im System ([A:2,C:1] vs [A:1, C:2]), kapituliert die Datenbank. Sie sendet alles ans Frontend ("Read Repair / Siblings") und verlangt, dass die Applikations-Logik des Entwicklers den Merge-Konflikt selber behebt.

2. The Paxos/Raft Quorum (Strict Majority)

Cassandra trennt Read- und Write-Quorums frei wählbar ($R=2, W=2$). Das ist weich und kann auf Latenz-Wünsche der Endpunden optimiert werden. Für Hard-Consensus Algorithmen (Raft, Paxos, Zookeeper), die Leader-Elections oder starke Linearizability erzwingen, existiert nur eine eiserne Wahrheit: Eine strikte Mehrheit ($M > \lfloor N/2 \rfloor$). In einem Cluster von 5 Nodes blockt Raft rigoros, bis 3 Knoten den Log-Eintrag festgeschrieben haben. Cluster werden absichtlich niemals mit gerader Anzahl (4, 6, 8 Racks) gebaut! Bei 4 Nodes wäre das Majority-Quorum $\lfloor 4/2 \rfloor + 1 = 3$. Das Cluster toleriert genau 1 Ausfall. Bei 3 Nodes ist das Majority-Quorum 2. Das Cluster toleriert exakt genau denselben 1 Ausfall! Der vierte Server verschwendet 25% Hardware-Kosten für exakt absolut null Zugewinn an Fehlertoleranz, sondern potenziert nur das Risiko von Leader-Ties.

3. Sloppy Quorum & Hinted Handoffs

Wenn Amazon an Weihnachten Rekordzugriffe hat und Node B stirbt, darf der "In den Warenkorb" Button niemals eine Exception werfen. Normale DBs (Strict Quorum) würden abblocken, wenn $W=2$ unerreichbar ist. DynamoDB erfand das Sloppy Quorum: Ist der korrekte Hash-Replica-Node B offline, schreibt der Coordinator die Daten für B temporär beim völlig Fremden Node D ab ("Kuckucksei"). Der Read fällt ab nun eventuell veraltet aus (Eventual Consistency tritt rein), aber das Write-Quorum wurde formal erfüllt, der Kunde kauft glücklich weiter ein. Node D speichert den Datensatz isoliert (Hinted Handoff). Sobald Node B vom Netz-Ausfall zurückkehrt, klopft D bei ihm an: "Hallo, ich hab da was für dich aufgehoben!" und schiebt die Ghost-Daten transparent rüber in die korrekte Partition.