Was sind Redis Streams?

Question

Accepted Answer

**Redis Streams** sind eine append-only Log-Datenstruktur – ähnlich einer dauerhaften Message Queue oder einem Event Log – mit Unterstützung für **Consumer Groups**, Message-Persistierung, Acknowledgments und Replay. Sie sind Redís Antwort auf zuverlässiges Messaging und robuster als Pub/Sub (das fire-and-forget ist).

## Append-only Log von Nachrichten

```bash
# add entries to a stream (each gets an auto ID: timestamp-sequence)
XADD events * type "signup" user "ann"     # * = auto-generate ID; returns e.g. 1700000000-0
XADD events * type "login" user "bob"

XLEN events                                 # number of entries
XRANGE events - +                           # read all entries (- to +)
XREAD COUNT 10 STREAMS events 0             # read entries (from ID 0)
```

Streams sind ein **append-only Log**: Einträge werden mit `XADD` hinzugefügt (jeder mit einer eindeutigen, zeitgeordneten ID) und bleiben im Stream erhalten – im Gegensatz zu Pub/Sub, wo Nachrichten nicht verloren gehen, sondern gespeichert werden und erneut gelesen werden können.

## Consumer Groups – zuverlässige, skalierbare Verarbeitung

```bash
# create a consumer group to process the stream
XGROUP CREATE events workers 0

# consumers read messages (each message goes to ONE consumer in the group)
XREADGROUP GROUP workers consumer1 COUNT 1 STREAMS events >

# acknowledge a processed message (so it's not redelivered)
XACK events workers 1700000000-0
# unacknowledged messages can be reclaimed (XPENDING/XCLAIM) → no message lost on crash
```

**Consumer Groups** verteilen Nachrichten auf mehrere Consumer (skalieren die Verarbeitung), wobei jede Nachricht an einen Consumer geht, **Acknowledgments** (`XACK`) die Verarbeitung bestätigen, und **Pending/Reclaim** (`XPENDING`/`XCLAIM`) sicherstellen, dass Nachrichten nicht verloren gehen, wenn ein Consumer abstürzt – zuverlässige, mindestens einmalige Zustellung.

## Streams vs Pub/Sub

```text
PUB/SUB  → fire-and-forget; offline subscribers MISS messages; no persistence/replay
STREAMS  → PERSISTENT log; messages stored; consumer groups; acknowledgments; replay
  → Streams = when you need RELIABLE delivery, message history, and scalable consumers
  → Pub/Sub = simple real-time broadcast where missing messages is OK
Streams are similar to a lightweight Kafka (log + consumer groups).
```

## Warum es wichtig ist

Das Verständnis von Redis Streams ist wertvoll für **zuverlässiges Messaging und Event-Verarbeitung** innerhalb von Redis, daher ist es nützliches Wissen – besonders, weil Streams die Schlüsselbegrenzungen von Pub/Sub ansprechen.

Während Pub/Sub einfach, aber fire-and-forget ist (offline Subscriber verlieren Nachrichten permanent, keine Persistierung), bieten **Streams zuverlässiges Messaging**: ein **append-only persistentes Log**, in dem Nachrichten gespeichert werden (nicht verloren) und erneut gelesen/wiedergegeben werden können, plus **Consumer Groups**, die Nachrichten auf mehrere Consumer verteilen für skalierbare Verarbeitung, **Acknowledgments** (`XACK`) zur Bestätigung der Verarbeitung, und **Reclaim von ausstehenden Nachrichten** (`XPENDING`/`XCLAIM`), damit Nachrichten nicht verloren gehen, wenn ein Consumer abstürzt – und so mindestens einmalige, zuverlässige, skalierbare Message-Verarbeitung ermöglichen.

Das Verständnis von **Streams vs Pub/Sub** (Streams für zuverlässige Zustellung, History und skalierbare Consumer; Pub/Sub für einfachen Echtzeit-Broadcast, bei dem Verlust akzeptabel ist) ist wichtig, um die richtige Redis-Messaging-Primitive auszuwählen.

Das Erkennen, dass Streams **ähnlich einem leichtgewichtigen Kafka** sind (Log-basiert mit Consumer Groups), hilft, ihre Rolle einzuordnen – sie bieten Event-Streaming-/Message-Queue-Fähigkeiten innerhalb von Redis ohne einen separaten Broker für moderate Anforderungen, während dedizierte Broker (Kafka, RabbitMQ) für größere oder anspruchsvollere Messaging-Szenarien geeignet bleiben.

Da zuverlässiges Messaging und Event-Verarbeitung häufige Anforderungen sind und Streams eine robuste, persistente, Consumer-Group-basierte Lösung bieten (die fire-and-forget-Limitation von Pub/Sub überwinden) innerhalb von Redis, ist das Verständnis von Redis Streams – das append-only Log, Consumer Groups mit Acknowledgments und Reclaim, und wie sie sich zu Pub/Sub und Kafka verhalten – wertvolles, praktisch relevantes Wissen für den Aufbau zuverlässiger Messaging- und Event-getriebener Funktionen mit Redis, die richtige Wahl, wenn Sie Zustellungsgarantien und Message-History benötigen, die Pub/Sub nicht bieten kann.