Pessimistisches Sperren mit DynamoDB-Transaktionen - Amazon DynamoDB

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.

Pessimistisches Sperren mit DynamoDB-Transaktionen

DynamoDB-Transaktionen bieten einen all-or-nothing Ansatz für gruppierte Operationen. Wenn Sie verwendenTransactWriteItems, überwacht DynamoDB alle Elemente in der Transaktion. Wenn ein Element während der Transaktion durch einen anderen Vorgang geändert wird, wird die gesamte Transaktion storniert und DynamoDB gibt a zurück. TransactionCanceledException Dieses Verhalten bietet eine Form der pessimistischen Parallelitätskontrolle, da widersprüchliche gleichzeitige Änderungen verhindert und nicht erst im Nachhinein erkannt werden.

Wann sollten Transaktionen zum Sperren verwendet werden

Transaktionen eignen sich gut, wenn:

  • Sie müssen mehrere Elemente atomar aktualisieren, entweder innerhalb derselben Tabelle oder tabellenübergreifend.

  • Ihre Geschäftslogik erfordert all-or-nothing Semantik — entweder sind alle Änderungen erfolgreich oder es werden keine angewendet.

Zu den häufigsten Beispielen gehören der Transfer von Geld zwischen Konten, das Aufgeben von Bestellungen, mit denen sowohl das Inventar als auch die Bestelltabelle aktualisiert werden, und der Austausch von Gegenständen zwischen Spielern in einem Spiel.

Kompromisse

Höhere Schreibkosten

Bei Elementen mit einer Größe von bis zu 1 KB verbrauchen Transaktionen 2 WCUs pro Element (eine für die Vorbereitung, eine für die Übertragung), verglichen mit 1 WCU für einen Standardschreibvorgang.

Limit für Artikel

Eine einzelne Transaktion kann bis zu 100 Aktionen in einer oder mehreren Tabellen umfassen.

Konfliktsensitivität

Wenn ein Element in der Transaktion durch einen anderen Vorgang geändert wird, schlägt die gesamte Transaktion fehl. In Szenarien mit hohem Streitaufkommen kann dies zu häufigen Stornierungen führen.

Implementierung

Das folgende Beispiel verwendet die atomare Übertragung TransactWriteItems von Inventar zwischen zwei Artikeln. Wenn ein anderer Prozess einen der Artikel während der Transaktion ändert, wird der gesamte Vorgang rückgängig gemacht.

import boto3 client = boto3.client('dynamodb') def transfer_inventory(source_id, target_id, quantity): try: client.transact_write_items( TransactItems=[ { 'Update': { 'TableName': 'Inventory', 'Key': {'ItemID': {'S': source_id}}, 'UpdateExpression': 'SET QuantityLeft = QuantityLeft - :qty', 'ConditionExpression': 'QuantityLeft >= :qty', 'ExpressionAttributeValues': { ':qty': {'N': str(quantity)} } } }, { 'Update': { 'TableName': 'Inventory', 'Key': {'ItemID': {'S': target_id}}, 'UpdateExpression': 'SET QuantityLeft = QuantityLeft + :qty', 'ExpressionAttributeValues': { ':qty': {'N': str(quantity)} } } } ] ) return True except client.exceptions.TransactionCanceledException as e: print(f"Transaction canceled: {e}") return False

In diesem Beispiel überprüft der Bedingungsausdruck, ob ausreichend Inventar vorhanden ist, aber kein Versionsattribut erforderlich ist. DynamoDB bricht die Transaktion automatisch ab, wenn ein Element in der Transaktion durch einen anderen Vorgang zwischen den Vorbereitungs- und Übertragungsphasen geändert wird. Dies ermöglicht die pessimistische Parallelitätskontrolle — widersprüchliche gleichzeitige Änderungen werden durch die Transaktion selbst verhindert.

Anmerkung

Sie können Transaktionen mit optimistischem Sperren kombinieren, indem Sie Versionsprüfungen als zusätzliche Bedingungsausdrücke hinzufügen. Dies bietet eine zusätzliche Schutzebene, ist jedoch nicht erforderlich, damit die Transaktion Konflikte erkennt.

Weitere Informationen finden Sie unter Verwalten komplexer Workflows mit DynamoDB-Transaktionen.