Publisher-Subscriber-Entwurfsmuster - Versionsgeschichte

PhilKa: /* Beispiele in realen Systemen */

2025-11-08T13:05:20Z

Beispiele in realen Systemen

← Nächstältere Version		Version vom 8. November 2025, 15:05 Uhr
Zeile 88:		Zeile 88:
	{\| class="wikitable"		{\| class="wikitable"
	! System !! Rolle		! System !! Rolle
			\|-
	\| ''RabbitMQ'' \|\| Topic/Fanout Exchanges für Pub/Sub		\| ''RabbitMQ'' \|\| Topic/Fanout Exchanges für Pub/Sub
			\|-
	\| ''Apache Kafka'' \|\| Verteilt Nachrichtenströme an Consumer-Gruppen		\| ''Apache Kafka'' \|\| Verteilt Nachrichtenströme an Consumer-Gruppen
			\|-
	\| ''Redis Pub/Sub'' \|\| Leichtgewichtiges Pub/Sub-Modell in Infrastrukturanwendungen		\| ''Redis Pub/Sub'' \|\| Leichtgewichtiges Pub/Sub-Modell in Infrastrukturanwendungen
			\|-
	\| ''WebSockets / Socket.IO'' \|\| Ereignisbasierte Kommunikation in Echtzeit-Anwendungen		\| ''WebSockets / Socket.IO'' \|\| Ereignisbasierte Kommunikation in Echtzeit-Anwendungen
			\|-
	\| ''Cloud Pub/Sub (Google/AWS/Azure)'' \|\| Globale Messaging-Systeme für verteilte Microservices		\| ''Cloud Pub/Sub (Google/AWS/Azure)'' \|\| Globale Messaging-Systeme für verteilte Microservices
	\|}		\|}

PhilKa: /* Publisher-Subscriber-Entwurfsmuster */

2025-11-08T13:04:44Z

Publisher-Subscriber-Entwurfsmuster

← Nächstältere Version		Version vom 8. November 2025, 15:04 Uhr
Zeile 86:		Zeile 86:

	== Beispiele in realen Systemen ==		== Beispiele in realen Systemen ==
	\| System \| Rolle \|		{\| class="wikitable"
	~~\|-------\|-------\|~~		! System !! Rolle
	\| ''RabbitMQ'' \| Topic/Fanout Exchanges für Pub/Sub \|		\| ''RabbitMQ'' \|\| Topic/Fanout Exchanges für Pub/Sub
	\| ''Apache Kafka'' \| Verteilt Nachrichtenströme an Consumer-Gruppen \|		\| ''Apache Kafka'' \|\| Verteilt Nachrichtenströme an Consumer-Gruppen
	\| ''Redis Pub/Sub'' \| Leichtgewichtiges Pub/Sub-Modell in Infrastrukturanwendungen \|		\| ''Redis Pub/Sub'' \|\| Leichtgewichtiges Pub/Sub-Modell in Infrastrukturanwendungen
	\| ''WebSockets / Socket.IO'' \| Ereignisbasierte Kommunikation in Echtzeit-Anwendungen \|		\| ''WebSockets / Socket.IO'' \|\| Ereignisbasierte Kommunikation in Echtzeit-Anwendungen
	\| ''Cloud Pub/Sub (Google/AWS/Azure)'' \| Globale Messaging-Systeme für verteilte Microservices \|		\| ''Cloud Pub/Sub (Google/AWS/Azure)'' \|\| Globale Messaging-Systeme für verteilte Microservices
			\|}

	== Vorteile ==		== Vorteile ==

PhilKa am 8. November 2025 um 13:02 Uhr

2025-11-08T13:02:58Z

