Quais são os padrões comuns de mensagens RabbitMQ e quando usá-los?

Os padrões de mensagens RabbitMQ decidem se um worker lida com um trabalho, se cada assinante recebe um evento ou se um serviço aguarda uma resposta. Se você escolher o padrão errado, seu sistema pode duplicar trabalho, perder eventos úteis ou bloquear em chamadas que deveriam ter permanecido assíncronas.

RabbitMQ oferece exchanges, filas, bindings, confirmações e propriedades de mensagem. O trabalho de design útil é escolher como essas peças se encaixam na sua aplicação. Os padrões comuns são Filas de Trabalho, Publicar/Assinar, roteamento Direto ou Tópico e Solicitar/Responder.

---

Filas de Trabalho: Distribuir Tarefas Entre Workers

O padrão de Fila de Trabalho, muitas vezes referido como Fila de Tarefas, é o padrão de mensagens mais simples e comum usado para distribuir tarefas demoradas entre múltiplos processos workers (consumidores).

Como funciona

1. Um Produtor envia tarefas (mensagens) para uma única Fila.
2. Múltiplos Consumidores (Workers) escutam a mesma Fila.
3. RabbitMQ entrega cada mensagem para um consumidor, então os workers compartilham o backlog.

RabbitMQ despacha mensagens round-robin entre consumidores ativos por padrão. Essa distribuição nem sempre é justa se um worker pega tarefas lentas enquanto outro pega tarefas rápidas, então você geralmente combina esse padrão com confirmações e um limite de prefetch.

Use confirmações

Com confirmações manuais, um worker informa ao RabbitMQ quando uma tarefa é concluída. Se o worker morrer antes de enviar basic_ack, o RabbitMQ pode recolocar na fila e reentregar essa mensagem para outro consumidor. Isso é o que torna uma fila de trabalho útil para geração de relatórios, processamento de imagens, trabalhos de faturamento ou qualquer tarefa que você não queira descartar silenciosamente.

Defina um limite de prefetch

basic.qos controla quantas mensagens não confirmadas um consumidor pode manter de uma vez. Um prefetch_count de 1 é um ponto de partida seguro para tarefas lentas e desiguais, porque o RabbitMQ não enviará um segundo trabalho para esse consumidor até que ele confirme o primeiro. Para tarefas mais rápidas, você pode aumentar o valor após medir a taxa de transferência e o uso de memória.

Exemplo de Implementação (Conceitual)

# Configuração do consumidor para distribuição justa
channel.basic_qos(prefetch_count=1)
channel.basic_consume(queue='task_queue', on_message_callback=worker_function)

# A lógica do worker deve enviar confirmação após processamento bem-sucedido
worker_function(ch, method, properties, body):
    # Processar tarefa...
    ch.basic_ack(delivery_tag=method.delivery_tag)

Publicar/Assinar: Transmitir Eventos

O padrão Pub/Sub é projetado para transmitir mensagens para múltiplos consumidores interessados simultaneamente. Ao contrário das Filas de Trabalho, onde cada mensagem é consumida por apenas um worker, Pub/Sub garante que cada assinante conectado receba uma cópia da mensagem.

Use uma exchange fanout

Um produtor publica em uma exchange fanout. A exchange ignora chaves de roteamento e copia a mensagem para cada fila vinculada a ela. Cada assinante normalmente tem sua própria fila, então um serviço de log, um serviço de métricas e um serviço de auditoria podem todos receber o mesmo evento sem competir por ele.

Casos de Uso

• Notificações em tempo real: Transmitir um evento de modo de manutenção para cada instância do aplicativo.
• Distribuição de logs: Enviar o mesmo evento de log para um serviço de arquivamento e um serviço de alerta.
• Invalidação de cache: Dizer a todas as instâncias do serviço para limpar um cache local após uma alteração no banco de dados.

Dica de Implementação

Para assinantes de curta duração, crie uma fila exclusiva e de exclusão automática e vincule-a à exchange fanout. Para assinantes duráveis, use uma fila durável para que o assinante possa voltar e ler mensagens que chegaram enquanto estava offline.

Roteamento Direto e por Tópico: Enviar Eventos Seletivamente

