RabbitMQ Condizioni di gara / messaggi dipendenti

Question

RabbitMQ Condizioni di gara / messaggi dipendenti

#1 da (0 voti)

1

Attualmente sto lavorando a un progetto, dove dovremo mantenere un sistema locale in "sincronizzazione" con un'applicazione remota.

Ad esempio, se un nuovo cliente viene creato nell'applicazione locale, questo cliente deve anche essere creato nell'app remota - tramite un'app di riposo - e l'ID utente "remoto" deve essere memorizzato nell'app locale per un ulteriore utilizzo.

Per avviare la sincronizzazione iniziale, abbiamo iniziato a chiamare l'app remota direttamente quando un utente è stato creato e ha atteso la risposta. Questo approccio ha molti aspetti negativi: uno di questi è che l'utente deve attendere che la chiamata al sistema remoto termini per continuare il suo flusso di lavoro.

Quindi stiamo cercando alternative all'approccio iniziale e broker di messaggi (ad esempio RabbitMQ) potrebbero essere la strada da percorrere.

Ho già effettuato alcune ricerche su RabbitMQ e ho anche saltato il libro di Enterprise Integration Pattern ma non riesco a delineare il seguente esempio flusso di lavoro:

1.) Un account viene creato nell'applicazione locale (deve anche essere creato nell'applicazione remota e l'ID dell'account remoto deve anche essere memorizzato nell'app locale)

2.) Immediatamente dopo la creazione dell'account, viene creato un utente per questo account (deve anche essere creato nell'applicazione remota e l'ID utente remoto deve anche essere memorizzato nell'app locale)

Quando esegui questi due passaggi asincrona, non posso garantire che l'ID azienda dal sistema remoto sia già stata sincronizzata con l'app locale. Quindi forse non sarò in grado di collegare l'utente all'azienda nell'app remota ...

Esiste qualche tipo di schema o qualche approccio di buona pratica a questo problema?

Grazie!

patterns-and-practices message-queue

posta sl0815 26.06.2017 - 20:54

fonte

1 risposta

Leggi altre domande sui tag patterns-and-practices message-queue

Struttura di codice adeguata per un servlet che utilizza la cache e asincrona Angular2: architettura di servizio + gestione degli errori

score 0 · Accepted Answer

Appena iniziando a utilizzare RabbitMQ, la collaborazione tra i due sistemi non si sentirà improvvisamente più fluida e più user-friendly. Infatti, collegando RabbitMQ al tuo sistema è probabile che porti ancora più problemi.

E anche allora, il tuo problema non è che l'API sia sincrona, il tuo problema è l'API di chiamata client in modo sincrono e in attesa di una risposta. Questo è il posto in cui dovresti iniziare a cercare prima.

La tua API può rimanere sincrona così com'è, cioè elaborare in modo sincrono la richiesta per creare un nuovo User / Account . Sul client, idealmente staresti guardando qualcosa del genere:

L'utente fa clic su un pulsante Save User .
Un'entità User viene salvata su un database locale - molto velocemente.
Un evento NewUserHasBeenSaved viene inviato a un bus dei messaggi.
^async Un gestore di processi ascolta gli eventi che si verificano nel sistema, prende l'evento NewUserHasBeenSaved dalla coda dei messaggi ed emette un nuovo comando PersistNewUserToRemoteApi .
^async Un gestore di comandi responsabile della gestione del comando PersistNewUserToRemoteApi estrae l'entità User dal database locale e lo spinge all'API - questa operazione potrebbe richiedere tra qualche ms fino a pochi minuti, a seconda della situazione della rete e / o della dimensione del carico utile.
^async Se la chiamata API remota ha esito positivo, l'entità locale User viene aggiornata con l'id remoto. In caso di errore, il PersistNewUserToRemoteApi è pianificato per riprovare: la strategia dipende da te, dipende interamente dal tuo caso specifico.
L'utente inserisce le informazioni dell'account e fa clic su un pulsante Save Account .
Un'entità Account viene salvata su un database locale che viene mappato su un'entità User locale (ad es. tramite una chiave esterna).
Un evento NewAccountHasBeenSaved viene inviato a un bus dei messaggi.
La finestra di dialogo per la creazione dell'account è chiusa e l'utente può procedere con operazioni aggiuntive.
^async Proprio come in 4, process manager ascolta gli eventi, prende l'evento NewAccountHasBeenSaved dalla coda dei messaggi ed emette un nuovo comando PersistNewAccountToRemoteApi .
^async Un gestore di comandi per PersistNewAccountToRemoteApi estrae il Account locale dal database locale ed è associato all'entità User . Quindi controlla se il User contiene già un ID remoto, vale a dire se è già stato mantenuto. Se l'entità User contiene remote, il gestore comandi invia una chiamata remota all'API per l'account, altrimenti pianifica PersistNewAccountToRemoteApi per riprovare. Ancora una volta, la strategia dei tentativi dipende dalle tue esigenze.

Come puoi vedere, alcune delle operazioni sono contrassegnate come ^async, ovvero l'ordine di esecuzione potrebbe non essere necessariamente quello che ho specificato, ma le azioni potrebbero si verificano nell'ordine di: 1, 2, 3, 7, 8, 4, 5, 6, 9, 10, 11, 12.

Inoltre, non è necessario inviare comandi per inviare le entità all'API remota, ma farlo direttamente nel gestore processi. Ancora una volta, dipende dalle tue esigenze.

Ciò che potrebbe interessarti è il modello di attore , che dovrebbe essere possibile implementare anche dal lato del client.