Wie funktioniert Redis Pub/Sub?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) ist Rediss Messaging-Pattern, bei dem **Publisher** Nachrichten an **Channels** senden und **Subscriber** Nachrichten von Channels empfangen, denen sie abonniert haben — ohne dass Publisher und Subscriber voneinander wissen. Es ermöglicht Echtzeit-Messaging und entkoppelte Kommunikation zwischen Services.

## Das Pub/Sub-Modell

```bash
# Subscriber listens on a channel
SUBSCRIBE news                    # subscribe to the "news" channel

# Publisher sends a message to the channel (in another connection)
PUBLISH news "Breaking story!"    # all subscribers to "news" receive this instantly

# Pattern subscriptions (wildcards)
PSUBSCRIBE news.*                 # subscribe to news.sports, news.tech, etc.
```

Publisher `PUBLISH` an einen Channel; Subscriber `SUBSCRIBE` zu Channels und erhalten Nachrichten in Echtzeit. Sie sind **entkoppelt** — der Publisher weiß nicht, wer (falls jemand) zuhört.

## Anwendungsfälle

```text
✓ REAL-TIME notifications — push events to interested services/clients instantly
✓ Chat / messaging — broadcast messages to subscribers
✓ Live updates — dashboards, feeds, multiplayer (broadcast state changes)
✓ Decoupling services — services communicate via channels without direct coupling
✓ Often paired with WebSockets (Redis pub/sub → server → WebSocket → browser)
```

## Wichtige Limitation: Fire-and-Forget

```text
⚠️ Redis Pub/Sub is FIRE-AND-FORGET (at-most-once delivery):
  → Messages are delivered ONLY to subscribers connected AT THAT MOMENT.
  → If a subscriber is offline/disconnected, it MISSES the message (no storage/replay).
  → No persistence, no acknowledgment, no delivery guarantee.
→ NOT suitable when you need reliable delivery or message history.
```

## Wenn Sie Zuverlässigkeit benötigen: Streams verwenden

```text
For RELIABLE messaging (persistence, replay, consumer groups, acknowledgments):
  → use Redis STREAMS (a durable, log-based structure) instead of Pub/Sub
  → or a dedicated message broker (Kafka, RabbitMQ)
Pub/Sub → simple real-time broadcast where missing messages is acceptable
Streams → when you need durability and delivery guarantees
```

## Warum es wichtig ist

Redis Pub/Sub zu verstehen ist wertvoll für **Echtzeit-Messaging und entkoppelte Kommunikation**, daher ist es nützliches Wissen — aber kritisch ist gleichermaßen wichtig, seine Limitationen zu verstehen, um es angemessen einzusetzen.

Pub/Sub ermöglicht **Echtzeit-Messaging**, bei dem Publisher an Channels broadcasten und Subscriber Nachrichten sofort erhalten, wobei Publisher und Subscriber **entkoppelt** sind (voneinander unabhängig) — was Anwendungsfälle wie Echtzeit-Benachrichtigungen, Chat, Live-Dashboard-Updates und entkoppelte Service-Kommunikation ermöglicht (oft gekoppelt mit WebSockets zum Pushen von Updates an Browser).

Dies macht Redis zu einer einfachen, schnellen Option für Echtzeit-Broadcast-Funktionen.

Aber der **wichtigste Punkt** ist das Verständnis der **Fire-and-Forget-Limitation von Pub/Sub**: es ist At-Most-Once-Delivery — Nachrichten erreichen nur Subscriber, die in diesem Moment verbunden sind, und Offline-Subscriber **verpassen Nachrichten permanent** (keine Persistenz, kein Replay, keine Bestätigung oder Liefergarantie).

Dies ist eine entscheidende Einschränkung: Pub/Sub ist ungeeignet, wenn zuverlässige Lieferung oder Message-Verlauf wichtig ist, und das Nicht-Verstehen dieser Limitation führt zu Lost-Message-Bugs.

Die Alternativen zu kennen — **Redis Streams** (dauerhaft, log-basiert, mit Consumer-Gruppen und Bestätigungen) oder dedizierte Broker (Kafka, RabbitMQ) für zuverlässiges Messaging — und Pub/Sub nur für einfache Echtzeit-Broadcasts zu wählen, wo verlorene Nachrichten akzeptabel sind, zeigt fundiertes Urteilsvermögen.

Da Echtzeit-Messaging ein häufiges Bedürfnis ist und Redis Pub/Sub eine einfache Lösung dafür bietet, aber mit wichtigen Zuverlässigkeitslimitationen (Streams oder ein Broker erforderlich, wenn Garantien nötig sind), ist das Verstehen von Pub/Sub — wie es funktioniert, seine Anwendungsfälle und besonders seine Fire-and-Forget-Limitation und wann Streams stattdessen verwendet werden sollten — wertvolles, praktisch relevantes Wissen für die korrekte Implementierung von Echtzeit-Funktionen, wobei das Verständnis der Limitation genauso wichtig ist wie das Verständnis der Fähigkeit.