CQRS, quali ragioni causano il ritardo di aggiornamento del modello di lettura? Come impedire all'utente di prendere i dati di incoerenza?

Question

CQRS, quali ragioni causano il ritardo di aggiornamento del modello di lettura? Come impedire all'utente di prendere i dati di incoerenza?

#1 da (3 voti)

0

Sto considerando CQRS per la creazione di un server di gioco in tempo reale (non il gameplay ma l'economia).

Per alcuni motivi. Ridimensionamento, Registrazione eventi, Cambio modello.

Tuttavia nel gioco in tempo reale durante l'aggiornamento del giocatore, ad esempio il personaggio. Ho deriso il client senza bisogno di alcun feedback del server.

Ma se chiude il gioco immediatamente dopo l'aggiornamento e riapre rapidamente il gioco, DEVE vedere il suo personaggio aggiornato.

Domanda:

Mi chiedo quanto tempo il modello in lettura è in ritardo? Quali ragioni ne causano il ritardo? Se ho solo pochi dati del processo di pre-elaborazione per il modello di lettura. Non ho esperienza in scala.
CQRS è ancora ok per questo caso d'uso?
Se va ancora bene, quali opzioni dovrei scegliere qui?

3.1. Blocca l'utente dalla lettura fino al completamento dell'aggiornamento del modello di lettura.

3.2. Blocca l'utente dalla lettura all'inizio che il comando ha raggiunto il server fino a quando il modello letto non ha completato l'aggiornamento.

3.3. Garanzia leggere il tempo di aggiornamento del modello in modo che sia inferiore al tempo di apertura dell'applicazione. E ignora questi problemi.

cqrs eventual-consistency read-model

posta b.ben 23.06.2018 - 21:49

fonte

1 risposta

Leggi altre domande sui tag cqrs eventual-consistency read-model

Progettazione del database: dove archiviare un flag "corrente" o "selezionato" in una gerarchia padre-figlio [duplicato] Il mio DataAccessLayer è stato implementato correttamente?

score 3 · Accepted Answer

I'm wonder how much read model delayed? What reason(s) cause it for delay? If I have only little preprocessing process data for read model. I have no experience at scale.

"Dipende". La causa del ritardo è la propagazione delle informazioni dalla struttura dati che supporta la scrittura nella struttura dati che fornisce la lettura. Quindi una parte della differenza è nella distanza tra le due strutture dati, alcune in quanto è necessario lavorare per piegare le nuove informazioni nel modello letto e quanto tempo c'è tra la scrittura e l'inizio del processo da copiare quella informazione alla nuova struttura dati.

Un altro modo di pensare a questo è che il "clock" del modello letto è lento rispetto al modello di scrittura; quindi il modello di lettura sta descrivendo come appaiono le cose "adesso", dove ora c'è un po 'di tempo nel passato.

Quindi una cosa che puoi fare in alcuni casi è rendere esplicito quell'orologio; "mostrami come è stato il modello al momento = t"; oppure "mostrami un modello recente dopo il tempo = t" è una query che il client può inviare a una cache di lettura; dove il gestore di query può semplicemente cercare di vedere se la sua copia è abbastanza recente da soddisfare la query e se non estrarre una copia più recente dei dati.

Diciamo "modello di lettura" e "modello di scrittura", ma fondamentalmente non c'è niente di sbagliato nella lettura dei dati dal modello di scrittura - identificare il modello write più recente disponibile al momento della query, e quindi (in modo sincrono) costruisce una rappresentazione della risposta alla query, da restituire. Questo ti dà una versione più "recente" del modello di lettura, al costo di un po 'di tempo extra per elaborare la query.

Inoltre, non è necessario utilizzare la stessa strategia di caching per tutte le query; ad esempio, potresti utilizzare un modello di lettura memorizzato nella cache quando mostri a un utente il carattere di qualcun altro, ma usando un nuovo modello di lettura quando mostri a un utente il proprio carattere.

Parte del punto di CQRS è che puoi prendere queste decisioni caso per caso.