Effektive RabbitMQ-Bindungsstrategien für das Nachrichten-Routing

Bindungen sind der Punkt, an dem RabbitMQ-Routing real wird. Produzenten veröffentlichen Nachrichten an Exchanges, Konsumenten lesen aus Queues, und Bindungen entscheiden, welche Queues welche Nachrichten erhalten. Wenn ein Routing-Design sauber ist, müssen Produzenten nicht wissen, wie viele Konsumenten es gibt, und Konsumenten können hinzugefügt werden, ohne den Publisher-Code zu ändern. Wenn es chaotisch ist, verschwinden Nachrichten in nicht routbaren Pfaden, Queues erhalten Arbeit, die sie nicht verarbeiten können, und jede Bereitstellung wird zum Ratespiel.

Die sinnvollste Art, über RabbitMQ-Bindungsstrategien nachzudenken, ist nicht „Welcher Exchange-Typ ist der beste?", sondern „Welches Versprechen mache ich bezüglich der Nachrichtenzustellung?" Ein Abrechnungsereignis, ein Audit-Log, eine Cache-Invalidierung und eine Wiederholungsnachricht haben alle unterschiedliche Routing-Anforderungen. Die Bindung sollte diese Absicht deutlich machen.

Beginnen Sie mit der Form des Ereignisses

Routing-Keys funktionieren am besten, wenn sie stabile Fakten über die Nachricht beschreiben, nicht vorübergehende Implementierungsdetails. Ein Key wie orders.created wird wahrscheinlich mehrere Versionen Ihrer Anwendung überleben. Ein Key wie worker-3.fast-path wird das wahrscheinlich nicht.

Verwenden Sie für Topic-Exchanges eine kleine, konsistente Hierarchie:

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

Ein Konsument kann dann an orders.invoice.* für Rechnungsereignisse, an orders.# für alle Ereignisse der Bestell-Domäne oder an #.failed für die operative Fehlerbehandlung binden. Das ist viel einfacher zu durchschauen, als new_order, invoice.paid und shipping-error auf demselben Exchange zu mischen.

Direct-Bindungen: exakte Namen für exakte Aufgaben

Ein Direct-Exchange ist eine gute Wahl, wenn der Publisher die genaue Art der Arbeit kennt und jede Queue einen oder mehrere exakte Keys haben möchte.

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

Wenn eine Nachricht mit invoice.created veröffentlicht wird, erhalten beide Queues eine Kopie. Wenn sie mit shipment.created veröffentlicht wird, erhält keine Queue sie, es sei denn, es existiert eine andere Bindung. Diese Exaktheit ist der Punkt.

Verwenden Sie Direct-Bindungen für befehlsähnliche Work-Queues, klare Ereignisnamen und kleine Sätze von Routing-Keys. Vermeiden Sie sie als Ersatz für Topic-Routing, wenn die Liste auf Dutzende fast identischer Keys anwächst. An diesem Punkt werden Sie eine fragile Routing-Tabelle manuell pflegen müssen.

Topic-Bindungen: flexible Abonnements ohne Änderung der Publisher

Topic-Exchanges sind in der Regel der praktischste Standard für ereignisbasierte Systeme. Der Publisher sendet einen Routing-Key. Jede Queue entscheidet, wie breit oder eng ihr Abonnement sein soll.

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

Die Wildcard-Regeln sind präzise:

• * entspricht genau einem Wort zwischen Punkten.
• # entspricht null oder mehr Wörtern.

Also passt orders.*.failed auf orders.payment.failed, aber nicht auf orders.eu.payment.failed. orders.# passt auf orders, orders.created und orders.eu.payment.failed.

Das Hauptrisiko bei Topic-Exchanges ist die versehentliche Überabonnierung. Eine Queue, die an # gebunden ist, erhält alles, was an den Exchange veröffentlicht wird. Das mag für Analyse- oder Archivsysteme in Ordnung sein, ist aber eine böse Überraschung für einen Dienst, der nur ein Nachrichtenschema versteht. Halten Sie breite Bindungen selten und benennen Sie diese Queues ehrlich.

