eventsource / CQRS - Riproduzione di proiezioni di un aggregato in ordine

3

Ho un progetto di eventi e voglio riprodurre i seguenti due eventi, nell'ordine:

ProductCreatedEvent
PriceChangedEvent

Mi è stato detto che le proiezioni dovrebbero essere asincrone, quindi durante la riproduzione, la ProductCreatedEvent viene proiettata contemporaneamente a PriceChangedEvent . Il fatto è che poiché PriceChangedEvent viene inviato prima che il prodotto possa essere creato nel database, l'aggiornamento della query fallisce.

Come posso affrontare questo tipo di problema senza fare in modo che PriceChangedEvent continui a controllare se il prodotto è già stato creato? Ho letto dal mio eventstore e ho usato rabbitmq per inviare gli eventi ai miei ascoltatori / proiettori, a causa della natura asincrona di rabbitmq, non sono sicuro su come dovrei fare questa orchestrazione.

Questo è un problema comune?

    
posta lucaswxp 20.03.2018 - 21:28
fonte

1 risposta

4

Is this a common problem?

Sì.

I read from my eventstore and use rabbitmq to dispatch the events to my listeners/projectors

Qui c'è una trappola - se la tua proiezione richiede l'elaborazione di eventi nell'ordine corretto, allora hai bisogno di un meccanismo per assicurarti che ciò accada.

L'approccio più semplice è quello di leggere le sequenze di eventi dall'archivio eventi e quindi elaborare quelle sequenze, invece di che cercano di ricevere i messaggi consegnati da un bus e capire come ordinare loro.

In altre parole, si utilizza il bus per avvisare il proiettore del fatto che c'è più lavoro da fare (ridurre la latenza), ma lasciare che il libro di record serva le storie alle proiezioni che necessitano esso.

Vedi Talk di Greg Young su Google Polygot Data .

Should I ditch RabbitMQ?

Non necessariamente; ma vuoi stare attento a come lo usi.

Se ogni evento ha il proprio thread di gestione (il che significa che gli eventi possono essere elaborati contemporaneamente) e scriveranno alle stesse entità di database, allora hai una condizione di competizione che non sarai felice con.

Una determinata "verità" nel tuo sistema vuole davvero essere uno scrittore singolo.

Quindi il bus middleware consegna gli eventi alla "cassetta" del singolo writer e elabora i messaggi in sequenza, e tu sei pronto per andare.

Ora, se il tuo sistema è progettato in modo tale che il coniglio garantisca l'ordine di consegna , quindi sei in buona forma.

Stai anche bene usare coniglio per quei casi in cui non ti interessa l'ordine dei messaggi.

Ma se ti interessa l'ordine dei messaggi e la progettazione del sistema non consente a coniglio di garantire l'ordine di consegna, è necessario che l'ordine sia mantenuto altrove.

In genere, ciò significa che quando si salva il risultato del comando si anche si accodano eventi di dominio a una cronologia ordinata. Gli eventi sono mantenuti nella cronologia ordinata prima che vengano pubblicati in coniglio.

I lettori che hanno bisogno di eventi nell'ordine corretto usano la coda per dire loro che la cronologia ordinata è cambiata, ma quando hanno bisogno di eventi dell'ordine interrogano la cronologia ordinata invece di provare a creare una copia da gli eventi che hanno visto.

In effetti, l'arrivo dell'evento da coniglio dice allo scrittore che la storia ordinata (potrebbe essere cambiata) e che lo scrittore dovrebbe aggiornare la sua copia locale dalla sorgente e quindi prendere ogni appropriato azione.

    
risposta data 20.03.2018 - 21:53
fonte

Leggi altre domande sui tag