O RabbitMQ é um broker de mensagens que implementa o protocolo AMQP (Advanced Message Queuing Protocol). Diferente de protocolos simples de rede, o AMQP define uma estrutura robusta para o roteamento e a persistência de dados em sistemas distribuídos.

Fluxo de Ciclo de Vida da Mensagem

1. Envio pelo Produtor (Publishing)

O processo de envio segue uma sequência lógica para garantir que a mensagem chegue ao destino correto:

• O produtor estabelece uma conexão TCP com o Broker.
• Uma conexão virtual, chamada Channel (Canal), é aberta sobre a conexão física.
• O produtor define (ou assume a existência de) uma Exchange (Troca).
• A mensagem é enviada para a Exchange acompanhada de uma Routing Key.
• A Exchange, baseada em suas regras de roteamento, encaminha a mensagem para uma ou mais Queues (Filas).
• O canal e a conexão são encerrados ou retornados ao pool.

2. Recebimento pelo Consumidor (Consuming)

O consumo pode ocorrer de duas formas principais:

• Push (BasicConsume): O Broker envia a mensagem para o consumidor assim que ela chega na fila. É o modelo padrão para alta performence e baixa latência.
• Pull (BasicGet): O consumidor solicita ativamente a mensagem da fila. Útil quando o consumidor precisa controlar rigidamente o fluxo de trabalho.

Componentes Fundamentais

• Broker: O servidor RabbitMQ propriamente dito.
• Connection: Conexão TCP estável entre o cliente e o servidor.
• Channel: Canais lógicos dentro de uma Connection. Criar conexões TCP é caro, por isso múltiplos canais compartilham a mesma conexão física para otimizar recursos.
• Virtual Host (vhost): Uma segregação lógica dentro do RabbitMQ. Cada vhost possui suas próprias filas, trocas e permisões, funcionando como instâncias independentes.
• Exchange: O roteador de mensagens. Ela decide, com base na chave de roteamento, para qual fila a mensagem deve ir.
• Binding: A regra que liga uma Exchange a uma Queue.

Modelos de Roteamento (Exchange Types)

Direct Exchange

A mensagem é encaminhada para a fila cuja Binding Key seja exatamente igual à Routing Key da mensagem. Ideal para tarefas específicas e roteamento unicast.

Fanout Exchange

Ignora as chaves de roteamento e envia a mensagem para todas as filas que estão vinculadas a ela. É o modelo clássico de broadcast ou publicação/assinatura.

Topic Exchange

Permite roteamento flexível baseado em padrões. Utiliza curingas:

• * (asterisco): Substitui exatamente uma palavra.
• # (cerquilha): Substiuti zero ou mais palavras.

Headers Exchange

Utiliza os atributos do cabeçalho da mensagem em vez da Routing Key. O argumento x-match define se a mensagem deve atender a todos os critérios (all) ou a pelo menos um (any).

Garantia de Entrega e Confiabilidade

Confirmações do Produtor (Publisher Confirms)

Para evitar perda de dados antes de chegar ao broker, o RabbitMQ oferece o mecanismo de confirmação. Quando ativado, o broker envia um ACK (Acknowledge) ao produtor confirmando que a mensagem foi processada pela Exchange.

Persistência de Dados

Para que as mensagens sobrevivam a reinicializações do servidor, três condições devem ser atendidas:

1. A Exchange deve ser declarada como durable.
2. A Queue deve ser declarada como durable.
3. A mensagem deve ser marcada como persistent (delivery mode 2).

Mecanismo de Confirmação do Consumidor

O consumidor informa ao broker que processou a mensagem com sucesso via basicAck. Se o consumidor falhar ou fechar a conexão antes de enviar o ACK, o RabbitMQ reencaminha a mensagem para outro consumidor.

// Exemplo de confirmação manual em Java/Spring
channel.basicAck(deliveryTag, false);
   

Tratamento de Falhas e Filas de Letra Morta (DLQ)

Quando uma mensagem falha repetidamente ou expira, ela pode ser enviada para uma Dead Letter Exchange. Isso permite análise posterior sem travar o processamento da fila principal.

@Bean
public Queue filaProcessamentoPrincipal() {
   Map<String, Object> configuracoes = new HashMap<>();
   // Define a exchange para onde mensagens mortas serão enviadas
   configuracoes.put("x-dead-letter-exchange", "exchange.dlx");
   configuracoes.put("x-dead-letter-routing-key", "rota.falha");
   // Define tempo de vida da mensagem (TTL) de 30 segundos
   configuracoes.put("x-message-ttl", 30000);
   
   return new Queue("fila.principal", true, false, false, configuracoes);
}
   

Gestão de Sobrecarga e Mensagens Acumuladas

Em cenários de alto tráfego, o acúmulo de mensagens pode degradar o sistema. Estratégias comuns incluem:

• Escalabilidade Horizontal: Adicionar mais instâncias de consumidores.
• QoS (Prefetch Count): Limitar quantas mensagens um consumidor recebe por vez, evitando que um único worker fique sobrecarregado enquanto outros estão ociosos.
• Monitoramento: Utilizar ferramentas como o RabbitMQ Management Plugin para identificar gargalos em tempo real.

Evitando o Processamento Duplicado (Idempotência)

Como o RabbitMQ garante a entrega "ao menos uma vez", duplicatas podem ocorrer. Para resolver isso:

• IDs Únicos: O produtor gera um UUID para cada mensagem. O consumidor verifica em um cache (como Redis) se aquele ID já foi processado.
• Operações Idempotentes: Projetar a lógica de negócio para que repetir a mesma operação não altere o estado final (ex: atualizar um status em vez de incrementar um valor).

Transações vs. Confirmações

Embora o RabbitMQ suporte transações (txSelect, txCommit), elas reduzem drasticamente o throughput (vazão). O uso de Publisher Confirms é preferível na maioria dos cenários de alta performance.

# Configuração de Retry no Spring Boot (application.yml)
spring:
 rabbitmq:
   listener:
     simple:
       retry:
         enabled: true
         max-attempts: 5
         initial-interval: 2000ms