Gossip Protocol

• Cassandra: Nodes finden sich via Gossip.
• Serf / Consul (HashiCorp): Nutzen SWIM (ein optimiertes Gossip-Protokoll), um Cluster-Mitglieder zu verwalten.
• Bitcoin: Transaktionen verbreiten sich per Gossip durch das P2P-Netzwerk.

1. Push vs Pull

• Push: Ich habe News, ich sende sie dir. (Gut für schnelle Verbreitung).
• Pull: Ich frage dich: "Hast du was Neues?" (Gut, um sicherzugehen, dass man nichts verpasst hat). Die meisten Protokolle (Anti-Entropy) nutzen Push-Pull-Mix.

2. Konvergenz

Wie lange dauert es? Mathematisch $O(\log N)$. Bei 1000 Nodes und Gossip jede Sekunde haben sich News in ~10 Runden (Sekunden) überall verteilt. Explosionsartige Verbreitung.

1. SWIM (Scalable Weakly-consistent Infection-style Membership) Protocol

Das klassische All-to-All Heartbeating crasht bei Clustern > 1000 Nodes am reinen Netzwerk-Ovehead des Pings ($\mathcal{O}(N^2)$ Nachrichtendichte). HashiCorp Consul implementiert das am MIT (2002) entwickelte SWIM Protokoll zur Ausfallerkennung. Ein Node A pingt alle $T$ Sekunden nur einen zufälligen Node B. Antwortet B nicht (Network Partition), deklariert A ihn nicht sofort für tot. A bittet zwei andere Nodes C und D: "Ping mal bitte B für mich" (Indirect Ping). Wenn das auch fehlschlägt, infiziert A den Cluster epidemisch mit dem Gerücht "B ist tot" (Suspect). Das reduziert False Positives im Multi-AZ Cloud Netzwerk dramatisch, während die Bandbreite strikt limitiert und konstant auf $\mathcal{O}(N)$ gedeckelt bleibt.

2. Anti-Entropy Mechanismen

Nachrichtenverluste durch UDP-Packet Drops lassen das Gerücht unvollständig. Man braucht einen Resolver-Prozess im Hintergrund: die Anti-Entropy. Nodes tauschen periodisch Hashes (z.B. Merkle Trees) ihres gesamten Datenbank/Metadaten-Zustands aus. Stimmen die Root-Hashes nicht überein, haben die Nodes unterschiedlichen Zustand. Sie traversieren den Baum von oben nach unten, finden den Knotenpunkt der Nichtübereinstimmung, und synchronisieren nur dieses fehlende Delta-Gerücht. Apache Cassandra und DynamoDB basieren kritisch auf diesem Verfahren, um nach stundenlangen Cluster-Partition-Splits wieder Bit-exakte "Eventual Consistency" zu heilen.

3. Vivaldi Network Coordinates und Geo-Awareness

Randomisiertes Gossiping wirft Requests rücksichtlos um die ganze Weltkügelkrümmung, anstatt den Node im Rack nebenan zu nutzen. Um Topologien intelligent zu formen, statten Enterprise-Protokolle (Nutzen Serf) Nodes mit "Netzwerkkoordinaten" nach dem Vivaldi System aus. Jedes Mal wenn Node A Node B pingt, misst er den RTT-Abstand (Round Trip Time) in Nanosekunden und berechnet daraus, wo B sich in einem imaginären euklidischen Feder-Masse-Modell befinden muss. Die Euclidean-Abstände im Cluster simulieren die reale Latenzkarte des Internets. Das bedeutet, das Gossip-Tratschen präferiert lokal benachbarte Server, und Queries werden extrem Latenz-effizient vom nächsten Replica ge-served.