Fanout-Bindungen: Broadcast ohne Routing-Key-Debatte

Ein Fanout-Exchange sendet jede Nachricht an jede gebundene Queue und ignoriert den Routing-Key. Das macht ihn hervorragend für Cache-Invalidierung, lokale Entwicklungs-Tap-Queues und Benachrichtigungen, die jedes Subsystem hören sollte.

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

Verwenden Sie Fanout nicht, weil Routing-Keys unbequem erscheinen. Wenn nur drei von zehn Konsumenten eine Nachricht benötigen, verwenden Sie Direct- oder Topic-Routing. Fanout ist absichtlich direkt: Jede gebundene Queue erhält eine Kopie.

Headers-Bindungen: nützlich, aber halten Sie sie langweilig

Headers-Exchanges routen nach Nachrichten-Headern anstelle von Routing-Keys. Sie können alle Header oder jeden beliebigen Header mit dem x-match-Bindungsargument abgleichen.

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()

Headers-Routing ist praktisch, wenn Nachrichten von Systemen kommen, die bereits aussagekräftige Metadaten enthalten. Es ist auch leicht, es undurchsichtig zu machen. Wenn die Routing-Regel nicht schnell aus der Queue-Bindung verstanden werden kann, bevorzugen Sie einen Topic-Key.

Bindungsfehler, die zu echten Vorfällen führen

Der häufigste Bindungsfehler ist ein Vhost-Mismatch. RabbitMQ-Objekte leben innerhalb virtueller Hosts. Ein Exchange namens orders.events in / ist nicht dasselbe Objekt wie orders.events in prod. Überprüfen Sie immer mit -V oder -p, wenn Sie CLI-Tools verwenden.

rabbitmqctl -p prod list_bindings source_name destination_name routing_key arguments

Der nächste Fehler ist die Annahme, dass sich ein Direct-Exchange wie ein Topic-Exchange verhält. Eine Direct-Bindung von orders.* entspricht nur dem literalen Key orders.*. Sie entspricht nicht orders.created. Wenn Sie Wildcards benötigen, muss der Exchange-Typ topic sein.

Ein weiterer häufiger Fehler ist das Binden einer Queue an einen Retry-Exchange mit demselben Routing-Key, der sie sofort an sich selbst zurücksendet. Das kann eine schnelle Retry-Schleife erzeugen. Machen Sie für Wiederholungen den Pfad explizit: aktive Queue -> Retry-Exchange -> Delay-Queue -> ursprünglicher Exchange, mit einer Parking-Queue nach dem letzten Versuch.

Achten Sie schließlich auf doppelte Bindungen, die durch Automatisierung erstellt wurden. RabbitMQ behandelt doppelte Bindungen mit denselben Eigenschaften idempotent, aber fast identische sind immer noch unterschiedlich. orders.created und order.created können monatelang nebeneinander existieren, bevor jemand bemerkt, dass die Hälfte der Nachrichten an den falschen Dienst geht.

Eine einfache Überprüfungs-Checkliste

Bevor Sie eine Routing-Änderung ausliefern, beantworte ich gerne diese Fragen:

• Welcher Exchange empfängt die Veröffentlichung?
• Welchen exakten Routing-Key oder welche Header wird der Produzent senden?
• Welche Queues sollten eine Kopie erhalten?
• Welche Queues dürfen sie nicht erhalten?
• Was passiert, wenn keine Bindung passt?
• Gibt es einen Alternate-Exchange oder Publisher-Return-Handling für nicht routbare Nachrichten?
• Sind Retry- und Dead-Letter-Bindungen unidirektional oder können sie Schleifen bilden?

Überprüfen Sie dann die bereitgestellte Topologie:

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

Gute RabbitMQ-Bindungsstrategien sind in der Regel langweilig. Die Namen sind vorhersehbar, die Wildcards sind beabsichtigt, und der Fehlerpfad ist sichtbar. Das ist genau das, was Sie wollen, wenn ein Produzent um Mitternacht bereitstellt und der Queue-Graph sich ohne Meeting erklären muss.