RabbitMQ

Definição

RabbitMQ é um broker de mensagens: recebe publicações e as encaminha para processamento por consumidores. No modelo AMQP 0-9-1, exchanges fazem o roteamento e filas mantêm as mensagens aguardando entrega ou confirmação.

Uma fila pode ter vários consumidores dividindo trabalho. Se dois serviços precisam receber cada evento de forma independente, normalmente cada serviço precisa de sua própria fila. Colocar ambos na mesma fila distribui as mensagens entre eles. Referência: filas.

Exemplo de fluxo

flowchart LR
  API[API de pedidos] --> E[Exchange pedidos]
  E --> F1[Fila faturamento]
  E --> F2[Fila notificacoes]
  F1 --> C1[Consumidor faturamento]
  F2 --> C2[Consumidor notificacoes]

Um evento pedido.criado pode ser roteado para ambas as filas. A indisponibilidade do serviço de notificações não impede o outro de continuar consumindo, enquanto o broker tiver capacidade para manter o acúmulo.

Durabilidade e replicação

Uma fila durável conserva sua definição após reinicialização. Persistência das mensagens e confirmação da publicação são decisões adicionais. Declarar apenas durable não comprova que toda publicação chegou ao armazenamento com segurança. Referência: confiabilidade.

Quorum queues usam replicação com Raft. A maioria dos membros precisa estar disponível para o grupo continuar operando. Isso envolve mais armazenamento e tráfego entre réplicas do que manter uma única cópia. Referência: quorum queues.

Limites

Fila crescendo continuamente indica que entradas e processamento estão desequilibrados. Mais consumidores ajudam apenas se o gargalo puder ser paralelizado. Concorrência e reentregas também afetam a ordem observada de processamento.

RabbitMQ possui ainda streams, com retenção e leitura de log. Portanto, comparar RabbitMQ e Kafka exige dizer qual mecanismo do RabbitMQ está sendo considerado.

Aprofundamento aplicado

Ready e unacknowledged contam histórias diferentes

Mensagens prontas aguardam entrega. Mensagens não confirmadas já foram entregues e aguardam ack. Poucas mensagens prontas com muitas não confirmadas podem indicar consumidores saturados ou prefetch alto, sem que a fila esteja efetivamente drenada.

Cenário: cada tarefa dura 2 s e um consumidor busca muitas antecipadamente. Ele pode concentrar trabalho enquanto outros ficam ociosos. Ajustar prefetch exige considerar paralelismo real, duração e uso de memória; não apenas taxa de entrega.

Backpressure atravessa a aplicação

Se a publicação fica mais lenta por pressão do broker, a API precisa decidir se espera, rejeita ou registra trabalho em armazenamento durável para envio posterior. Acumular promessas ou mensagens ilimitadamente na RAM apenas transfere o problema de lugar.

Exercício: limite a concorrência dos consumidores e acompanhe prontas, não confirmadas e tarefas concluídas. Resultado esperado: diferencie entregar rapidamente de processar rapidamente; aumentar o prefetch não aumenta a capacidade do banco de destino.

Referência: filas e estado das mensagens.

Relacionado: 2. Exchanges, Bindings e Roteamento no RabbitMQ · 3. Confirmações, Retry e DLQ no RabbitMQ · 5. Kafka vs Fila Tradicional.

---

Parte de RabbitMQ