Strategie efficaci di binding RabbitMQ per il routing dei messaggi

I binding sono il punto in cui il routing di RabbitMQ diventa reale. I produttori pubblicano sugli exchange, i consumatori leggono dalle code e i binding decidono quali code ricevono quali messaggi. Quando un design di routing è pulito, i produttori non hanno bisogno di sapere quanti consumatori esistono e i consumatori possono essere aggiunti senza modificare il codice del publisher. Quando è disordinato, i messaggi scompaiono in percorsi non instradabili, le code ricevono lavoro che non possono elaborare e ogni distribuzione diventa un gioco di ipotesi.

Il modo più utile di pensare alle strategie di binding di RabbitMQ non è "qual è il tipo di exchange migliore?" È "quale promessa sto facendo sulla consegna dei messaggi?" Un evento di fatturazione, un log di audit, un'invalidazione della cache e un messaggio di retry hanno tutti esigenze di routing diverse. Il binding dovrebbe rendere ovvia questa intenzione.

Inizia con la forma dell'evento

Le routing key funzionano meglio quando descrivono fatti stabili sul messaggio, non dettagli di implementazione temporanei. Una chiave come orders.created probabilmente sopravviverà a diverse versioni della tua applicazione. Una chiave come worker-3.fast-path probabilmente no.

Per gli exchange topic, usa una gerarchia piccola e coerente:

dominio.entità.azione
orders.invoice.created
orders.invoice.paid
orders.shipment.failed
users.account.disabled

Un consumatore può quindi legarsi a orders.invoice.* per eventi di fattura, orders.# per tutti gli eventi del dominio ordini, o #.failed per la gestione operativa dei fallimenti. Questo è molto più facile da ragionare rispetto a mescolare new_order, invoice.paid e shipping-error sullo stesso exchange.

Binding direct: nomi esatti per lavori esatti

Un exchange direct è una buona scelta quando il publisher conosce la classe esatta di lavoro e ogni coda vuole una o più chiavi esatte.

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 un messaggio viene pubblicato con invoice.created, entrambe le code ricevono una copia. Se viene pubblicato con shipment.created, nessuna coda lo riceve a meno che non esista un altro binding. Questa esattezza è il punto.

Usa i binding direct per code di lavoro simili a comandi, nomi di eventi chiari e piccoli insiemi di routing key. Evita di usarli come sostituto per il routing topic quando la lista cresce fino a dozzine di chiavi quasi duplicate. A quel punto, finirai per mantenere a mano una tabella di routing fragile.

Binding topic: sottoscrizioni flessibili senza cambiare i publisher

Gli exchange topic sono di solito il default più pratico per i sistemi basati su eventi. Il publisher invia una routing key. Ogni coda decide quanto ampia o stretta debba essere la sua sottoscrizione.

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=#

Le regole dei wildcard sono precise:

• * corrisponde esattamente a una parola tra i punti.
• # corrisponde a zero o più parole.

Quindi orders.*.failed corrisponde a orders.payment.failed, ma non a orders.eu.payment.failed. orders.# corrisponde a orders, orders.created e orders.eu.payment.failed.

Il rischio principale con gli exchange topic è la sovra-sottoscrizione accidentale. Una coda legata a # riceverà tutto ciò che viene pubblicato sull'exchange. Questo può andare bene per sistemi di analisi o archiviazione, ma è una brutta sorpresa per un servizio che capisce solo uno schema di messaggi. Mantieni i binding ampi rari e dai a quelle code nomi onesti.

Binding fanout: broadcast senza dibattito sulla routing key

Un exchange fanout invia ogni messaggio a ogni coda legata e ignora la routing key. Questo lo rende eccellente per l'invalidazione della cache, code di tap per lo sviluppo locale e notifiche "ogni sottosistema dovrebbe sentire questo".

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

Non usare fanout perché le routing key sembrano scomode. Se solo tre su dieci consumatori hanno bisogno di un messaggio, usa il routing direct o topic. Fanout è intenzionalmente brusco: ogni coda legata riceve una copia.

Binding headers: utili, ma mantienili noiosi

Gli exchange headers instradano in base agli header del messaggio invece che alle routing key. Possono corrispondere a tutti gli header o a qualsiasi header usando l'argomento di 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()

Il routing headers è utile quando i messaggi provengono da sistemi che già portano metadati significativi. È anche facile renderlo opaco. Se la regola di routing non può essere compresa rapidamente dal binding della coda, preferisci una chiave topic.

Errori di binding che causano incidenti reali

Il fallimento di binding più comune è una mancata corrispondenza di vhost. Gli oggetti RabbitMQ vivono all'interno di virtual host. Un exchange chiamato orders.events in / non è lo stesso oggetto di orders.events in prod. Controlla sempre con -V o -p quando usi gli strumenti CLI.

rabbitmqctl -p prod list_bindings source_name destination_name routing_key arguments

Il prossimo fallimento è assumere che un exchange direct si comporti come un exchange topic. Un binding direct di orders.* corrisponde solo alla chiave letterale orders.*. Non corrisponde a orders.created. Se hai bisogno di wildcard, il tipo di exchange deve essere topic.

Un altro comune è legare una coda a un exchange di retry con la stessa routing key che la rimanda immediatamente a se stessa. Questo può creare un ciclo di retry veloce. Per i retry, rendi il percorso esplicito: coda attiva -> exchange di retry -> coda di ritardo -> exchange originale, con una coda di parcheggio dopo il tentativo finale.

Infine, fai attenzione ai binding duplicati creati dall'automazione. RabbitMQ tratta i binding duplicati con le stesse proprietà in modo idempotente, ma i quasi-duplicati sono ancora diversi. orders.created e order.created possono stare fianco a fianco per mesi prima che qualcuno noti che metà dei messaggi vanno al servizio sbagliato.

Una semplice checklist di revisione

Prima di distribuire una modifica al routing, mi piace rispondere a queste domande:

• Quale exchange riceve la pubblicazione?
• Quale routing key o header esatti invierà il produttore?
• Quali code dovrebbero ricevere una copia?
• Quali code non devono riceverla?
• Cosa succede se nessun binding corrisponde?
• Esiste un exchange alternativo o una gestione del ritorno del publisher per messaggi non instradabili?
• I binding di retry e dead-letter sono unidirezionali o possono creare un ciclo?

Poi verifica la topologia distribuita:

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

Le buone strategie di binding RabbitMQ sono di solito noiose. I nomi sono prevedibili, i wildcard sono intenzionali e il percorso di fallimento è visibile. Questo è esattamente ciò che vuoi quando un produttore distribuisce a mezzanotte e il grafico delle code deve spiegarsi senza una riunione.