← Nächstältere Version		Version vom 8. November 2025, 15:02 Uhr
Zeile 1:		Zeile 1:
	= Publisher-Subscriber-Entwurfsmuster =		= Publisher-Subscriber-Entwurfsmuster =

	Das '''Publisher-Subscriber-Entwurfsmuster''' (kurz: '''Pub/Sub''') ist ein Verhaltens- und Integrationsmuster, das die asynchrone, lose gekoppelte Kommunikation zwischen Softwarekomponenten ermöglicht.		Das '''Publisher-Subscriber-Entwurfsmuster''' (kurz: '''Pub/Sub''') ist ein ''Verhaltens- und Integrationsmuster'', das die ''asynchrone, lose gekoppelte Kommunikation'' zwischen Softwarekomponenten ermöglicht.
	Statt dass Sender (Publisher) Nachrichten direkt an Empfänger (Subscriber) senden, werden diese über eine vermittelnde Instanz (z. B. Message Broker oder Event-Bus) verteilt.		Statt dass Sender (Publisher) Nachrichten direkt an Empfänger (Subscriber) senden, werden diese über eine ''vermittelnde Instanz'' (z. B. Message Broker oder Event-Bus) verteilt.

	== Ziel ==		== Ziel ==
	Das Muster soll:		Das Muster soll:
	* Abhängigkeiten zwischen Sender und Empfänger vermeiden		* ''Abhängigkeiten zwischen Sender und Empfänger vermeiden''
	* Asynchrone Kommunikationsabläufe ermöglichen		* ''Asynchrone Kommunikationsabläufe ermöglichen''
	* Skalierbarkeit verbessern		* ''Skalierbarkeit verbessern''
	* Flexibilität und Erweiterbarkeit des Systems erhöhen		* ''Flexibilität und Erweiterbarkeit des Systems erhöhen''
	* Ereignisgesteuerte Architekturen unterstützen		* ''Ereignisgesteuerte Architekturen unterstützen''

	== Grundprinzip ==		== Grundprinzip ==
	Komponenten, die Nachrichten senden möchten, veröffentlichen diese bei einem Publisher oder über einen Message Broker.		Komponenten, die Nachrichten senden möchten, veröffentlichen diese bei einem ''Publisher'' oder über einen ''Message Broker''.
	Komponenten, die Nachrichten empfangen möchten, registrieren sich (abonnieren) bei einem Subscriber-Interface oder beim Broker.		Komponenten, die Nachrichten empfangen möchten, registrieren sich (abonnieren) bei einem ''Subscriber''-Interface oder beim Broker.
	Der Publisher kennt die Subscriber nicht direkt.		Der Publisher kennt die Subscriber ''nicht'' direkt.

	=== Grafische Darstellung ===		=== Grafische Darstellung ===
Zeile 31:		Zeile 31:
	! Komponente !! Rolle		! Komponente !! Rolle
	\|-		\|-
	\| Publisher \|\| Erzeugt und veröffentlicht Nachrichten/Ereignisse.		\| ''Publisher'' \|\| Erzeugt und veröffentlicht Nachrichten/Ereignisse.
	\|-		\|-
	\| Subscriber \|\| Registriert sich für bestimmte Nachrichten und verarbeitet sie.		\| ''Subscriber'' \|\| Registriert sich für bestimmte Nachrichten und verarbeitet sie.
	\|-		\|-
	\| Broker / Event Bus \|\| Vermittelt Nachrichten zwischen Publishern und Subscribern.		\| ''Broker / Event Bus'' \|\| Vermittelt Nachrichten zwischen Publishern und Subscribern.
	\|}		\|}

	== Ablauf ==		== Ablauf ==
	1. Der Subscriber meldet sich beim Broker für bestimmte Themen oder Ereignisse an.		1. Der ''Subscriber'' meldet sich beim Broker für bestimmte Themen oder Ereignisse an.
	2. Der Publisher sendet eine Nachricht an den Broker.		2. Der ''Publisher'' sendet eine Nachricht an den Broker.
	3. Der Broker verteilt die Nachricht automatisch an alle relevanten Subscriber.		3. Der Broker verteilt die Nachricht automatisch an alle relevanten Subscriber.
	4. Die Subscriber verarbeiten die Nachricht unabhängig voneinander.		4. Die Subscriber verarbeiten die Nachricht unabhängig voneinander.
Zeile 47:		Zeile 47:

	=== Themenbasiert (Topic-based) ===		=== Themenbasiert (Topic-based) ===
	Subscriber abonnieren Nachrichten zu bestimmten Themen (Topics).		Subscriber abonnieren Nachrichten zu bestimmten ''Themen (Topics)''.
	Beispiel:		Beispiel:
	<syntaxhighlight lang="text">		<syntaxhighlight lang="text">
