CRDTs: So synchronisieren Sie serverlose Daten, um Konflikte zu schlichten

Stellen Sie sich vor, zwei Benutzer bearbeiten dasselbe Dokument auf verschiedenen Ebenen, ohne Internet. Jeder ändert das gleiche Feld. Wenn sie landen und die Geräte synchronisiert werden, muss jemand entscheiden, welche Version gewinnt. Die traditionelle Antwort war einfach und brutal: Der letzte zu speichernde überschreibt den vorherigen. Der andere verliert seinen Job und merkt es nicht einmal.

Dies ist das Kernproblem jeder Local-First-Anwendung. Die Daten verbleiben zunächst auf dem Gerät, die Bearbeitung erfolgt offline und der Abgleich erfolgt später. Die Frage ist nicht, ob es zu Konflikten kommt, sondern wie man zwei unterschiedliche Wahrheiten zusammenführen kann, ohne Informationen zu verlieren und im Idealfall ohne sich auf einen zentralen Server als Richter zu verlassen. CRDTs sind die eleganteste mathematische Antwort, die wir darauf haben.

Was ist ein CRDT ohne Mystik?

CRDT steht für Conflict-free Replicated Data Type. Der Name macht mehr Angst als das Konzept. In der Praxis handelt es sich um eine Datenstruktur, die so konzipiert ist, dass mehrere Kopien unabhängig voneinander bearbeitet werden können und bei ihrem Zusammentreffen automatisch und ohne vorherige Koordination zum gleichen Endzustand konvergieren.

Das Schlüsselwort ist Konvergenz. Es spielt keine Rolle, in welcher Reihenfolge die Änderungen eintreffen, wie oft dieselbe Änderung angewendet wird oder wie viele Sprünge sie durch das Netzwerk durchlaufen hat. Wenn zwei Geräte dieselben Vorgänge sehen, sind sie am Ende identisch. Diese Garantie ist mathematisch und kein Versprechen des guten Willens des Codes.

Um dies zu erreichen, müssen die Operationen eines CRDT drei Eigenschaften haben. Da sie kommutativ sind, ändert die Reihenfolge das Ergebnis nicht. Sie sind assoziativ, daher spielt die Gruppierung keine Rolle. Und sie sind idempotent, sodass die zweimalige Anwendung derselben Sache keinen Schaden verursacht. Strukturen, die diese Regeln respektieren, bilden das, was die Mathematik Halbgitter nennt, und hieraus ergibt sich die Konvergenzgarantie.

Warum dies das Local-First-Problem löst

Ohne CRDTs erfordert die Offline-Synchronisierung einen Schiedsrichter. Normalerweise gewinnt ein Server, der alle Versionen empfängt, eine beliebige Regel anwendet, häufig das berüchtigte Last-Write-Win, und die offizielle Wahrheit zurückgibt. Dies hat zwei Kosten. Die beim Überschreiben verlorenen Daten und die Abhängigkeit von einem zentralen Punkt, der immer online ist, um etwaige Abweichungen zu beheben.

CRDTs lösen diese Abhängigkeit auf. Da die Zusammenführung deterministisch und in die Fabric selbst integriert ist, kann jedes Gerät mit jedem anderen Gerät in jeder Topologie zusammengeführt werden. Zwei Mobiltelefone können sich direkt über Bluetooth synchronisieren, drei Replikate können in einem Mesh zusammenpassen und das Ergebnis ist das gleiche wie bei einem Server, der alles koordiniert. Der Server wird, wenn er existiert, nur zu einem praktischen Relais und nicht zu einer Autorität.

Dadurch ändert sich die Art der Anwendung. Der Benutzer wartet nicht auf eine Netzwerkantwort, um zu sehen, dass seine Änderung übernommen wird, da die lokale Wahrheit bereits gültig ist. Die Synchronisierung erfolgt im Hintergrund und kommt nie mit der Meldung „Ihre Arbeit wurde verworfen“ zurück. Dies macht das App-Erlebnis als moderne kollaborative Editoren so flüssig und ist die technische Grundlage jeder ernsthaften Local-First-Architektur.

Die CRDT-Geschmacksrichtungen, die Sie finden werden

Zwei Hauptstile dominieren. Statusbasierte CRDTs tauschen die gesamte Struktur zwischen Replikaten aus und verwenden zum Kombinieren eine Zusammenführungsfunktion. Sie sind einfach zu begründen, belasten jedoch das Netzwerk, wenn die Datenmenge wächst. Betriebsbasiert oder op-basiert verbreiten nur einzelne Änderungen, was wirtschaftlicher ist, aber eine zuverlässige Betriebsbereitstellungsschicht erfordert.

