Estratégias Eficazes de Binding no RabbitMQ para Roteamento de Mensagens

Bindings são onde o roteamento do RabbitMQ se torna real. Produtores publicam em exchanges, consumidores leem de filas, e bindings decidem quais filas recebem quais mensagens. Quando um design de roteamento é limpo, os produtores não precisam saber quantos consumidores existem, e os consumidores podem ser adicionados sem alterar o código do publicador. Quando é confuso, mensagens desaparecem em caminhos não roteáveis, filas recebem trabalho que não podem processar, e cada implantação se torna um jogo de adivinhação.

A maneira mais útil de pensar sobre estratégias de binding no RabbitMQ não é "qual tipo de exchange é melhor?" É "que promessa estou fazendo sobre a entrega da mensagem?" Um evento de faturamento, um log de auditoria, uma invalidação de cache e uma mensagem de repetição têm necessidades de roteamento diferentes. O binding deve tornar essa intenção óbvia.

Comece com a forma do evento

Chaves de roteamento funcionam melhor quando descrevem fatos estáveis sobre a mensagem, não detalhes temporários de implementação. Uma chave como orders.created provavelmente sobreviverá a várias versões da sua aplicação. Uma chave como worker-3.fast-path provavelmente não.

Para exchanges de tópico, use uma hierarquia pequena e consistente:

dominio.entidade.acao
orders.invoice.created
orders.invoice.paid
orders.shipment.failed
users.account.disabled

Um consumidor pode então se ligar a orders.invoice.* para eventos de fatura, orders.# para todos os eventos do domínio de pedidos, ou #.failed para tratamento operacional de falhas. Isso é muito mais fácil de raciocinar do que misturar new_order, invoice.paid e shipping-error na mesma exchange.

Bindings diretos: nomes exatos para trabalhos exatos

Uma exchange direta é uma boa escolha quando o publicador sabe a classe exata do trabalho, e cada fila quer uma ou mais chaves exatas.

rabbitmqadmin declare exchange name=orders.events type=direct durable=true
rabbitmqadmin declare queue name=billing.invoice-created durable=true
rabbitmqadmin declare queue name=audit.order-events durable=true

rabbitmqadmin declare binding source=orders.events destination=billing.invoice-created routing_key=invoice.created
rabbitmqadmin declare binding source=orders.events destination=audit.order-events routing_key=invoice.created
rabbitmqadmin declare binding source=orders.events destination=audit.order-events routing_key=invoice.paid

Se uma mensagem for publicada com invoice.created, ambas as filas recebem uma cópia. Se for publicada com shipment.created, nenhuma fila a recebe, a menos que exista outro binding. Essa exatidão é o ponto.

Use bindings diretos para filas de trabalho do tipo comando, nomes de eventos claros e pequenos conjuntos de chaves de roteamento. Evite usá-los como substituto para roteamento de tópico quando a lista crescer para dezenas de chaves quase duplicadas. Nesse ponto, você acabará mantendo uma tabela de roteamento frágil manualmente.

Bindings de tópico: assinaturas flexíveis sem alterar publicadores

Exchanges de tópico são geralmente o padrão mais prático para sistemas baseados em eventos. O publicador envia uma chave de roteamento. Cada fila decide quão ampla ou estreita deve ser sua assinatura.

rabbitmqadmin declare exchange name=platform.events type=topic durable=true
rabbitmqadmin declare queue name=fraud.orders durable=true
rabbitmqadmin declare queue name=ops.failures durable=true
rabbitmqadmin declare queue name=analytics.all-events durable=true

rabbitmqadmin declare binding source=platform.events destination=fraud.orders routing_key=orders.payment.*
rabbitmqadmin declare binding source=platform.events destination=ops.failures routing_key=#.failed
rabbitmqadmin declare binding source=platform.events destination=analytics.all-events routing_key=#

As regras de curinga são precisas:

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

Então orders.*.failed corresponde a orders.payment.failed, mas não a orders.eu.payment.failed. orders.# corresponde a orders, orders.created e orders.eu.payment.failed.

O principal risco com exchanges de tópico é a superassinatura acidental. Uma fila ligada a # receberá tudo o que for publicado na exchange. Isso pode ser aceitável para sistemas de análise ou arquivamento, mas é uma surpresa ruim para um serviço que só entende um esquema de mensagem. Mantenha bindings amplos raros e nomeie essas filas honestamente.

