Redis Streams als persistentes Message-Log einsetzen

1. Warum Streams eine eigene Datenstruktur brauchen

Redis Streams, eingefuehrt in Redis 5.0, loesen ein Problem, das weder Listen noch Pub/Sub allein zufriedenstellend abdecken konnten: ein append-only Log von Ereignissen, das mehrere unabhaengige Konsumenten gleichzeitig lesen koennen, wobei jeder Konsument seinen eigenen Lesefortschritt verfolgt, und das Nachrichten nicht verliert, selbst wenn ein Konsument zum Zeitpunkt des Schreibens offline ist. Eine Liste kann zwar als Queue dienen, aber sobald ein Element mit LPOP entnommen wird, ist es fuer alle anderen Konsumenten verloren. Pub/Sub liefert Nachrichten nur an aktuell verbundene Subscriber und speichert nichts, ein Nachzuegler verpasst alles, was waehrend seiner Abwesenheit gesendet wurde.

Ein Redis Stream ist im Kern ein append-only Log, in dem jeder Eintrag eine eindeutige, monoton steigende ID erhaelt, typischerweise aus Timestamp und Sequenznummer zusammengesetzt. Diese ID fungiert als Cursor: Ein Konsument kann jederzeit angeben, ab welcher ID er weiterlesen moechte, und verpasst dadurch keine Nachricht, egal wie lange er offline war, solange der Stream nicht durch Trimming bereinigt wurde. Diese Eigenschaft macht Streams zur Grundlage fuer Event-Sourcing-Muster, Aktivitaets-Feeds und Message-Queues mit garantierter Zustellung.

Dieser Beitrag geht die zentralen Stream-Commands durch, erklaert Consumer Groups fuer verteilte Verarbeitung im Detail, und ordnet Streams gegenueber den beiden nahliegenden Alternativen Pub/Sub und Kafka ein, um eine fundierte Entscheidung fuer den jeweiligen Anwendungsfall zu ermoeglichen.

Wer bereits mit anderen Redis-Datentypen wie Listen oder Sorted Sets vertraut ist, wird bei Streams ein neues, eigenstaendiges Konzept vorfinden, das speziell fuer Messaging-Anwendungsfaelle entwickelt wurde, statt eine Erweiterung eines bestehenden Datentyps zu sein.

Intern implementiert Redis einen Stream als radix tree, optimiert fuer schnelle Bereichsabfragen nach ID und effizientes Anhaengen neuer Eintraege am Ende. Diese Datenstruktur unterscheidet sich fundamental von den bisher besprochenen Redis-Datentypen wie Listen oder Sets und wurde gezielt fuer das Anwendungsmuster "viele Schreibvorgaenge, mehrere unabhaengige Leser mit unterschiedlichem Fortschritt" entworfen.

2. XADD und die Stream-ID im Detail

XADD key * field1 value1 field2 value2 fuegt einen neuen Eintrag zum Stream hinzu. Das Sternchen * weist Redis an, automatisch eine neue ID zu generieren, bestehend aus der aktuellen Millisekunden-Zeit und einer Sequenznummer, die bei mehreren Eintraegen innerhalb derselben Millisekunde hochgezaehlt wird, etwa 1721742001234-0. Diese automatische ID-Generierung garantiert, dass IDs innerhalb eines Streams immer streng monoton steigen, was fuer die spaetere Bereichsabfrage entscheidend ist.

Jeder Eintrag besteht aus einer Menge von Feld-Wert-Paaren, aehnlich einem Hash, wodurch ein Eintrag mehrere strukturierte Datenfelder tragen kann, statt nur einen einzelnen String-Wert wie bei einer Liste. Das eignet sich hervorragend fuer Ereignisdaten wie event_type, user_id und payload in einem einzigen atomaren Eintrag. Mit XLEN key laesst sich die aktuelle Anzahl Eintraege abfragen, mit XRANGE key start end ein Bereich nach ID abrufen, wobei die Spezialwerte - und + fuer den Anfang beziehungsweise das Ende des Streams stehen.

