Quali sono alcuni approcci utilizzati nelle applicazioni finanziarie per prevenire problemi di sincronizzazione deposito / ritiro?

Question

Quali sono alcuni approcci utilizzati nelle applicazioni finanziarie per prevenire problemi di sincronizzazione deposito / ritiro?

#1 da (12 voti)
#2 da (2 voti)
#3 da (1 voti)
#4 da (1 voti)

6

Attualmente sto affrontando un problema con un'applicazione che ha funzionalità di deposito / prelievo.

Il database sottostante (Cassandra) non offre blocchi di lettura / scrittura.

Ora supponiamo che l'utente A abbia depositato 100 $ nel suo account, Egli può usare questo credito per inviare 100 e-mail.

Immagina il seguente scenario:

L'utente A apre due diverse schede, t1 e t2, e indica loro la pagina per l'invio di e-mail.
Riempie i campi di entrambe le schede per inviare 100 e-mail e hit inviati quasi alla stessa ora.

Ora ciò accade in background.

Ora 0: t1 controlla se l'utente ha credito sufficiente per l'invio di 100 e-mail? Vero. Lo fa.

Ora 0.01: t2 verifica se l'utente ha credito sufficiente per l'invio di 100 e-mail? Vero. Lui fa. (t1 non ha aggiornato il valore del credito dell'utente).

Ora 0.02: t1 aggiorna il credito a 0 e passa all'invio di 100 e-mail.

Ora 0.03: t2 aggiorna il credito a 0 e passa all'invio di 100 e-mail.

L'utente malintenzionato ha ora inviato 200 e-mail mentre aveva crediti sufficienti per inviare solo 100.

Un approccio sarebbe quello di fare un'azione sottrazione invece di aggiornare , in tal caso t2 imposterà il campo di credito dell'utente a -100, ma l'utente ha già overspent il suo credito.

Quindi, ecco le mie domande:

Qual è il nome accademico o più tecnico di questo problema? Condizione di gara? Sincronizzazione del problema?
Quali sono alcuni approcci per impedire che ciò accada? Ciò potrebbe accadere ovunque venga distribuito il database, come gli inventari dei prodotti Amazon o Visa Card.
Come gestiscono questa situazione nei momenti di picco in cui due clienti possono acquistare un articolo nello stesso momento in cui non effettuano la sovrastampa? o nel caso di Visa, in che modo impediscono a qualcuno di prelevare più del saldo dell'account copiando la sua carta fisica e utilizzandola su due bancomat molto distanti? (aumentando così la probabilità che colpirà due diversi nodi del database che non sono sincronizzati in tempo reale a causa della distanza geografica.)

Sono molto confuso su questo,
Qualsiasi aiuto è molto apprezzato.

enterprise-architecture synchronization architectural-patterns financial

posta Sam 29.04.2018 - 20:09

fonte

4 risposte

Leggi altre domande sui tag enterprise-architecture synchronization architectural-patterns financial

Mantenendo i segreti fuori dal controllo del codice sorgente: stiamo semplicemente spostando il problema? Come fai a sapere quando dividere un metodo oggetto in 2 o più altri metodi?

score 12 · Answer 1

Rapporti

Una transazione esegue il wrapping di tutti i passaggi necessari per una determinata operazione aziendale e garantisce che tutti i passaggi siano riusciti o che tutti eseguano il rollback allo stato originale nel database prima dell'avvio della transazione.

Ulteriori letture
In che modo le transazioni Cassandra sono diverse dalle transazioni RDBMS?

score 2 · Answer 2

Serrature e transazioni non sono realmente necessarie per gestire casi così semplici.

È possibile combinare il controllo e l'aggiornamento in un unico passaggio (o istruzione nel gergo SQL), garantendo un'operazione atomica:

update customer set credit = credit - 100 
where idcustomer = {put the customer id here} 
and credit >= 100

Quando l'operazione sopra descritta fallisce, sai che lo stato è incoerente (il cliente non è valido o non ha abbastanza credito) per poter agire di conseguenza.

score 1 · Answer 3

Coerenza

Con Cassandra o database generico e distribuito questo è un problema di "coerenza" e "coerenza finale". Con la coerenza finale, l'accuratezza, o le letture che escono dal tuo db, "alla fine" saranno coerenti (accurate) con le transazioni che entrano in esso, ma non è garantita.

La coerenza fa parte del Teorema di coerenza, disponibilità e partizionamento della PAC. Con Cassandra DB stai essenzialmente scambiando una certa coerenza per l'alta disponibilità. È un compromesso quando si cerca di ottenere veloci scritture / letture tra più negozi di distribuzione degli stessi dati e anche raggiungere un certo grado di consenso.

Cassandra non ha il concetto di transazioni con rollback, ma invece offre due diverse modalità di coerenza. 1. consistenza "strong" accordabile. 2. coerenza linearizzabile mediante "transazioni leggere". [1] [2]

Si potrebbe anche mescolare questo con controlli a livello di sessione Web e garanzie per integrare la natura del modello di consistenza del database. autorizzi solo una sessione utente alla volta. Usa semafori a livello di sessione per il tuo db. Ma viene fornito con le sue considerazioni.

score 1 · Answer 4

Il termine che stai cercando è "coerenza" (o mancanza di).

Per il vero SW aziendale, occorrono diversi modelli per risolvere questo problema

Transazioni (semplici vecchie transazioni).
Utilizza gli aggiornamenti atomici o il database di sola aggiunta.
- Per gli aggiornamenti atomici, mi riferisco al di là di ciò che una transazione può fare già: puoi leggere e aggiornare (o aggiornare e leggere) i dati atomicamente all'interno della stessa operazione. Alcuni DBMS supportano già livelli di isolamento della transazione che supportano questo tipo.
- Per append-only, è un animale completamente diverso. Il tuo DB dovrebbe inserire solo operazioni come "prelevare" o "depositare" e, ogni volta che è necessario ottenere il saldo corrente, è necessario sommare tutti i record per ottenerlo. Ciò si basa anche sul presupposto che tu abbia buone transazioni.
Infine, dovresti controllare in Compensazione del modello di transazione . Questo schema è concepito proprio per gestire operazioni distribuite che non possono permettersi o non possono utilizzare transazioni distribuite in modo coerente. In generale, il modello richiede che, per ogni operazione, si aggiunga anche l'operazione di annullamento in un registro. Se l'operazione di massa non riesce, è necessario eseguire tutto il "log di annullamento" per ristabilire lo stato.
- Questo è ciò che le banche usano nel caso in cui una condizione di competizione causi uno stato di errore (un tale bilancio negativo). In effetti, i conti di risparmio hanno sempre un credito implicito (sconosciuto alla maggior parte delle persone) che viene utilizzato nel caso in cui un utente possa "battere il sistema" e stia progettando di farla franca con denaro gratuito.