Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Bewährte Methoden für den Umgang mit gleichzeitigen Aktualisierungen in DynamoDB
In verteilten Systemen können mehrere Prozesse oder Benutzer versuchen, dieselben Daten gleichzeitig zu ändern. Ohne Kontrolle der Parallelität können diese gleichzeitigen Schreibvorgänge dazu führen, dass Aktualisierungen verloren gehen, Daten inkonsistent sind oder es zu Wettlaufbedingungen kommt. DynamoDB bietet mehrere Mechanismen, mit denen Sie den gleichzeitigen Zugriff verwalten und die Datenintegrität aufrechterhalten können.
Anmerkung
Einzelne Schreiboperationen wie z. B. UpdateItem sind atomar und werden unabhängig von der Parallelität immer mit der neuesten Version des Elements ausgeführt. Sperrstrategien sind erforderlich, wenn Ihre Anwendung ein Element lesen und es dann auf der Grundlage des Lese-Werts zurückschreiben muss (ein Lese-Ändern-Schreib-Zyklus), da ein anderer Prozess das Element zwischen dem Lesen und dem Schreiben ändern könnte.
Es gibt zwei Hauptstrategien für den Umgang mit gleichzeitigen Aktualisierungen:
-
Optimistische Sperrung — Geht davon aus, dass Konflikte selten sind. Es ermöglicht den gleichzeitigen Zugriff und erkennt Konflikte beim Schreiben mithilfe bedingter Schreibvorgänge. Wenn ein Konflikt erkannt wird, schlägt der Schreibvorgang fehl und die Anwendung kann es erneut versuchen.
-
Pessimistisches Sperren — Geht davon aus, dass Konflikte wahrscheinlich sind. Es verhindert den gleichzeitigen Zugriff, indem es exklusiven Zugriff auf eine Ressource erhält, bevor sie geändert wird. Andere Prozesse müssen warten, bis die Sperre aufgehoben wird.
Die folgende Tabelle fasst die in DynamoDB verfügbaren Ansätze zusammen:
| Ansatz | Mechanismus | Am besten geeignet für |
|---|---|---|
| Optimistische Sperre | Versionsattribut + bedingte Schreibvorgänge | Niedriger Streitwert, kostengünstige Wiederholungsversuche |
| Pessimistisches Sperren (Transaktionen) | TransactWriteItems |
Multi-item Atomarität, mäßiger Streit |
| Pessimistisches Sperren (Lock-Client) | Dedizierte Sperrtabelle mit Lease und Heartbeat | Long-running Arbeitsabläufe, verteilte Koordination |
Auswahl einer Strategie zur Kontrolle der Parallelität
Verwenden Sie die folgenden Richtlinien, um den richtigen Ansatz für Ihre Arbeitslast auszuwählen:
- Verwenden Sie optimistisches Sperren, wenn:
-
Konflikte kommen selten vor.
Es ist kostengünstig, einen fehlgeschlagenen Schreibvorgang erneut zu versuchen.
Sie aktualisieren jeweils ein einzelnes Element.
- Verwenden Sie Transaktionen, wenn:
-
Sie müssen mehrere Elemente atomar aktualisieren.
Sie benötigen eine Alles-oder-Nichts-Semantik für Elemente oder Tabellen.
Sie müssen Bedingungsprüfungen mit Schreibvorgängen in einem einzigen Vorgang kombinieren.
- Verwenden Sie den Lock-Client, wenn:
-
Sie müssen den Zugriff auf externe Ressourcen über verteilte Prozesse hinweg koordinieren.
Der kritische Abschnitt ist langwierig und es ist kostspielig, bei Konflikten erneut zu versuchen.
Sie benötigen das automatische Ablaufen der Sperre, um Prozessfehler zu behandeln.
Anmerkung
Wenn Sie globale DynamoDB-Tabellen verwenden, beachten Sie, dass globale Tabellen bei gleichzeitigen Aktualisierungen eine Abstimmungsstrategie verwenden, bei der der letzte Writer gewinnt. Optimistisches Sperren mit Versionsnummern funktioniert regionsübergreifend nicht erwartungsgemäß, da ein Schreibvorgang in einer Region einen gleichzeitigen Schreibvorgang in einer anderen Region ohne Versionsprüfung überschreiben kann. Entwerfen Sie Ihre Anwendung so, dass Konflikte auf Anwendungsebene bei der Verwendung globaler Tabellen behandelt werden.