Bindings fanout: transmissão sem debate sobre chave de roteamento

Uma exchange fanout envia cada mensagem para todas as filas ligadas e ignora a chave de roteamento. Isso a torna excelente para invalidação de cache, filas de desenvolvimento local e notificações do tipo "todo subsistema deve ouvir isso".

rabbitmqadmin declare exchange name=deploy.notifications type=fanout durable=true
rabbitmqadmin declare queue name=slack.deploys durable=true
rabbitmqadmin declare queue name=audit.deploys durable=true

rabbitmqadmin declare binding source=deploy.notifications destination=slack.deploys
rabbitmqadmin declare binding source=deploy.notifications destination=audit.deploys

Não use fanout porque as chaves de roteamento parecem inconvenientes. Se apenas três de dez consumidores precisam de uma mensagem, use roteamento direto ou de tópico. Fanout é intencionalmente bruto: toda fila ligada recebe uma cópia.

Bindings de headers: úteis, mas mantenha-os simples

Exchanges de headers roteiam por cabeçalhos de mensagem em vez de chaves de roteamento. Elas podem corresponder a todos os cabeçalhos ou a qualquer cabeçalho usando o argumento de binding x-match.

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

channel.exchange_declare(exchange='documents', exchange_type='headers', durable=True)
channel.queue_declare(queue='pdf-invoices', durable=True)

channel.queue_bind(
    exchange='documents',
    queue='pdf-invoices',
    arguments={'x-match': 'all', 'format': 'pdf', 'type': 'invoice'}
)

channel.basic_publish(
    exchange='documents',
    routing_key='ignored',
    body=b'...',
    properties=pika.BasicProperties(headers={'format': 'pdf', 'type': 'invoice'})
)

connection.close()

O roteamento por headers é útil quando as mensagens vêm de sistemas que já carregam metadados significativos. Também é fácil de tornar opaco. Se a regra de roteamento não puder ser entendida rapidamente a partir do binding da fila, prefira uma chave de tópico.

Erros de binding que causam incidentes reais

A falha de binding mais comum é uma incompatibilidade de vhost. Os objetos do RabbitMQ vivem dentro de hosts virtuais. Uma exchange chamada orders.events em / não é o mesmo objeto que orders.events em prod. Sempre verifique com -V ou -p ao usar ferramentas CLI.

rabbitmqctl -p prod list_bindings source_name destination_name routing_key arguments

A próxima falha é assumir que uma exchange direta se comporta como uma exchange de tópico. Um binding direto de orders.* corresponde apenas à chave literal orders.*. Não corresponde a orders.created. Se você precisar de curingas, o tipo de exchange deve ser topic.

Outro erro comum é ligar uma fila a uma exchange de repetição com a mesma chave de roteamento que a envia de volta para si mesma imediatamente. Isso pode criar um loop rápido de repetição. Para repetições, torne o caminho explícito: fila ativa -> exchange de repetição -> fila de atraso -> exchange original, com uma fila de estacionamento após a tentativa final.

Finalmente, cuidado com bindings duplicados criados por automação. O RabbitMQ trata bindings duplicados com as mesmas propriedades de forma idempotente, mas quase duplicados ainda são diferentes. orders.created e order.created podem ficar lado a lado por meses antes que alguém perceba que metade das mensagens está indo para o serviço errado.

Uma lista de verificação simples para revisão

Antes de enviar uma alteração de roteamento, gosto de responder a estas perguntas:

• Qual exchange recebe a publicação?
• Qual chave de roteamento ou cabeçalhos exatos o produtor enviará?
• Quais filas devem receber uma cópia?
• Quais filas não devem recebê-la?
• O que acontece se nenhum binding corresponder?
• Existe uma exchange alternativa ou tratamento de retorno do publicador para mensagens não roteáveis?
• Os bindings de repetição e dead-letter são unidirecionais ou podem criar um loop?

Em seguida, verifique a topologia implantada:

rabbitmqctl -p prod list_exchanges name type durable arguments
rabbitmqctl -p prod list_queues name durable arguments
rabbitmqctl -p prod list_bindings source_name source_kind destination_name destination_kind routing_key arguments

Boas estratégias de binding no RabbitMQ são geralmente simples. Os nomes são previsíveis, os curingas são intencionais e o caminho de falha é visível. Isso é exatamente o que você deseja quando um produtor implanta à meia-noite e o gráfico de filas precisa se explicar sem uma reunião.