Publish/Subscribe-Muster: Nachrichten an viele Empfänger

Kurz: Ein Sender veröffentlicht Nachrichten zu einem Thema, ohne die Empfänger zu kennen; jeder, der das Thema abonniert hat, erhält sie.

Genauer: Beim Publish/Subscribe (Pub/Sub) sind Sender (Publisher) und Empfänger (Subscriber) entkoppelt. Dazwischen steht ein Vermittler, der Broker. Der Publisher weiß nicht, wer zuhört, die Subscriber wissen nicht, wer sendet. Dadurch lassen sich Systeme leicht erweitern: Ein neuer Empfänger abonniert einfach ein vorhandenes Thema.

Im Detail

Bausteine

• Topic (Thema, Kanal): Name, unter dem Nachrichten veröffentlicht werden, z. B. bestellung.neu.
• Publisher: schickt Nachrichten an ein Topic.
• Subscriber: abonniert Topics und verarbeitet eingehende Nachrichten.
• Broker: nimmt Nachrichten an, verteilt sie und kann sie zwischenspeichern. Beispiele: MQTT-Broker, Redis Pub/Sub, Google Pub/Sub, Apache Kafka.

Unterschied zur Warteschlange

In einer klassischen Warteschlange bekommt jede Nachricht genau ein Verbraucher von mehreren konkurrierenden. Bei Pub/Sub erhält jeder Abonnent eine Kopie. Viele Systeme kombinieren beides: Mehrere Dienste abonnieren ein Topic, und innerhalb eines Dienstes teilen sich mehrere Instanzen die Arbeit (Consumer Groups).

Beispiel in JavaScript mit Redis

// Empfänger
subscriber.subscribe('bestellung.neu', (msg) => console.log('Neu:', msg));
// Sender
publisher.publish('bestellung.neu', JSON.stringify({ id: 42 }));

Der Rechnungsdienst und der Versanddienst können dasselbe Topic abonnieren und unabhängig voneinander reagieren.

Auf Dinge achten

Reines Redis Pub/Sub speichert nichts: Wer gerade nicht verbunden ist, verpasst die Nachricht. Für zuverlässige Zustellung braucht man Broker mit Speicherung und Bestätigungen (Acknowledgements). Weil dieselbe Nachricht mehrfach ankommen kann, sollten Empfänger idempotent arbeiten. Die Reihenfolge ist je nach System nur pro Partition oder gar nicht garantiert.

Siehe auch: Message Queue, Apache Kafka, Observer-Muster, Webhooks