Eine explizite ID statt * anzugeben ist ebenfalls moeglich und in verteilten Systemen relevant, etwa wenn eine ID aus einer externen Quelle uebernommen werden soll. Redis erzwingt dabei, dass jede neue ID strikt groesser als die zuletzt vergebene sein muss, ein Versuch, eine kleinere oder gleiche ID einzufuegen, schlaegt mit einem Fehler fehl. Diese Garantie ist die Grundlage dafuer, dass Bereichsabfragen und Cursor-basiertes Lesen zuverlaessig funktionieren, ohne dass die Anwendung selbst auf Sortierung achten muss.

# Streams: appending structured events with auto-generated IDs
redis-cli XADD orders:events "*" event_type "created" order_id "5001" amount "129.90"
redis-cli XADD orders:events "*" event_type "paid" order_id "5001" amount "129.90"
redis-cli XLEN orders:events
redis-cli XRANGE orders:events - + COUNT 10
redis-cli XREVRANGE orders:events + - COUNT 1

3. XREAD: einfaches Lesen und Live-Tailing

XREAD COUNT n STREAMS key id liest Eintraege ab einer bestimmten ID, exklusiv, das heisst der Eintrag mit genau dieser ID wird nicht mehr zurueckgegeben, nur alles danach. Mit der ID 0 liest man den kompletten Stream von Anfang an, mit $ nur Eintraege, die nach dem Zeitpunkt des Aufrufs hinzugefuegt werden, praktisch fuer Live-Tailing aehnlich einem tail -f auf einer Logdatei.

Mit der Option BLOCK milliseconds wartet XREAD, bis neue Eintraege verfuegbar sind, statt sofort mit einem leeren Ergebnis zurueckzukehren. Diese blockierende Variante ersetzt Polling-Schleifen und ist die Grundlage fuer einfache Consumer-Implementierungen ohne Consumer Group, bei denen ein einzelner Prozess den kompletten Stream liest, etwa fuer ein Monitoring-Dashboard, das jedes Ereignis in Echtzeit anzeigen soll, ohne dass mehrere Konsumenten sich die Arbeit teilen muessen.

Ein wichtiger Unterschied zu Consumer Groups: Bei einfachem XREAD muss die Anwendung selbst Buch fuehren, welche ID zuletzt gelesen wurde, etwa in einer eigenen Variable oder einem separaten Redis-Key. Redis speichert bei dieser einfachen Lesevariante keinen serverseitigen Fortschritt, im Gegensatz zu Consumer Groups, die ihren Lesefortschritt automatisch verwalten. Fuer einen einzelnen, dauerhaft laufenden Konsumenten ist das meist kein Problem, fuer mehrere unabhaengige Konsumenten mit persistentem Fortschritt sind Consumer Groups die robustere Wahl.

XREAD kann zudem mehrere Streams gleichzeitig in einem einzigen Aufruf abfragen, indem mehrere Schluessel-ID-Paare nach STREAMS aufgelistet werden. Das ist praktisch, wenn eine Anwendung mehrere thematisch getrennte Event-Logs gleichzeitig ueberwachen muss, etwa Bestellungen und Zahlungen als separate Streams, aber dennoch mit einer einzigen blockierenden Abfrage auf neue Ereignisse in beiden warten moechte.

# XREAD: live tailing without a consumer group
redis-cli XREAD COUNT 10 STREAMS orders:events 0
redis-cli XREAD BLOCK 5000 STREAMS orders:events "$"
redis-cli XREAD COUNT 5 STREAMS orders:events 1721742001234-0

4. Consumer Groups: verteilte Verarbeitung mit XREADGROUP

Waehrend XREAD fuer einzelne, unabhaengige Konsumenten geeignet ist, loesen Consumer Groups das Problem der verteilten Verarbeitung: Mehrere Worker sollen sich die Eintraege eines Streams teilen, sodass jeder Eintrag von genau einem Worker innerhalb der Gruppe verarbeitet wird, aehnlich wie bei einer klassischen Message-Queue. Mit XGROUP CREATE key groupname id wird eine Consumer Group erstellt, die ihren eigenen, von individuellen Konsumenten unabhaengigen Lesefortschritt verfolgt.

