Utilizzo dei sistemi di code dei messaggi: forzatura dell'elaborazione sincrona

Question

Utilizzo dei sistemi di code dei messaggi: forzatura dell'elaborazione sincrona

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

1

Ho un processo php producer-a che colloca un lavoro su RabbitMQ a - rimandando l'elaborazione a un servizio di terze parti. Il servizio di terze parti completa l'elaborazione di a e inserisce una risposta sulla coda b . Ho un listener consumer-b che preleva i lavori in coda b per continuare l'elaborazione.

Devo assicurarmi che producer-a abbia completato il processo completamente prima che il listener consumer-b prenda il lavoro per continuare l'elaborazione.

Il problema che sto affrontando è che usando RMQ - sto eseguendo operazioni in modo asincrono - tuttavia ho bisogno di serializzare questo processo usando ancora RMQ.

Nel caso in cui quanto sopra non ha senso:

Esempio di timeline se serializzato:

Process A ------> Process B ------> Process C

Esempio di timeline con coda messaggi

Internal Process    Process A----------------------------------|

Deferred Process           Process B -----|

Internal Process                          |Process C---|

Il processo A deve essere completato completamente prima del processo C. Il problema è che il processo B viene posticipato a un servizio di terze parti tramite una coda di messaggi e devo garantire che il processo A che ha inviato il processo al processo B sia stato completato prima del processo C riprende il lavoro dal processo A. Come si può vedere dalla timeline precedente, il processo C è stato completato prima del completamento del processo A.

Aggiornamento:

Non pensavo di affermare l'ovvio, ma sembra che stia ricevendo suggerimenti / soluzioni ovvi. producer-a deve semplicemente inviare un messaggio TCP a Loggly (a volte richiede più di 2 secondi) e deve anche aggiornare il database per avvisare che il processo è stato rinviato. A volte, il messaggio ritorna e viene raccolto da Process C prima che il processo A sia completato.

asynchronous-programming message-queue serialization

posta Gravy 16.02.2015 - 19:23

fonte

3 risposte

Leggi altre domande sui tag asynchronous-programming message-queue serialization

Che cosa significa? L'operazione SOAP rappresenta le risorse logiche e REST che rappresentano i dati Conflitti di progettazione e dati basati sul dominio

score 1 · Answer 1

Quello che hai è un problema di scatter-gather.

Il Processo A deve disseminare i suoi (possibilmente intermedi) risultati tra il Processo B e la Legione Straniera Francese. Il processo B deve raccogliere i prodotti di lavoro dal Processo A e dalla Legione straniera francese e non può procedere finché non li ha entrambi.

Presumibilmente, RabbitMQ ha la capacità di attendere contemporaneamente più code. Stabilire una terza coda, per le notifiche di completamento dal processo A al processo B. Il processo B attende quindi entrambe le code e, utilizzando i cookie magici incorporati nei messaggi, corrisponde ai dispacci della legione straniera francese ai completamenti del processo A. Quando ha entrambi i pezzi del biglietto d'oro, il processo B continua. Se ha solo un pezzo del cookie, continua ad attendere su entrambe le code.

score 1 · Answer 2

Lascia che Producer-A inserisca qualche stato nel DB o in qualche altro archivio persistente e Consumer-B possa guardare in quello stato e determinare se ritirare il lavoro da Producer-A o meno. Un'altra opzione è che, poiché si sta utilizzando una coda messaggi, lasciare che Producer-A invii un altro messaggio al suo completamento nella coda C. Consumatore-B non dovrebbe raccogliere alcun messaggio dalla coda B finché non riceve il messaggio dalla coda C.

score 0 · Answer 3

Se hai bisogno che producer a sia terminato prima che consumer b inizi l'elaborazione, allora:

producer a dovrebbe aggiungere il messaggio a accodare un come ultima cosa che fa
produttore a dovrebbe aggiungere un messaggio a un'altra coda come ultima cosa che fa e consumatore b dovrebbe attendere il messaggio di flag prima che prelevi il messaggio principale da elaborare o altrimenti raccogliere il messaggio principale da elaborare e quindi attendere il messaggio di conferma sull'altra coda.