Rabbitmq- Progettazione di un servizio di ripetizione di messaggi

Question

Sto provando a progettare un meccanismo di riproduzione che consentirà agli utenti di riprodurre i messaggi dalle code. Il miglior design Sono venuto per uno scambio che contiene più code e più consumatori è:

1. creare un servizio registratore che verrà:

   • Creare una coda e legare tutte le chiavi di routing ad esso .
   • Consuma tutti i messaggi dallo scambio.
   • Salva tutti i messaggi nel DB.

2. Richiesta di sottoscrizione per riproduzione.

   • Ogni sottoscrittore crea un nuovo scambio, accoda e si lega ad esso con gli stessi collegamenti della coda normale.
   • L'utente invia una richiesta di riposo a un server Web per avviare la riproduzione con un filtro (startdate, ecc.). La richiesta contiene il suo nome di scambio di ripetizione.
   • Il server Web estrae i dati dal DB e li pubblica nello specifico scambio
   • i perfezionamenti possono essere aggiunti come associare RequestId e riecheggiarlo.

Domande:
1. Ha senso?
2. Sto inventando la ruota? Esiste una soluzione inerente al coniglio? collegare?
3. La creazione di più scambi è considerata una buona pratica?
In questa soluzione viene creato uno scambio per ogni coda per pubblicare lo stesso messaggio.

Un'altra soluzione:
1. Creare una coda aggiuntiva "ReplayQueue" per ogni coda. imposta un TTL (diciamo un mese).
2. Ogni volta che un utente richiede un replay, gli consente di riprodurre dal proprio ReplayQueue senza acking.

Questa soluzione è un po 'problematica perché.

• Per poter riprodurre l'ultimo giorno, i consumatori dovranno recuperare tutti i 29 giorni precedenti e filtrarli.
• Questa soluzione è scalabile: le code diventeranno più grandi (a differenza dell'archiviazione db che può scalare).

Answer 1

1. Ha senso?

Sì

2. Perchè sono inventare la ruota? Esiste una soluzione inerente al coniglio? collegare?

Non reinventare la ruota. C'è AFAIK senza soluzione di coniglio e nessuna soluzione pronta all'uso.

La tua prima soluzione è a mio parere buona. Il Another solution è molto problematico perché un coniglio sano è vuoto e il coniglio non è un archivio dati.

Si avrà una coda (STORE) in cui tutti i messaggi pubblicati devono essere indirizzati. Invece di legare STORE con tutte le chiavi di associazione, potresti prendere in considerazione l'utilizzo di uno scambio di argomenti. Al prezzo che la chiave di associazione non deve contenere . # * e un leggero sovraccarico quando il messaggio viene instradato. La coda STORE si collegherà con la chiave di associazione #.

Si potrebbe dare un'occhiata a firehose.

Perché una richiesta web? Non puoi utilizzare Coniglio con un RPC call:

• abbonato invia una richiesta di AMQP per avviare la riproduzione di un filtro (startdate, ecc).
• La richiesta contiene il nome della coda reply-to. La coda può essere esclusiva per il cliente e la richiesta.
• server RPC estrae i dati dal DB e pubblica alla coda di risposta

Si potrebbe avere uno sguardo troppo al modello direct-reply-to.

La creazione di più scambi è considerata una buona pratica?

Sì, non appena ne avete bisogno. Per il tuo caso specifico, a mio parere non è necessario uno scambio per abbonato. La richiesta contiene già il nome della coda. Potresti semplicemente pubblicare in questa coda utilizzando lo scambio predefinito amq.direct con la chiave di routing uguale al nome della coda. Se vuoi uno scambio creerei uno scambio unico (es. "Replay"). Ogni abbonato lega le loro code di riproduzione a questo scambio. Lo scambio "replay" può essere una convenzione o inviato con la richiesta.

Answer 2

La prima soluzione è fattibile. Dato che coniglio MQ viene fornito con uno tracing plugin, la memorizzazione del messaggio in DB diventa ancora più facile in quanto si riduce semplicemente a consumare da una coda legata allo scambio amq.rabbitmq.trace.

Questo scambio è specifico per un vhost e ogni vhost ha il proprio scambio amq.rabbitmq.trace. Inoltre, quando si crea una nuova traccia, è possibile limitare la coda/lo scambio per abilitare la traccia, offrendo quindi la flessibilità di disabilitare la traccia laddove non è richiesta.

consultare i seguenti link per configurare l'analisi:
https://www.rabbitmq.com/firehose.html
https://www.rabbitmq.com/blog/2011/09/09/rabbitmq-tracing-a-ui-for-the-firehose/