Zeile 56:		Zeile 56:

	=== Ereignisbasiert (Event-based) ===		=== Ereignisbasiert (Event-based) ===
	Nachrichten definieren spezifische Ereignisse, z. B.:		Nachrichten definieren ''spezifische Ereignisse'', z. B.:
	<syntaxhighlight lang="text">		<syntaxhighlight lang="text">
	Event: "Benutzer wurde erstellt"		Event: "Benutzer wurde erstellt"
Zeile 88:		Zeile 88:
	\| System \| Rolle \|		\| System \| Rolle \|
	\|-------\|-------\|		\|-------\|-------\|
	\| RabbitMQ \| Topic/Fanout Exchanges für Pub/Sub \|		\| ''RabbitMQ'' \| Topic/Fanout Exchanges für Pub/Sub \|
	\| Apache Kafka \| Verteilt Nachrichtenströme an Consumer-Gruppen \|		\| ''Apache Kafka'' \| Verteilt Nachrichtenströme an Consumer-Gruppen \|
	\| Redis Pub/Sub \| Leichtgewichtiges Pub/Sub-Modell in Infrastrukturanwendungen \|		\| ''Redis Pub/Sub'' \| Leichtgewichtiges Pub/Sub-Modell in Infrastrukturanwendungen \|
	\| WebSockets / Socket.IO \| Ereignisbasierte Kommunikation in Echtzeit-Anwendungen \|		\| ''WebSockets / Socket.IO'' \| Ereignisbasierte Kommunikation in Echtzeit-Anwendungen \|
	\| Cloud Pub/Sub (Google/AWS/Azure) \| Globale Messaging-Systeme für verteilte Microservices \|		\| ''Cloud Pub/Sub (Google/AWS/Azure)'' \| Globale Messaging-Systeme für verteilte Microservices \|

	== Vorteile ==		== Vorteile ==
	* Lose Kopplung zwischen Komponenten		* ''Lose Kopplung'' zwischen Komponenten
	* Hohe Skalierbarkeit durch parallele Verarbeitung		* ''Hohe Skalierbarkeit'' durch parallele Verarbeitung
	* Unterstützt verteilte und eventgesteuerte Architekturen		* ''Unterstützt verteilte und eventgesteuerte Architekturen''
	* Wiederverwendbarkeit und Erweiterbarkeit der Systemkomponenten		* ''Wiederverwendbarkeit und Erweiterbarkeit'' der Systemkomponenten

	== Nachteile ==		== Nachteile ==
	* Nachrichtenfluss nicht direkt nachvollziehbar (Debugging komplexer)		* ''Nachrichtenfluss nicht direkt nachvollziehbar'' (Debugging komplexer)
	* Keine garantierte Reihenfolge, wenn nicht explizit unterstützt		* ''Keine garantierte Reihenfolge'', wenn nicht explizit unterstützt
	* Fehlerhandling und Retry-Strategien müssen bewusst implementiert werden		* ''Fehlerhandling und Retry-Strategien'' müssen bewusst implementiert werden
	* Potenzielle Zustandsinkonsistenzen, wenn Ereignisse zeitlich variieren		* Potenzielle ''Zustandsinkonsistenzen'', wenn Ereignisse zeitlich variieren

	== Best Practices ==		== Best Practices ==
	* Nachrichten idempotent verarbeiten (Doppelausführung darf keine Fehler verursachen)		* Nachrichten ''idempotent'' verarbeiten (Doppelausführung darf keine Fehler verursachen)
	* Monitoring von Queues und Topics		* ''Monitoring von Queues und Topics''
	* Verwendung eines zentralen Event-Schemas bei verteilten Teams		* Verwendung eines ''zentralen Event-Schemas'' bei verteilten Teams
	* Klare Namenskonventionen für Topics/Ereignisse		* Klare ''Namenskonventionen'' für Topics/Ereignisse

	== Vergleich zu anderen Mustern ==		== Vergleich zu anderen Mustern ==
