Zum Hauptinhalt springen

Konzepte der Geo-Replikation und Multi-Site-Replikation

Die Geo-Replikation ermöglicht es, dass sich ein Clustron-Zaris-Store über mehr als ein Rechenzentrum erstreckt. Zwei (oder mehr) unabhängige Cluster — einer pro Region — nehmen jeweils lokal Schreibzugriffe entgegen und replizieren sich gegenseitig über einen wiederaufnehmbaren, Pull-basierten Change Feed. Dies ist das Konzeptmodell; die Architekturseite beschreibt, wie es aufgebaut ist, und der Entwicklerleitfaden erläutert, wie Sie es aktivieren und betreiben.

Die Geo-Replikation ist neu in Zaris 2.1.0 und standardmäßig deaktiviert — ein Store ohne Site-Konfiguration verhält sich exakt wie ein normaler Single-Site-Store.

Eine Site ist ein unabhängiger Cluster​

Eine Site ist ein vollständiger Zaris-Cluster — mit eigener Mitgliedschaft, Partitionsübersicht, eigenem Ownership und lokalem Quorum — identifiziert durch eine Site-ID. Die Geo-Replikation koppelt Sites ausschließlich über den Change Feed; sie ist bewusst kein gestreckter Cluster.

SITE A · REGION WESTindependent clusterCluster An1n2n3partitioned · RF ≥ 2op-log → change feedrevision-ordered · watermark-gatedSITE B · REGION EASTindependent clusterCluster Bn1n2n3partitioned · RF ≥ 2op-log → change feedrevision-ordered · watermark-gatedchange feed →← change feedWAN linkpull · resumable
Two independent clusters, coupled only by a resumable, pull-based change feed — not a stretched cluster.

Unabhängige Sites sind der Kern eines In-Memory-Stores: Die Latenz des WANs gelangt nie in einen lokalen Schreibpfad, und eine WAN-Partition verschlechtert die Replikationsverzögerung, niemals die lokale Verfügbarkeit. Der Preis ist eventuelle Konsistenz zwischen den Sites, begrenzt durch diese Verzögerung — sie wird sichtbar gemacht, statt verborgen zu bleiben.

Der Change Feed koppelt die Sites​

Jeder Segment-Owner führt bereits ein nach Revision geordnetes Op-Log seiner Mutationen. Der Change Feed ist genau das Ende dieses Op-Logs, bereitgestellt als wiederaufnehmbarer Stream und begrenzt auf das, was auf einem Replikat dauerhaft ist. Ein Peer zieht (Pull) den Feed und wendet ihn lokal an. Da der Feed Pull-basiert ist, besitzt jede Site ihre eigene Position und Flusssteuerung.

  • Cursor — die dauerhafte Position einer Site im Feed eines Peers, ein Paar (generation, revision). Die Sortierung nach Generation zuerst hält einen Consumer auch über die eigenen Failover des Peers hinweg korrekt. Nach einem Neustart oder einer WAN-Unterbrechung setzt eine Site an ihrem Cursor fort, statt von Grund auf neu zu synchronisieren.
  • Origin — die Site, die einen Wert zuerst geschrieben hat. Ein Feed liefert nur Änderungen eigener Herkunft, sodass ein Schreibvorgang in einer bidirektionalen Topologie nie im Kreis zurückläuft.

Active-Passive und Active-Active​

  • Active → Passive — eine Site ist der aktive Primary; der Peer ist ein schreibgeschützter Spiegel, der ihr über den Feed folgt und Anwendungsschreibzugriffe ablehnt (Lesezugriffe und Watches funktionieren weiterhin).
  • Active-Active — jede Site ist aktiv und führt jede andere Site als Peer auf. Jede Site nimmt lokal Schreibzugriffe entgegen, zieht den Feed jedes Peers, und alle Sites konvergieren.

Wie gleichzeitige Schreibvorgänge konvergieren​

Wenn zwei Sites ungefähr gleichzeitig denselben Key schreiben, ist das Ergebnis deterministisch und symmetrisch — jede Site ermittelt denselben Gewinner, sodass alle Sites ohne einen vermittelnden Koordinator identisch enden.

Concurrent writes to key K at two sitesresolve by value kind ↓SCALARSHLC last-writer-winsphysical · logical · site idCOUNTERSPN-countersum of per-site parts · nothing lostDELETESVersioned tombstonenewer delete beats older putEvery site converges to the same value
Resolution is deterministic and symmetric — every site computes the same winner, so all sites converge.
  • Konfliktversion — eine hybride logische Uhr (physicalMs, logical) plus die Origin-Site-ID, einmalig beim ursprünglichen Schreibvorgang gesetzt. Last-Writer-Wins vergleicht diese der Reihe nach: physische Zeit, dann logischer Zähler, dann Site-ID.
  • Skalare verwenden Last-Writer-Wins: Der unterlegene gleichzeitige Schreibvorgang wird verworfen. Verwenden Sie Zähler, wenn jedes Update erhalten bleiben muss.
  • Zähler verwenden einen PN-Counter: Jede Site trägt ihre eigene Komponente bei, und der Wert ist die Summe, sodass gleichzeitige Inkremente an verschiedenen Sites nie verloren gehen.
  • Collections (Hash, List, Set, Sorted-Set, Stream) unterliegen in diesem Release dem Whole-Value-Last-Writer-Wins — eine gleichzeitige Änderung ersetzt den gesamten Wert anhand der Version, ohne Merge auf Feldebene.
  • Löschvorgänge sind versionierte Tombstones, die nach derselben Regel entschieden werden; ein Clear ist Geo-aware und wird als versionierte Tombstones repliziert, statt nur lokale Daten zu verwerfen.

Was Site-lokal bleibt​

Die Geo-Replikation bringt Daten zur Konvergenz, nicht die Koordination. CAS, Transaktionen, Locks und Leases sind Site-lokal — verwenden Sie sie nicht für den siteübergreifenden gegenseitigen Ausschluss. TTL wird als absolutes Ablaufdatum übertragen, sodass ein Element auf jeder Site zur selben Uhrzeit (Wall-Clock) abläuft (halten Sie die Uhren per NTP synchron). Ein lokaler Watch wird nur ausgelöst, wenn eine eingehende Änderung ihre Konfliktauflösung gewinnt.

Konsistenzmodell​

Die Geo-Replikation ist zwischen den Sites eventuell konsistent: Ein Lesezugriff spiegelt den Zustand der lokalen Site wider, und die Sites konvergieren, während sich der Feed ausbreitet. Es gibt weder siteübergreifendes Read-your-write noch Linearisierbarkeit — das ist der bewusste Kompromiss für unabhängige, latenzarme regionale Verfügbarkeit.

Verwandte Themen​