Über diesen Stilen befindet sich ein Katalog mit vorgefertigten Typen. Zähler, die Inkremente von mehreren Replikaten hinzufügen, ohne welche zu verlieren. Sets, die wissen, wie man Hinzufügungen und Entfernungen auf kohärente Weise mischt, wie z. B. OR-Set. Und der begehrteste Fall ist sequenzieller Text, bei dem jedes Zeichen eine eindeutige und sortierbare Kennung erhält, damit konkurrierende Einfügungen sich nicht überschneiden. Algorithmen wie Yjs und Automerge packen all dies in Bibliotheken, die Sie verwenden können, ohne die Theorie erneut zu implementieren.

Die gute Nachricht für Architekturentscheider ist, dass man ein CRDT selten von Grund auf neu schreibt. Sie wählen die Bibliothek aus, modellieren Ihre Daten anhand der angebotenen Typen und erhalten Konvergenz geschenkt. Die intellektuelle Arbeit besteht darin, den Bereich auf diese Strukturen abzubilden, nicht darin, Theoreme zu beweisen.

Wo CRDTs wirklich glänzen

Sie sind unschlagbar, wenn die Zusammenführungsregel wirklich neutral ist, d. h. wenn das Beibehalten beider Änderungen immer das richtige Verhalten ist. Kollaborativer Text ist das perfekte Beispiel: Wenn zwei Personen unterschiedliche Absätze eingeben, möchten Sie beide Absätze, Punkt. In diese Kategorie fallen Listen, Kanban-Tafeln, Notizen, Vektorzeichnungen und die meisten Produktivitätstools für die Zusammenarbeit.

Sie glänzen auch in Szenarien, in denen die Konnektivität schlecht oder zeitweise unterbrochen ist. Feldanwendungen, Datenerfassung in abgelegenen Gebieten, Geräte, die stundenlang offline sind. In offline-first-Anwendungen ermöglicht Ihnen CRDT, mit der absoluten Gewissheit zu arbeiten, dass bei der nächsten Synchronisierung nichts verloren geht. Automatische Konvergenz ist genau die Garantie, die diese Kontexte erfordern.

Und sie glänzen, wenn Sie den Server aus dem kritischen Pfad entfernen möchten. Peer-to-Peer-Architekturen, lokale Meshes, Synchronisierung zwischen Geräten desselben Benutzers ohne Umweg über die Cloud. All dies ist realisierbar, da die Zusammenführungsintelligenz in den Daten und nicht in der Infrastruktur steckt.

Wo sie nicht die richtige Antwort sind

Hier ist der Teil, der oft unter den Teppich gekehrt wird. CRTDs konvergieren zu einem gültigen Zustand, aber nicht unbedingt zu dem Zustand, den Ihr Unternehmen für richtig hält. Konvergenz ist nicht gleichbedeutend mit erfüllten Geschäftsregeln. Wenn zwei Personen den letzten Sitzplatz auf einem Offline-Flug buchen, führt CRDT problemlos beide Reservierungen zusammen, und Sie haben eine mathematische Garantie für eine Überbuchung.

Konflikte, die eine semantische Entscheidung erfordern, gehören nicht in CRDT. Gleichgewicht, das nicht negativ sein kann, Einzigartigkeit eines Feldes, Zustimmung, die ein anderes ungültig macht, jede Invariante, die ein „Nein, das kann nicht passieren“ braucht, braucht einen echten Schiedsrichter. In diesen Fällen muss die Geschäftsregel den Konflikt entscheiden, und der Versuch, ihn auf die Datenschicht zu übertragen, führt zu subtilen und kostspieligen Fehlern.

Hinzu kommen die Kosten für Arbeitsspeicher und Speicher. Um die Konvergenz sicherzustellen, speichern viele CRDTs Metadaten, die mit dem Bearbeitungsverlauf wachsen. Element-Tombstones, zeichenspezifische Kennungen und Versionsvektoren wurden entfernt. Ohne Verdichtungsstrategien kann eine scheinbar kleine Struktur überraschend stark anschwellen. Nicht jedes Problem wird kostengünstig zu CRDT, und nicht jedes Problem sollte dies auch tun.

Meine Empfehlung als CTO ist pragmatisch. Verwenden Sie CRDT, wenn die Zusammenführung von Natur aus additiv ist und der Erfahrungsgewinn real ist. Wenn die Korrektheit von einer Geschäftsinvariante abhängt, akzeptieren Sie einen Arbiter, sei es ein Server, eine Befehlswarteschlange oder ein expliziter Auflösungsfluss, der dem Benutzer präsentiert wird. Der häufigste Fehler besteht darin, CRDT als Allheilmittel zu betrachten und Überbuchungen in der Produktion zu entdecken.