XREADGROUP GROUP groupname consumername COUNT n STREAMS key > liest neue, bisher noch nicht an diese Gruppe zugestellte Eintraege und markiert sie automatisch als "pending" fuer den anfragenden Konsumenten. Das Sonderzeichen > bedeutet "nur neue Eintraege, die noch nie an diese Gruppe zugestellt wurden". Mehrere Worker, die alle mit demselben Groupname, aber unterschiedlichem Consumername lesen, teilen sich so automatisch die Eintraege eines Streams, ohne dass Koordinationslogik in der Anwendung noetig waere, Redis uebernimmt die Verteilung.

Ein zentraler Unterschied zu einer einfachen Liste als Queue: Wird ein Eintrag per XREADGROUP an einen Konsumenten zugestellt, verschwindet er nicht aus dem Stream, sondern wird lediglich in der Pending Entries List der Gruppe als "in Bearbeitung" markiert. Erst ein explizites XACK entfernt ihn aus dieser Liste. Stuerzt ein Worker waehrend der Verarbeitung ab, bleibt der Eintrag in der Pending-Liste sichtbar und kann von einem anderen Worker uebernommen werden, ein entscheidender Vorteil fuer zuverlaessige Verarbeitung.

Mit XGROUP CREATECONSUMER und XGROUP DELCONSUMER laesst sich die Menge der aktiven Konsumenten innerhalb einer Gruppe dynamisch verwalten, etwa wenn Worker in einer Auto-Scaling-Umgebung hinzukommen oder entfernt werden. XINFO CONSUMERS key group zeigt alle bekannten Konsumenten einer Gruppe samt Anzahl unbestaetigter Eintraege, was fuer Monitoring und Kapazitaetsplanung in produktiven Systemen wertvoll ist.

# Consumer groups: distributed processing across multiple workers
redis-cli XGROUP CREATE orders:events order-processors "$"
redis-cli XREADGROUP GROUP order-processors worker-1 COUNT 5 STREAMS orders:events ">"
redis-cli XREADGROUP GROUP order-processors worker-2 COUNT 5 STREAMS orders:events ">"
redis-cli XPENDING orders:events order-processors
redis-cli XINFO GROUPS orders:events

5. XACK und Pending Entries List: zuverlaessige Zustellung

XACK key group id bestaetigt die erfolgreiche Verarbeitung eines Eintrags und entfernt ihn aus der Pending Entries List der Gruppe. Dieser explizite Bestaetigungsschritt ist der Kern des "at least once"-Zustellungsmodells von Streams: Ein Eintrag gilt erst dann als vollstaendig verarbeitet, wenn der Konsument aktiv bestaetigt, dass die Verarbeitung erfolgreich abgeschlossen wurde. Ohne XACK bleibt der Eintrag in der Pending-Liste, selbst wenn der Konsument laengst mit dem naechsten Eintrag weitermacht.

Fuer den Umgang mit abgestuerzten Workern bietet XCLAIM beziehungsweise das komfortablere XAUTOCLAIM die Moeglichkeit, Eintraege, die laenger als eine definierte Zeit in der Pending-Liste eines anderen Konsumenten haengen, zu uebernehmen und selbst zu verarbeiten. Das ist die Grundlage fuer Timeout-basierte Wiederholungslogik: Ein Watchdog-Prozess prueft periodisch mit XPENDING, welche Eintraege laenger als etwa 30 Sekunden unbestaetigt sind, und uebernimmt sie mit XAUTOCLAIM fuer einen erneuten Verarbeitungsversuch.