Zeile 124:		Zeile 124:

	== Zusammenfassung ==		== Zusammenfassung ==
	Das Publisher-Subscriber-Entwurfsmuster ermöglicht asynchrone, lose gekoppelte Kommunikation zwischen Softwarekomponenten.		Das Publisher-Subscriber-Entwurfsmuster ermöglicht ''asynchrone, lose gekoppelte Kommunikation'' zwischen Softwarekomponenten.
	Publisher senden Ereignisse ohne Wissen über Empfänger, während Subscriber flexibel Ereignisse abonnieren.		Publisher senden Ereignisse ohne Wissen über Empfänger, während Subscriber flexibel Ereignisse abonnieren.
	Es bildet das Fundament vieler eventgesteuerter, verteilter und skalierbarer Softwaresysteme.		Es bildet das Fundament vieler ''eventgesteuerter, verteilter und skalierbarer Softwaresysteme''.

	== Siehe auch ==		== Siehe auch ==

PhilKa: Die Seite wurde neu angelegt: „= Publisher-Subscriber-Entwurfsmuster = Das '''Publisher-Subscriber-Entwurfsmuster''' (kurz: '''Pub/Sub''') ist ein Verhaltens- und Integrationsmuster, das die asynchrone, lose gekoppelte Kommunikation zwischen Softwarekomponenten ermöglicht. Statt dass Sender (Publisher) Nachrichten direkt an Empfänger (Subscriber) senden, werden diese über eine vermittelnde Instanz (z. B. Message Broker oder Event-Bus) verteilt. == Ziel == Das Muster…“

2025-11-08T12:59:17Z

Die Seite wurde neu angelegt: „= Publisher-Subscriber-Entwurfsmuster = Das '''Publisher-Subscriber-Entwurfsmuster''' (kurz: '''Pub/Sub''') ist ein **Verhaltens- und Integrationsmuster**, das die **asynchrone, lose gekoppelte Kommunikation** zwischen Softwarekomponenten ermöglicht. Statt dass Sender (Publisher) Nachrichten direkt an Empfänger (Subscriber) senden, werden diese über eine **vermittelnde Instanz** (z. B. Message Broker oder Event-Bus) verteilt. == Ziel == Das Muster…“

Neue Seite

= Publisher-Subscriber-Entwurfsmuster =

Das '''Publisher-Subscriber-Entwurfsmuster''' (kurz: '''Pub/Sub''') ist ein **Verhaltens- und Integrationsmuster**, das die **asynchrone, lose gekoppelte Kommunikation** zwischen Softwarekomponenten ermöglicht.
Statt dass Sender (Publisher) Nachrichten direkt an Empfänger (Subscriber) senden, werden diese über eine **vermittelnde Instanz** (z. B. Message Broker oder Event-Bus) verteilt.

== Ziel ==
Das Muster soll:
* **Abhängigkeiten zwischen Sender und Empfänger vermeiden**
* **Asynchrone Kommunikationsabläufe ermöglichen**
* **Skalierbarkeit verbessern**
* **Flexibilität und Erweiterbarkeit des Systems erhöhen**
* **Ereignisgesteuerte Architekturen unterstützen**

== Grundprinzip ==
Komponenten, die Nachrichten senden möchten, veröffentlichen diese bei einem **Publisher** oder über einen **Message Broker**.
Komponenten, die Nachrichten empfangen möchten, registrieren sich (abonnieren) bei einem **Subscriber**-Interface oder beim Broker.
Der Publisher kennt die Subscriber **nicht** direkt.

=== Grafische Darstellung ===
<pre>
Publisher Subscriber
(Sendet Events) (Empfängt Events)
| ^
| |
v |
+--------- Message Broker --------+
</pre>

== Komponenten ==
{| class="wikitable"
! Komponente !! Rolle
|-
| **Publisher** || Erzeugt und veröffentlicht Nachrichten/Ereignisse.
|-
| **Subscriber** || Registriert sich für bestimmte Nachrichten und verarbeitet sie.
|-
| **Broker / Event Bus** || Vermittelt Nachrichten zwischen Publishern und Subscribern.
|}

== Ablauf ==
1. Der **Subscriber** meldet sich beim Broker für bestimmte Themen oder Ereignisse an.
2. Der **Publisher** sendet eine Nachricht an den Broker.
3. Der Broker verteilt die Nachricht automatisch an alle relevanten Subscriber.
4. Die Subscriber verarbeiten die Nachricht unabhängig voneinander.