Enquanto a exchange Fanout fornece transmissão cega, o AMQP oferece exchanges para publicação seletiva, estendendo o modelo Pub/Sub.

Exchange direta

As mensagens são roteadas para filas com base em uma correspondência exata entre a chave de roteamento da mensagem e a chave de ligação da fila. Isso é útil quando você precisa direcionar especificamente diferentes tipos de consumidores.

Por exemplo, seu publicador de log pode enviar mensagens com chaves de roteamento como error, warning e info. Uma fila de alerta pode vincular apenas a error, enquanto uma fila de arquivamento pode vincular a todas as três severidades.

Exchange de tópico

Este é o tipo de exchange mais flexível, permitindo que chaves de ligação e chaves de roteamento usem curingas. A chave de roteamento é tratada como uma lista delimitada (por exemplo, usando pontos .).

• * corresponde exatamente a uma palavra.
• # corresponde a zero ou mais palavras.

Uma chave de roteamento como orders.us.created pode ir para uma fila de fraude vinculada a orders.*.created e uma fila de operações dos EUA vinculada a #.us.#. Use exchanges de tópico quando suas regras de roteamento são categorias de negócios reais, não apenas um campo fixo.

Solicitar/Responder: Pedir uma Resposta Específica

O padrão Solicitar/Responder permite que um aplicativo cliente envie uma mensagem de solicitação e aguarde sincronizadamente uma resposta de um worker (servidor). Embora a mensageria seja inerentemente assíncrona, esse padrão simula Chamadas de Procedimento Remoto (RPC) tradicionais sobre o barramento de mensagens.

Use reply_to e correlation_id

1. O cliente envia uma solicitação para uma fila como rpc_queue.
2. O cliente define reply_to para uma fila de retorno de chamada que está consumindo.
3. O cliente define um correlation_id único.
4. O worker processa a solicitação e publica a resposta na fila reply_to.
5. O cliente corresponde a resposta à solicitação original verificando correlation_id.

Casos de Uso

• Consultas de serviço: Buscar um perfil de usuário ou feature flag de outro serviço.
• Decisões curtas: Verificar o estoque antes de aceitar um pedido.

Use com cuidado

Solicitar/Responder é útil, mas traz espera síncrona de volta ao seu sistema de mensagens. Defina timeouts no cliente, lide com respostas duplicadas e evite usar RPC para trabalhos de longa duração. Para trabalho lento, publique um comando, retorne um ID de trabalho e envie eventos de progresso ou conclusão separadamente.

Fluxo RPC Conceitual

graph TD
    A[Cliente (Solicitante)] -->|1. Mensagem de Solicitação (incl. reply_to, correlation_id)| B(Fila de Solicitação RPC);
    B --> C[Servidor (Worker)];
    C -->|2. Processar Solicitação|
D[Resultado];
    D -->|3. Mensagem de Resposta (via reply_to, mantendo correlation_id)| A;

---

Padrões Comuns RabbitMQ de Relance

Padrão	Tipo de Exchange	Mecanismo de Roteamento	Característica Principal	Caso de Uso Principal
Filas de Trabalho	Padrão ou Direta	Uma fila compartilhada por workers	Uma mensagem, um consumidor	Balanceamento de carga de tarefas de longa duração
Publicar/Assinar	Fanout	Ignora chave de roteamento	Uma mensagem, todas as filas vinculadas	Transmissões do sistema, logging
Roteamento Direto	Direta	Correspondência exata da chave de roteamento	Segmentação seletiva de consumidores	Roteamento baseado em severidade ou tipo
Roteamento por Tópico	Tópico	Correspondência curinga (*, #)	Roteamento flexível e complexo	Comunicação entre microsserviços, streams de eventos
Solicitar/Responder (RPC)	Direta (para resposta)	Usa reply_to e correlation_id	Simula chamadas de API síncronas	Consultas imediatas de serviço, pequenas transações

Conclusão

Comece com a forma da comunicação. Use Filas de Trabalho quando exatamente um worker deve lidar com um trabalho, Pub/Sub quando todo assinante deve ver um evento, roteamento Direto ou por Tópico quando apenas alguns assinantes devem vê-lo, e Solicitar/Responder apenas quando o chamador realmente precisa de uma resposta imediata.