Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Le migliori pratiche per la gestione degli aggiornamenti simultanei in DynamoDB
Nei sistemi distribuiti, più processi o utenti possono tentare di modificare gli stessi dati contemporaneamente. Senza il controllo della concorrenza, queste scritture simultanee possono portare alla perdita di aggiornamenti, alla mancata coerenza dei dati o alle condizioni di gara. DynamoDB offre diversi meccanismi per aiutarti a gestire l'accesso simultaneo e mantenere l'integrità dei dati.
Nota
UpdateItemLe singole operazioni di scrittura, ad esempio Atomic, funzionano sempre sulla versione più recente dell'elemento, indipendentemente dalla concorrenza. Le strategie di blocco sono necessarie quando l'applicazione deve leggere un elemento e quindi riscriverlo in base al valore di lettura (un read-modify-write ciclo), poiché un altro processo potrebbe modificare l'elemento tra la lettura e la scrittura.
Esistono due strategie principali per la gestione degli aggiornamenti simultanei:
-
Blocco ottimistico: presuppone che i conflitti siano rari. Consente l'accesso simultaneo e rileva i conflitti in fase di scrittura utilizzando scritture condizionali. Se viene rilevato un conflitto, la scrittura fallisce e l'applicazione può riprovare.
-
Blocco pessimistico: presuppone la probabilità di conflitti. Impedisce l'accesso simultaneo acquisendo l'accesso esclusivo a una risorsa prima di modificarla. Gli altri processi devono attendere il rilascio del blocco.
La tabella seguente riassume gli approcci disponibili in DynamoDB:
| Approccio | Meccanismo | Ideale per |
|---|---|---|
| Blocco ottimistico | Attributo di versione + scritture condizionali | Tentativi a basso livello di contesa e poco costosi |
| Blocco pessimistico (transazioni) | TransactWriteItems |
Atomicità multielemento, contesa moderata |
| Blocco pessimistico (lock client) | Tavolo di chiusura dedicato con leasing e battito cardiaco | Flussi di lavoro di lunga durata, coordinamento distribuito |
Scelta di una strategia di controllo della concorrenza
Utilizza le seguenti linee guida per scegliere l'approccio giusto per il tuo carico di lavoro:
- Utilizza il blocco ottimistico quando:
-
I conflitti sono rari.
Riprovare una scrittura fallita è poco costoso.
Si sta aggiornando un singolo elemento alla volta.
- Utilizza le transazioni quando:
-
È necessario aggiornare più elementi in modo atomico.
È necessaria la all-or-nothing semantica tra elementi o tabelle.
È necessario combinare i controlli delle condizioni con le scritture in un'unica operazione.
- Usa il lock client quando:
-
È necessario coordinare l'accesso alle risorse esterne attraverso i processi distribuiti.
La sezione critica è di lunga durata e riprovare in caso di conflitto è costoso.
È necessaria la scadenza automatica del blocco per gestire gli errori del processo.
Nota
Se utilizzi tabelle globali DynamoDB, tieni presente che le tabelle globali utilizzano una strategia di riconciliazione «l'ultimo scrittore vince» per gli aggiornamenti simultanei. Il blocco ottimistico con i numeri di versione non funziona come previsto in tutte le regioni, perché una scrittura in una regione può sovrascrivere una scrittura simultanea in un'altra regione senza un controllo della versione. Progetta l'applicazione in modo da gestire i conflitti a livello di applicazione quando utilizzi tabelle globali.