== Themenbasierte vs. ereignisbasierte Varianten ==

=== Themenbasiert (Topic-based) ===
Subscriber abonnieren Nachrichten zu bestimmten **Themen (Topics)**.
Beispiel:
<syntaxhighlight lang="text">
topic = "sensor/temperatur"
</syntaxhighlight>

Alle Subscriber dieses Topics erhalten die Nachrichten.

=== Ereignisbasiert (Event-based) ===
Nachrichten definieren **spezifische Ereignisse**, z. B.:
<syntaxhighlight lang="text">
Event: "Benutzer wurde erstellt"
</syntaxhighlight>

Nur Subscriber dieses Ereignisses werden informiert.

== Beispiel in Python (vereinfachter Event-Bus) ==
<syntaxhighlight lang="python">
class EventBus:
def __init__(self):
self.subscribers = {}

def subscribe(self, event, callback):
self.subscribers.setdefault(event, []).append(callback)

def publish(self, event, data):
for callback in self.subscribers.get(event, []):
callback(data)

bus = EventBus()

def handler(msg):
print("Empfangen:", msg)

bus.subscribe("test_event", handler)
bus.publish("test_event", "Hallo Pub/Sub")
</syntaxhighlight>

== Beispiele in realen Systemen ==
| System | Rolle |
|-------|-------|
| **RabbitMQ** | Topic/Fanout Exchanges für Pub/Sub |
| **Apache Kafka** | Verteilt Nachrichtenströme an Consumer-Gruppen |
| **Redis Pub/Sub** | Leichtgewichtiges Pub/Sub-Modell in Infrastrukturanwendungen |
| **WebSockets / Socket.IO** | Ereignisbasierte Kommunikation in Echtzeit-Anwendungen |
| **Cloud Pub/Sub (Google/AWS/Azure)** | Globale Messaging-Systeme für verteilte Microservices |

== Vorteile ==
* **Lose Kopplung** zwischen Komponenten
* **Hohe Skalierbarkeit** durch parallele Verarbeitung
* **Unterstützt verteilte und eventgesteuerte Architekturen**
* **Wiederverwendbarkeit und Erweiterbarkeit** der Systemkomponenten

== Nachteile ==
* **Nachrichtenfluss nicht direkt nachvollziehbar** (Debugging komplexer)
* **Keine garantierte Reihenfolge**, wenn nicht explizit unterstützt
* **Fehlerhandling und Retry-Strategien** müssen bewusst implementiert werden
* Potenzielle **Zustandsinkonsistenzen**, wenn Ereignisse zeitlich variieren

== Best Practices ==
* Nachrichten **idempotent** verarbeiten (Doppelausführung darf keine Fehler verursachen)
* **Monitoring von Queues und Topics**
* Verwendung eines **zentralen Event-Schemas** bei verteilten Teams
* Klare **Namenskonventionen** für Topics/Ereignisse

== Vergleich zu anderen Mustern ==
{| class="wikitable"
! Muster !! Vergleichspunkt !! Unterschied
|-
| Pub/Sub || Kommunikation || Asynchron und entkoppelt
|-
| Observer || Kommunikation || Direkte Objektbeziehung ohne Broker
|-
| Competing Consumer || Verarbeitung || Mehrere Consumer teilen sich eine Queue (Lastverteilung), aber ohne Broadcast an mehrere Empfänger
|}

== Zusammenfassung ==
Das Publisher-Subscriber-Entwurfsmuster ermöglicht **asynchrone, lose gekoppelte Kommunikation** zwischen Softwarekomponenten.
Publisher senden Ereignisse ohne Wissen über Empfänger, während Subscriber flexibel Ereignisse abonnieren.
Es bildet das Fundament vieler **eventgesteuerter, verteilter und skalierbarer Softwaresysteme**.

== Siehe auch ==
* [[Competing-Consumer-Entwurfsmuster]]
* [[Mediator-Entwurfsmuster]]
* [[Event-Driven Architecture]]
* [[RabbitMQ]]
* [[Apache Kafka]]

== Weblinks ==
* https://www.enterpriseintegrationpatterns.com/
* https://refactoring.guru/design-patterns/publisher-subscriber
* https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern