Come risolvere i doppi attacchi di prelievo sui database decentralizzati

Question

Come risolvere i doppi attacchi di prelievo sui database decentralizzati

#1 da (5 voti)

1

Ho bisogno di un modo per risolvere i doppi attacchi di prelievo nei database decentralizzati.

Ad esempio, un'infrastruttura bancaria ha più server con i propri database, il vantaggio è che consente ai cittadini di avere ritiri rapidi e bassa latenza, con dati ridondanti.

Lo svantaggio è che consente attacchi con doppia transazione, il che significa che un cittadino potrebbe andare a due bancomat e ritirarsi allo stesso tempo, prima che i database separati si siano riconciliati.

In che modo questo problema può essere risolto e queste soluzioni hanno nomi specifici?

database data

posta mateos 04.03.2018 - 16:43

fonte

1 risposta

Leggi altre domande sui tag database data

La copertura del codice ha senso quando si eseguono test end-to-end? Richiamo di un metodo statico dall'elenco di inizializzazione dei membri del costruttore

score 5 · Answer 1

Questo è uno scenario in cui la coerenza finale è un modello di coerenza totalmente inadatto. Vuoi davvero un database ACID che garantisca:

Una transazione è avvenuta o non è successo.
Dopo che una transazione è stata completata con successo, tutte le letture vedranno lo stato dopo questa transazione - gli accessi al database possono essere linearizzati come se ci fosse un chiaro "prima" e "dopo", anche se le letture possono accadere da più DB.

Un modo per implementare questo in un sistema distribuito è che le scritture devono prima essere completate in tutti i database prima che il database di scrittura risponda al cliente con successo. Se i database distribuiti ricevono due transazioni che modificano gli stessi valori, uno o entrambi falliranno e verranno ripristinati.

In pratica, è molto scomodo utilizzare un sistema distribuito dove la coerenza è molto importante. Invece, un sistema master / di backup è molto più semplice da costruire: tutte le richieste di scrittura vanno in un unico database che rispecchia le scritture negli altri DB nel cluster. Una scrittura viene contrassegnata come completata solo dopo che la scrittura è stata sincronizzata con tutti i backup. Le richieste di lettura possono essere risolte da tutti i DB nel cluster. Se il master fallisce, qualsiasi DB di backup può essere promosso al nuovo master.