Der Parameter min-idle-time bei XCLAIM und XAUTOCLAIM verhindert, dass ein Eintrag vorzeitig uebernommen wird, waehrend der urspruengliche Worker ihn moeglicherweise noch aktiv bearbeitet. Erst wenn ein Eintrag laenger als diese Schwelle ohne Bestaetigung in der Pending-Liste verharrt, gilt er als moeglicherweise verwaist und darf von einem anderen Konsumenten uebernommen werden, was verhindert, dass langsame, aber funktionierende Verarbeitung faelschlich als abgestuerzt behandelt wird.

Dieses Zusammenspiel aus XREADGROUP, XACK und XAUTOCLAIM bildet ein vollstaendiges, zuverlaessiges Zustellungsmodell direkt in Redis, ohne dass eine externe Message-Queue-Infrastruktur wie RabbitMQ oder Kafka betrieben werden muss, solange der Durchsatz und die Aufbewahrungsanforderungen im Rahmen dessen bleiben, was eine einzelne Redis-Instanz oder ein Redis-Cluster leisten kann.

Fuer dauerhaft nicht verarbeitbare Eintraege, etwa weil die Payload fehlerhaft ist und jeder Verarbeitungsversuch fehlschlaegt, empfiehlt sich ein Dead-Letter-Muster: Ein Watchdog-Prozess zaehlt ueber das XPENDING-Feld die Anzahl der Zustellversuche, und verschiebt Eintraege, die eine definierte Grenze ueberschreiten, in einen separaten Fehler-Stream statt sie endlos erneut zu versuchen. Das verhindert, dass ein einzelner defekter Eintrag die Verarbeitung des gesamten Streams blockiert.

# XACK and recovering stuck entries after a worker crash
redis-cli XACK orders:events order-processors 1721742001234-0
redis-cli XPENDING orders:events order-processors - + 10
redis-cli XAUTOCLAIM orders:events order-processors worker-2 30000 0
redis-cli XACK orders:events order-processors 1721742002456-0

6. Streams vs. Pub/Sub: der entscheidende Unterschied

Redis Pub/Sub, mit PUBLISH und SUBSCRIBE, ist ein reines Fire-and-Forget-Broadcastsystem: Eine Nachricht wird an alle aktuell verbundenen Subscriber eines Kanals gesendet und danach nicht mehr gespeichert. Ist ein Subscriber zum Zeitpunkt des PUBLISH nicht verbunden, verpasst er die Nachricht unwiderruflich, es gibt keine Historie, keinen Cursor und keine Moeglichkeit, verpasste Nachrichten nachzuholen. Das macht Pub/Sub geeignet fuer Anwendungsfaelle, bei denen Verlust tolerierbar ist, etwa Live-Benachrichtigungen in einer aktiven Benutzeroberflaeche.

Streams loesen genau dieses Problem: Jede Nachricht bleibt im Stream gespeichert, bis sie explizit getrimmt wird, und jeder Konsument, ob mit einfachem XREAD oder ueber eine Consumer Group, kann jederzeit ab einer beliebigen historischen Position weiterlesen. Diese Persistenz macht Streams geeignet fuer Anwendungsfaelle, bei denen kein Ereignis verloren gehen darf, etwa Bestellstatusaenderungen, Audit-Logs oder Event-Sourcing, bei dem der komplette Verlauf eines Aggregats aus seinen Ereignissen rekonstruierbar sein muss.

In der Praxis lassen sich Pub/Sub und Streams auch kombinieren: Pub/Sub fuer die latenzarme Live-Benachrichtigung aktiver Clients, etwa um eine offene Weboberflaeche sofort zu aktualisieren, und parallel ein Stream fuer die zuverlaessige, nachholbare Verarbeitung im Hintergrund. Diese Kombination nutzt die jeweiligen Staerken, statt eine einzelne Technologie fuer beide sehr unterschiedlichen Anforderungen zu erzwingen.

7. Streams als Kafka-lite: wo die Grenze liegt

