2012-03-14 8 views
36

Abbiamo un'applicazione che utilizzerà RabbitMQ e che ha diverse code per il passaggio di messaggi tra i livelli.Scambio di argomenti con scambio diretto in RabbitMQ

Inizialmente, stavo progettando di utilizzare più scambi diretti, uno per ogni tipo di messaggio, ma sembra che avere un singolo scambio di argomenti con le code utilizzando diversi binding di tasti di routing otterrà la stessa cosa.

Avere uno scambio singolo sembra anche essere un po 'più facile da mantenere, ma mi chiedevo se ci sono dei benefici (se ce ne sono) di farlo in un modo rispetto all'altro?

Opzione 1, l'utilizzo di più scambi diretti:

ExchangeA (type: direct) 
-QueueA 

ExchangeB (type: direct) 
-QueueB 

ExchangeC (type: direct) 
-QueueC 

Opzione 2, utilizzando singolo scambio argomento:

Exchange (type: topic) 
-QueueA (receives messages from exchange with routing key of "TypeA") 
-QueueB (receives messages from exchange with routing key of "TypeB") 
-QueueC (receives messages from exchange with routing key of "TypeC") 

risposta

29

Supponendo che entrambi i modelli vengono presi in considerazione per essere implementato utilizzando un broker in esecuzione, c'è poco differenza che posso vedere.

L'opzione 2 sembra più comune nel mondo reale per risolvere questo tipo di problema di routing (almeno nella mia esperienza aneddotica) ed è esattamente la sfida che gli Scambi di argomenti esistono per risolvere.

L'unica differenza che è possibile riscontrare riguarda la velocità di routing. Non so con certezza se il routing di Exchange (basato sempre su una corrispondenza esatta della stringa) sia più veloce in RabbitMQ rispetto alla tecnica della chiave di routing utilizzata in Topic Exchanges (che può includere caratteri jolly come # e *). La mia impressione sarebbe che la discriminazione di Exchange sarebbe più veloce, ma potresti provare a scoprirlo, o provare a contattare il team di RabbitMQ per chiedere loro.

Infine, se si va con l'opzione 1 finiscono con un sacco di code, allora si avrà una proliferazione proporzionale di scambi. Sembra un mal di testa per la manutenzione. Se avrai solo una manciata di code, non sarà un problema.

+2

concordo. Più code con chiavi di routing appropriate è molto più facile da gestire. L'unico vantaggio dell'opzione 1 che mi viene in mente è che gli scambi multipli potrebbero essere ospitati su hardware separato, ottenendo in tal modo un ridimensionamento verticale. Tuttavia, se il tuo hardware non funziona, potresti non aver bisogno di seguire questa strada. –

+0

Penso che il vantaggio dell'uso di Topic sia che se in futuro dovessi inviare lo stesso messaggio a più code nel tuo scambio, la tua opzione 2 sarebbe più desiderabile. – gigi2

3

Per un singolo nodo piccolo con poco carico, c'è poca differenza. La maggior parte delle persone sceglie l'opzione numero due per i suddetti motivi.

Quando si progetta il sistema, è necessario chiedersi come potrebbe espandersi in futuro.

Come va in scala?
Ho bisogno di ridimensionarlo? Desidero aggiungere un cluster di disponibilità elevato in futuro? Il mio routing cambierà ...

L'opzione 2 offre molta più flessibilità nella maggior parte dei casi.

Permette di fare cose come collegare un nuovo utente allo scambio con la propria coda e catturare facilmente qualsiasi sottoinsieme o tutto il flusso dei messaggi. (queste code potrebbero essere su altri nodi in un cluster o su mirroring su n nodi che forniscono il failover) Un tipico caso d'uso sarebbe registrare tutti i messaggi usando una quarta coda.

Se il collo di bottiglia si trova sul lato di elaborazione, è inoltre possibile suddividere ulteriormente gli argomenti dei messaggi ed eseguire una certa quantità di priorità senza dover cambiare i propri editori. Esempio: ToppicA.urgent, elaborato dal consumatore dedicato, TopicA.log eventualmente elaborato.

La risposta breve è andare con l'opzione 2 a meno che non si abbiano requisiti di prestazione molto specifici, se per esempio è necessario elaborare una velocità sostenuta di più di 50k msg/s, si potrebbe voler pensare all'opzione 1 su nodi dedicati, ma per i flussi normali l'opzione 2 sarà più semplice da ridimensionare e mantenere.

4

Infatti, l'approccio 2 è migliore in quanto consente di utilizzare una singola coda per più chiavi di routing.

Scambio Topic

QueueA-- binding key = India.Karnataka.* 

È possibile indirizzare un messaggio a scambio argomento con la chiave routing come India.Karnataka.bangalore, India.Karnataka.Mysore.

Tutti i messaggi precedenti passano alla codaA.

diretto Cambio

ma non ho capito il motivo per cui stai creando più scambi diretti di approccio 1. Si può avere singolo scambio diretto ed avere più code con ogni coda vincolante con una chiave univoca.

QueueA-- binding key = Key1 
QueueB-- binding Key = Key2 
QueueC-- binding Key = Key3 

Tutti i messaggi key1 va a QueueA.Key2 va a QueueB ... È ancora possibile mantenere singolo scambio diretto.