RabbitMQ é um message broker implementado em Erlang que utiliza o protocolo AMQP para essa troca de mensagens.
Diferente dos protocolos de mensageira tradicionais, o AMQP utiliza o conceito de exchanges (no roteamento das mensagens) e acknowledges (para confirmação de recebimento).
Basicamente, os publishers enviam mensagens ao broker para uma exchange, e o broker realiza o roteamento da mensagem para filas existentes com base do tipo de exchange, estas filas serão consumidas pelos consumers que subscreveram nelas.
Exchanges funcionam de forma semelhante a um serviço postal, recebem as mensagens e as redirecionam (routing) aos carteiros (queues).
As regras de roteamento são chamadas de routing keys.
💡 Uma diferença na analogia do serviço postal é que as mensagens são efetivamente copiadas para as filas, e uma mesma mensagem pode ser roteada para mais de 1 uma fila.
Um producer de mensagens nunca as envia diretamente para filas, ele sempre envia para exchanges. O trabalho da exchange se resume a receber mensagens dos producers e enviar estas mensagens para queues.
A exchange sabe exatamente o que deve fazer com as mensagens que recebe, se vai enviar para uma ou mais filas, se a mensagem deve ser descartada, etc. Tudo depende do tipo de exchange que recebeu a mensagem.
💡 In AMQP 0-9-1, messages are load balanced between consumers and not between queues.
| Exchange type | Default pre-declared names |
|---|---|
| Direct exchange | (Empty string) and amq.direct |
| Fanout exchange | amq.fanout |
| Topic exchange | amq.topic |
| Headers exchange | amq.match (and amq.headers in RabbitMQ) |
Entrega mensagens de acordo com a routing key. É ideal para comunicações unicast (também pode realizar envios multicast).
Exchanges do tipo fanout roteiam as mensagem a todas as filas que estejam ligadas (bound) a elas. Elas ignoras as routing keys. É ideal para envios broadcast.
Quando uma mensagem é enviada a uma exchange fanout, uma cópia da mensagem é enviada a todos as queues.
Envia mensagens para 1 ou N queues com base no matching entre a routing key utilizada e o padrão definido na ligação da queue com a topic exchange.
Esse tipo de exchange é utilizado na implementação de padrões publish/subscribe e suas variações.
Sempre que houve um problema que envolva múltiplos consumers/aplicações que seletivamente devem decidir quais mensagens irão receber, deve ser considerado a utilização da exchange topic.
Uma característica imporante da topic exchange está na binding keys, que podem ser compostas por palavaras separadas por pontos '.' e podem utilizar de wildcards.
* (star) - substitui uma palavra (até o próximo ponto '.')
# (hash) - substitui 0 ou mais palavras (independente da divisão utilizando ponto '.')
É a exchange utilizada para realizar o roteamento utilizando múltiplos atributos que são definidos através de headers ao invés de routing keys.
Essa exchange ignora a routing key utilizando atributos do header como chaves para realizar o roteamento.
Uma característica interessante é a utilização do argumento "x-match" no binding, quando esse argumento é utilizado com o valor "any", caso pelo menos 1 atributo do header der match, já é suficiente para rotear a mensagem.
Utilizado quando é necessário ter ordem no processamento das mensagens. Utilizando um identificador único, é gerado o hash desse valor e as mensagens que compartilham esse hash são enviadas para a mesma fila, garantindo ordem no processamento. Existe uma condição para que essa abordagem funcione que é a de que cada Consumer deve escutar apenas uma fila.
Existe a possibilidade de quebrar o correto roteamento baseado no hash quando uma nova fila é adicionada a exchange.
É necessário instalar o plugin "rabbitmq_consistent_hash_exchange"
rabbitmq-plugins enable rabbitmq_consistent_hash_exchange
Na consistet hash exchange, a routing key é definida utilizando números que na verdade representam o 'balanceamento' das queues (peso em um balancer).
No AMQP queues são buffers de mensagens.
A ligação entre uma exchange e uma queue é chamada de binding.
Queues podem ter a propriedade x-single-active-consumer:consumer=true que fará com que apenas um canal receba as mensagens da fila (evita concorrencia de consumidores). Inclusive, caso existam 2 consumidores para uma fila single, apenas 1 receberá as mensagens e caso esse falhe (caia) o outro começa a recebê-las.
- Nome
- Durável (se a queue deve sobreviver após um restart do servidor)
- Exclusiva (se a fila será exclusiva de determinada conexão, e quando esta for fechada a fila sera deletada)
- Auto-delete (se a fila é removida quando o último consumer realizar o unsubscribe)
- Argumentos (tempo de vida, tamanho da vila, etc)
Bindings podem ser descritos como regras que as exchanges utilizaram para rotear mensagens para queues.
To draw an analogy:
Queue is like your destination in New York city
Exchange is like JFK airport
Bindings are routes from JFK to your destination. There can be zero or many ways to reach it