Die Kombination aus Consumer Groups, persistenten Eintraegen und expliziter Bestaetigung erinnert bewusst an Kafka, und tatsaechlich werden Redis Streams haeufig als leichtgewichtige Kafka-Alternative fuer mittlere Durchsatzanforderungen eingesetzt. Fuer Teams, die bereits Redis im Einsatz haben und keine dedizierte Kafka-Infrastruktur mit Zookeeper oder KRaft, Partitionierung und Replikations-Konfiguration betreiben moechten, bieten Streams einen erheblich geringeren operativen Aufwand bei vergleichbarer Grundfunktionalitaet.

Die Grenzen zeigen sich bei sehr hohem Durchsatz und langer Aufbewahrung: Kafka ist fuer Partitionierung ueber viele Broker und persistente Logs im Terabyte-Bereich konzipiert, waehrend ein Redis Stream durch den verfuegbaren Arbeitsspeicher der Redis-Instanz begrenzt ist, sofern nicht mit Trimming gearbeitet wird. Auch die Ordnungsgarantien unterscheiden sich: Kafka garantiert Reihenfolge nur innerhalb einer Partition, waehrend ein einzelner Redis Stream eine globale, strikt monotone Reihenfolge aller Eintraege bietet, was fuer viele Anwendungsfaelle einfacher zu handhaben, bei sehr hohem Durchsatz aber schwerer horizontal zu skalieren ist.

Auch beim Replay-Verhalten unterscheiden sich beide Systeme: Kafka-Consumer koennen einen Offset beliebig zuruecksetzen und ganze Partitionen erneut verarbeiten, ein etabliertes Muster fuer Backfills nach einem Bugfix. Redis Streams unterstuetzen dasselbe Prinzip ueber XREADGROUP mit einer expliziten ID statt >, allerdings ohne die ausgereiften Tooling- und Offset-Management-Funktionen, die im Kafka-Oekosystem ueber Jahre gewachsen sind.

Fuer Systeme mit Millionen Ereignissen pro Sekunde, langfristiger Aufbewahrung ueber Monate oder Jahre, oder komplexer Stream-Processing-Topologie mit mehreren nachgelagerten Transformationsschritten bleibt Kafka die robustere Wahl. Fuer Event-Logs mittlerer Groessenordnung, typischerweise bis zu einigen tausend Ereignissen pro Sekunde mit Aufbewahrung im Bereich von Stunden bis wenigen Tagen, sind Redis Streams eine pragmatische, deutlich einfacher zu betreibende Alternative.

Ein oft entscheidender praktischer Faktor bei der Wahl ist das bereits vorhandene Betriebs-Know-how im Team: Wer bereits Redis fuer Caching und Sessions betreibt, kann Streams ohne neue Infrastruktur, neue Monitoring-Tools oder neues operatives Wissen einfuehren. Der Umstieg auf Kafka bedeutet dagegen fast immer, ein komplett neues System mit eigenen Betriebsanforderungen, Backup-Strategien und Skalierungsmustern zu erlernen und zu betreiben.

8. Speicherverwaltung: XTRIM und MAXLEN

Da ein Stream standardmaessig unbegrenzt waechst, ist aktives Speichermanagement Pflicht fuer den produktiven Einsatz. XTRIM key MAXLEN n begrenzt den Stream auf die letzten n Eintraege und entfernt aeltere Eintraege. Alternativ laesst sich MAXLEN direkt bei XADD angeben, etwa XADD key MAXLEN 10000 * field value, wodurch der Stream bei jedem Schreibvorgang automatisch auf die konfigurierte Maximallaenge zurechtgestutzt wird, ohne einen separaten Trimming-Prozess zu benoetigen.

Fuer praezisere Kontrolle bietet XTRIM key MINID id die Moeglichkeit, alle Eintraege vor einer bestimmten ID zu entfernen, etwa alles aelter als 24 Stunden, was fuer zeitbasierte Aufbewahrungsrichtlinien praktischer ist als eine reine Laengenbegrenzung. Wichtig zu beachten: Trimming entfernt Eintraege unabhaengig davon, ob sie bereits von allen Consumer Groups verarbeitet wurden. Wer garantieren muss, dass kein Eintrag vor vollstaendiger Verarbeitung entfernt wird, sollte das Aufbewahrungsfenster grosszuegig genug gegenueber der erwarteten maximalen Verarbeitungsverzoegerung waehlen.

