Stratégies de liaison RabbitMQ efficaces pour le routage des messages

Les liaisons sont l'endroit où le routage RabbitMQ devient réel. Les producteurs publient sur les échanges, les consommateurs lisent depuis les files d'attente, et les liaisons décident quelles files d'attente reçoivent quels messages. Lorsqu'une conception de routage est propre, les producteurs n'ont pas besoin de savoir combien de consommateurs existent, et les consommateurs peuvent être ajoutés sans modifier le code de l'éditeur. Quand c'est désordonné, les messages disparaissent dans des chemins non routables, les files d'attente reçoivent un travail qu'elles ne peuvent pas traiter, et chaque déploiement devient un jeu de devinettes.

La façon la plus utile de penser aux stratégies de liaison RabbitMQ n'est pas "quel type d'échange est le meilleur ?" C'est "quelle promesse est-ce que je fais concernant la livraison des messages ?" Un événement de facturation, un journal d'audit, une invalidation de cache et un message de nouvelle tentative ont tous des besoins de routage différents. La liaison doit rendre cette intention évidente.

Commencez par la forme de l'événement

Les clés de routage fonctionnent mieux lorsqu'elles décrivent des faits stables sur le message, et non des détails d'implémentation temporaires. Une clé comme orders.created survivra probablement à plusieurs versions de votre application. Une clé comme worker-3.fast-path ne le fera probablement pas.

Pour les échanges thématiques, utilisez une hiérarchie petite et cohérente :

domain.entity.action
orders.invoice.created
orders.invoice.paid
orders.shipment.failed
users.account.disabled

Un consommateur peut alors se lier à orders.invoice.* pour les événements de facture, orders.# pour tous les événements du domaine des commandes, ou #.failed pour la gestion des échecs opérationnels. C'est beaucoup plus facile à raisonner que de mélanger new_order, invoice.paid et shipping-error sur le même échange.

Liaisons directes : noms exacts pour des tâches exactes

Un échange direct est un bon choix lorsque l'éditeur connaît la classe exacte du travail, et que chaque file d'attente veut une ou plusieurs clés exactes.

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

Si un message est publié avec invoice.created, les deux files d'attente reçoivent une copie. S'il est publié avec shipment.created, aucune file d'attente ne le reçoit à moins qu'une autre liaison n'existe. Cette exactitude est le point.

Utilisez les liaisons directes pour les files d'attente de travail de type commande, les noms d'événements clairs et les petits ensembles de clés de routage. Évitez de les utiliser comme substitut au routage thématique lorsque la liste se transforme en dizaines de clés presque identiques. À ce stade, vous finirez par maintenir une table de routage fragile à la main.

Liaisons thématiques : abonnements flexibles sans modifier les éditeurs

Les échanges thématiques sont généralement le choix pratique par défaut pour les systèmes basés sur les événements. L'éditeur envoie une clé de routage. Chaque file d'attente décide à quel point son abonnement doit être large ou étroit.

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

Les règles des caractères génériques sont précises :

• * correspond exactement à un mot entre les points.
• # correspond à zéro ou plusieurs mots.

Ainsi, orders.*.failed correspond à orders.payment.failed, mais pas à orders.eu.payment.failed. orders.# correspond à orders, orders.created et orders.eu.payment.failed.

Le principal risque avec les échanges thématiques est le sur-abonnement accidentel. Une file d'attente liée à # recevra tout ce qui est publié sur l'échange. Cela peut être acceptable pour les systèmes d'analyse ou d'archivage, mais c'est une mauvaise surprise pour un service qui ne comprend qu'un seul schéma de message. Gardez les liaisons larges rares et nommez ces files d'attente honnêtement.

Liaisons fanout : diffusion sans débat sur la clé de routage

Un échange fanout envoie chaque message à chaque file d'attente liée et ignore la clé de routage. Cela le rend excellent pour l'invalidation de cache, les files d'attente de développement local et les notifications "tous les sous-systèmes doivent entendre cela".

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'utilisez pas fanout parce que les clés de routage semblent peu pratiques. Si seulement trois consommateurs sur dix ont besoin d'un message, utilisez le routage direct ou thématique. Fanout est intentionnellement brutal : chaque file d'attente liée reçoit une copie.

Liaisons par en-têtes : utiles, mais gardez-les ennuyeuses

Les échanges par en-têtes routent par en-têtes de message au lieu de clés de routage. Ils peuvent correspondre à tous les en-têtes ou à n'importe quel en-tête en utilisant l'argument de liaison 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()

Le routage par en-têtes est pratique lorsque les messages proviennent de systèmes qui portent déjà des métadonnées significatives. Il est également facile de le rendre opaque. Si la règle de routage ne peut pas être comprise rapidement à partir de la liaison de file d'attente, préférez une clé thématique.

Erreurs de liaison qui causent de véritables incidents

L'échec de liaison le plus courant est une discordance de vhost. Les objets RabbitMQ vivent à l'intérieur de hôtes virtuels. Un échange nommé orders.events dans / n'est pas le même objet que orders.events dans prod. Vérifiez toujours avec -V ou -p lors de l'utilisation d'outils CLI.

rabbitmqctl -p prod list_bindings source_name destination_name routing_key arguments

L'échec suivant est de supposer qu'un échange direct se comporte comme un échange thématique. Une liaison directe de orders.* correspond uniquement à la clé littérale orders.*. Elle ne correspond pas à orders.created. Si vous avez besoin de caractères génériques, le type d'échange doit être topic.

Une autre erreur courante est de lier une file d'attente à un échange de nouvelle tentative avec la même clé de routage qui la renvoie immédiatement à elle-même. Cela peut créer une boucle de nouvelle tentative rapide. Pour les nouvelles tentatives, rendez le chemin explicite : file d'attente active -> échange de nouvelle tentative -> file d'attente de délai -> échange d'origine, avec une file d'attente de stationnement après la tentative finale.

Enfin, surveillez les liaisons en double créées par l'automatisation. RabbitMQ traite les liaisons en double avec les mêmes propriétés de manière idempotente, mais les quasi-doublons sont toujours différents. orders.created et order.created peuvent coexister pendant des mois avant que quelqu'un ne remarque que la moitié des messages vont au mauvais service.

Une simple liste de vérification pour la révision

Avant de livrer un changement de routage, j'aime répondre à ces questions :

• Quel échange reçoit la publication ?
• Quelle clé de routage ou quels en-têtes exacts le producteur enverra-t-il ?
• Quelles files d'attente devraient recevoir une copie ?
• Quelles files d'attente ne doivent pas la recevoir ?
• Que se passe-t-il si aucune liaison ne correspond ?
• Y a-t-il un échange alternatif ou une gestion de retour d'éditeur pour les messages non routables ?
• Les liaisons de nouvelle tentative et de lettre morte sont-elles unidirectionnelles, ou peuvent-elles boucler ?

Ensuite, vérifiez la topologie déployée :

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

Les bonnes stratégies de liaison RabbitMQ sont généralement ennuyeuses. Les noms sont prévisibles, les caractères génériques sont intentionnels et le chemin d'échec est visible. C'est exactement ce que vous voulez lorsqu'un producteur se déploie à minuit et que le graphique des files d'attente doit s'expliquer sans réunion.