Paxos

Indirekt. Du nutzt ZooKeeper oder Etcd (die nutzen ZAB oder Raft, was Paxos-Varianten sind). Wenn du "Leader Election" brauchst ("Wer darf den Cronjob ausführen?"). Paxos sorgt dafür, dass es niemals zwei Leader gleichzeitig gibt (Split Brain Impossible).

1. Phasen (Synod Protocol)

Ähnlich wie 2PC, aber robuster.

1. Prepare: Proposer wählt eine Nummer N und fragt Mehrheit: "Versprecht ihr, auf niemanden mit Nummer < N zu hören?"
2. Promise: Acceptors antworten: "OK, ich höre auf dich (und hier ist der letzte Wert, den ich gesehen habe)."
3. Accept: Proposer sagt: "Dann stimmt bitte für Wert V ab!"
4. Accepted: Acceptors stimmen zu. Konsens erreicht.

2. Multi-Paxos

Basic Paxos entscheidet nur einen Wert. Datenbanken brauchen eine Sequenz von Werten (Log). Multi-Paxos optimiert das Protokoll, indem ein stabiler Leader gewählt wird. Dann entfällt Phase 1 für nachfolgende Requests. (Performance wie 1 Round-Trip).

1. Dueling Proposers (Livelock) & FLP Impossibility

Das mathematische Grundproblem von Paxos ist das "FLP Impossibility Result" (Fischer, Lynch, Paterson, 1985). Es beweist, dass deterministischer Konsensus in einem asynchronen System (wo Messages beliebig lange verzögert werden können) unmöglich ist, falls auch nur ein einziger Knoten abstürzt. Paxos "löst" dieses Theorem nicht, es umgeht es pragmatisch, indem es Liveness (Fortschritt) opfert, aber Safety garantiert. Der gefährlichste State ist der Dueling Proposers Livelock: Knoten A schickt Prepare(N=1). Die Mehrheit verspricht (Promise) N=1. Knoten B wacht auf, schickt sofort Prepare(N=2). Die Mehrheit bricht ihr Versprechen für N=1 und verspricht N=2. Knoten A versucht nun den Accept(N=1) und scheitert. Aus Rache schickt er direkt Prepare(N=3). Die Knoten blockieren sich endlos im Prepare-Ping-Pong. Keine Phase 2 wird jemals abgeschlossen. Die Lösung in der Produktion: Randomized Exponential Backoff bei Abstammungs-Fehlschlägen (ähnlich wie CSMA/CD beim Ethernet).

2. Spanner & TrueTime API (Leader Leases)

Multi-Paxos braucht einen stabilen Leader, ansonsten degeneriert jeder State-Request in teure 2 Round-Trips. Wie weiß Knoten A in einer weltweit verteilten Google-Datenbank, dass er noch "der legitime Leader in Kontinent Europa" ist und die Verbindung zu den anderen nicht isoliert wurde? Wenn A isoliert ist und fröhlich weiter Client-Daten als Leader akzeptiert, entsteht am Ende des "Split Brains" Inkonsistenz. Google löste das im Spanner-System durch Hardware: Rubidium-Atomuhren und GPS-Empfänger in jedem Rack bieten die TrueTime API. The Leader bekommt einen "Lease" (Mietvertrag für die Leitung) für 10 Sekunden. Dank TrueTime garantiert Google, dass die physikalische Clock Drift absolut niemals 7 Millisekunden pro Sekunde übersteigt. Der Leader weiß, dass er safe lesen und schreiben kann, ohne die anderen im Quorum jedes Mal per Netzwerk fragen zu müssen ("Bin ich noch Boss?"), solange der Lease-Timestamp unter Abzug der maximal garantierten Hardware-Ungenauigkeit gilt.

3. Disk Sync vs SSD fsync Latenz

Ein Konsensus-Algorithmus schützt vor Netzwerk-Ausfällen. Aber was ist bei Stromausfall des Racks? Damit ein Acceptor in Phase 2 legal ein "Accepted" antworten darf, muss seine Stimme zwingend nicht nur im RAM-Log, sondern persistiert im Storage Flush Cycle landen. Das führt im Paxos/Raft oft zu massiven Bottlenecks: Jeder Commit wartet auf den fsync() Syscall des Linux Kernels auf die Disk. Bei alten HDDs dauerte das 10-20ms pro Write. In Hochdurchsatz-Systemen führt man daher "Group Commits" ein: Mehrere hunderte Konsens-Operationen (State-Machine Transitions) werden künstlich im RAM gebuffert und mit einem einzigen gigantischen NVMe Flush atomar als Batch auf die Disk zementiert. Das hebt den Durchsatz von 100 auf $100.000$ TPS, opfert aber oft wenige Millisekunden an Latenz.