Der Zusatz ~ vor der Laengenangabe, etwa XADD key MAXLEN ~ 10000 * field value, weist Redis an, ein approximatives statt exaktes Trimming durchzufuehren. Redis entfernt dabei ganze interne Knoten der zugrunde liegenden Datenstruktur, statt bei jedem einzelnen Schreibvorgang exakt auf die Ziellaenge zu trimmen, was den CPU-Aufwand fuer Trimming bei sehr hoher Schreibfrequenz erheblich senkt, auf Kosten einer leicht ungenauen, aber immer nach oben abweichenden tatsaechlichen Streamlaenge.

# Memory management: bounding stream growth with trimming
redis-cli XADD orders:events MAXLEN "~" 10000 "*" event_type "shipped" order_id "5001"
redis-cli XTRIM orders:events MAXLEN 5000
redis-cli XTRIM orders:events MINID 1721742000000-0
redis-cli XLEN orders:events

9. Streams im Vergleich zu Listen und Pub/Sub

Die folgende Tabelle stellt Streams den beiden naheliegenden Alternativen Liste und Pub/Sub fuer Queue- und Messaging-Anwendungsfaelle gegenueber.

Streams vereinen die Staerken von Liste und Pub/Sub: Persistenz wie bei einer Liste, aber mit mehreren unabhaengigen Lesern wie bei Pub/Sub, ergaenzt um Consumer Groups fuer verteilte Verarbeitung und explizite Zustellungsgarantien, die weder Liste noch Pub/Sub allein bieten koennen.

Fuer neue Projekte, die eine Queue oder ein Event-Log benoetigen und bereits Redis im Einsatz haben, ist ein Stream fast immer die richtige Ausgangswahl gegenueber einer Liste als improvisierter Queue. Nur bei sehr einfachen Fire-and-Forget-Benachrichtigungen ohne jeden Anspruch auf Zustellungsgarantie bleibt Pub/Sub wegen seiner geringeren Latenz und Einfachheit die passendere Wahl.

10. Zusammenfassung

Redis Streams loesen das Problem eines persistenten, mehrfach lesbaren Message-Logs direkt in Redis. XADD fuegt Eintraege mit automatisch generierten, monoton steigenden IDs hinzu. XREAD eignet sich fuer einfaches, unabhaengiges Lesen, waehrend Consumer Groups mit XREADGROUP, XACK und XAUTOCLAIM verteilte Verarbeitung mit Zustellungsgarantie ermoeglichen, inklusive Wiederherstellung nach Worker-Absturz ueber die Pending Entries List.

Gegenueber Pub/Sub gewinnen Streams durch Persistenz und Nachhol-Faehigkeit, gegenueber einer einfachen Liste durch mehrere unabhaengige Konsumenten mit eigenem Cursor. Gegenueber Kafka bleiben Streams die leichtgewichtigere Wahl fuer Event-Logs mittlerer Groessenordnung, waehrend Kafka bei sehr hohem Durchsatz und langfristiger Aufbewahrung im Terabyte-Bereich die robustere Infrastruktur bleibt. XTRIM mit MAXLEN oder MINID haelt den Speicherbedarf eines Streams im produktiven Betrieb unter Kontrolle.

Wer bereits Redis fuer Caching oder Sessions im Einsatz hat, sollte Streams als naheliegende erste Option fuer neue Queue- und Event-Log-Anforderungen pruefen, bevor eine zusaetzliche, separat zu betreibende Message-Queue-Infrastruktur eingefuehrt wird. Der geringere operative Aufwand bei vergleichbarer Grundfunktionalitaet macht Streams zu einem der unterschaetztesten Features von Redis.

11. FAQ: Redis Streams als Message-Log