Korrektheit verteilter Daten
Beginnen Sie mit dem Vertrag
Schreiben Sie die Invariante, ihren Gültigkeitsbereich und die Ausfälle auf, die sie überstehen muss. "Eine Bestellung wird höchstens einmal belastet" ist nützlich; "starke Konsistenz" ist unzureichend. Identifizieren Sie den autoritativen Datensatz, abgeleitete Ansichten, Akteure und jede Commit-/Bestätigungsgrenze. Fragen Sie, ob Clients Lese-Deine-Schreibvorgänge, kausale Ordnung, linearisierbare Operationen, serialisierbare Transaktionen oder lediglich eventuelle Konvergenz benötigen.
Überprüfungsverfahren
- Zeichnen Sie den Schreibpfad auf, einschließlich Datenbank-Commit, Broker-Bestätigung und externer Seiteneffekte. Halten Sie fest, was jede erfolgreiche Antwort nach einem Prozessabsturz, Maschinenverlust oder Replikat-Failover garantiert. Ein Timeout bedeutet unbekanntes Ergebnis, nicht unbedingt fehlgeschlagene Ausführung.
- Zählen Sie Crash-Fenster vor und nach jedem dauerhaften Schritt auf. Wiederholen Sie für jedes Fenster die Operation und prüfen Sie die Invariante. Testen Sie sowohl gleichzeitige als auch sequenzielle Wiederholungsversuche. Verwenden Sie das Fehlerprotokoll.
- Halten Sie einen geschäftlichen Effekt und seinen Deduplizierungsmarker in einer Transaktion zusammen, wenn sie eine Datenbank teilen. Für ausgehende Ereignisse sollten Sie eine transaktionale Outbox in Betracht ziehen. Für entfernte Effekte benötigen Sie einen dauerhaften Idempotenzvertrag des Anbieters oder eine Zustandsmaschine zur Abgleichung. Die Zustellungsgarantien des Brokers enden an ihrer dokumentierten Transaktionsgrenze.
- Identifizieren Sie den Ordnungsbereich: Schlüssel, Partition, Stream oder global. Wählen Sie den engsten Bereich, der die Invariante bewahrt. Ein partitioniertes Log ordnet seine Partitionen; es ordnet nicht automatisch verwandte Ereignisse in verschiedenen Partitionen.
- Für Replikation und Failover überprüfen Sie Wahl, Fencing, Bestätigungsrichtlinie und Wiederherstellung.
R + W > Nergibt eine Schnittmenge unter fester Mitgliedschaft; dies allein etabliert keine Linearisierbarkeit. Siehe Konsistenz. - Für Sharding überprüfen Sie die Transaktionslokalität, heiße Schlüssel, Neuausrichtung und Eindeutigkeitsdurchsetzung. Messen Sie den am stärksten ausgelasteten Shard, nicht nur den Gesamtdurchsatz.
- Produzieren Sie das kleinste Gegenbeispiel zu einer zweifelhaften Garantie und einen Test, der es ausübt. Trennen Sie erforderliche Garantien von akzeptabler Veralterung.
Überprüfungsergebnis
Zurückgeben: Invariante → Annahmen → Ausfallzeitlinie → verletzte Garantie → minimale Lösung → Kosten → Validierung. Fügen Sie einen Wiederherstellungspfad für bereits inkonsistente Daten hinzu. Nennen Sie jedes Verhalten, das von einer Datenbank-, Broker- oder Anbieterversion abhängt.
Überprüfen Sie vor einer Empfehlung
- Kann eine wiederholte Anfrage ihre stabile Operations-ID mit geänderten Parametern wiederverwenden?
- Benötigt ein Leasingnehmer einen monoton steigenden Fencing-Token, der von der Ressource durchgesetzt wird? Leasingablauf allein kann einen pausierten Prozess nicht stoppen.
- Können Replikate unmittelbar nach einem erfolgreichen Schreibvorgang veraltete Werte bereitstellen?
- Laufen Tombstones oder Deduplizierungseinträge vor dem Wiederholungshorizont ab?
- Erfordert eine Multi-Datensatz-Invariante eine Transaktion oder explizite Koordination?
Geltungsbereich und Referenzen
Teilweise Abdeckung in Anlehnung an Designing Data-Intensive Applications, 2. Aufl. (Kleppmann und Riccomini). Diese Originalverfahren verwenden öffentliche Autoren-Kursnotizen und zusätzliche Primärdokumentation; das vollständige Buch war nicht verfügbar. Lesen Sie Quellen für die genaue Zuschreibung. Dieser Skill liefert keine Konsensimplementierung und geht nicht von Byzantinischer Fehlertoleranz aus.