Redis Streams er en append-only log-datastruktur — som en holdbar message queue eller event log — der understøtter consumer groups, message-persistering, acknowledgments og replay. De er Rediss svar på pålidelig messaging, mere robust end Pub/Sub (som er fire-and-forget).
XADD events * user
XADD events * user
XLEN events
XRANGE events - +
XREAD COUNT 10 STREAMS events 0
Streams er en append-only log: poster tilføjes med XADD (hver med et unikt, tidsordnet ID) og persisteres i streamen — modsat Pub/Sub, hvor beskeder ikke går tabt; de bliver gemt og kan læses igen.
# 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 distribuerer beskeder på tværs af flere consumers (skalering af behandling), hvor hver besked går til én consumer, acknowledgments (XACK) bekræfter behandling, og pending/reclaim (XPENDING/XCLAIM) sikrer, at beskeder ikke går tabt, hvis en consumer går ned — pålidelig, at-least-once delivery.
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).
At forstå Redis Streams er værdifuldt for pålidelig messaging og event processing inden for Redis, så det er nyttig viden — især fordi Streams addresserer de vigtigste begrænsninger ved Pub/Sub.
Mens Pub/Sub er simpel men fire-and-forget (offline subscribers mister permanent beskeder, ingen persistering), giver Streams pålidelig messaging: en append-only persistent log, hvor beskeder bliver gemt (ikke tabt) og kan læses igen/afspilles, plus consumer groups, der distribuerer beskeder på tværs af flere consumers for skalérbar behandling, acknowledgments (XACK) til at bekræfte behandling, og pending-message reclaim (XPENDING/XCLAIM), så beskeder ikke går tabt, når en consumer går ned — levering af at-least-once, pålidelig, skalérbar message processing.
At forstå Streams vs Pub/Sub (Streams til pålidelig levering, historie og skalérbare consumers; Pub/Sub til simpel real-time broadcast, hvor tab er acceptabelt) er vigtig for at vælge den rigtige Redis messaging primitive.
At genkende, at Streams er svarende til en lightweight Kafka (log-baseret med consumer groups) hjælper med at indramme deres rolle — at levere event-streaming/message-queue funktionalitet inden for Redis uden en separat broker til moderate behov, mens dedikerede brokers (Kafka, RabbitMQ) forbliver passende for større eller mere krævende messaging.
Da pålidelig messaging og event processing er almindelige behov, og da Redis Streams giver en robust, persistent, consumer-group-baseret løsning (overvinder Pub/Subs fire-and-forget begrænsning) inden for Redis, er forståelse af Redis Streams — append-only logen, consumer groups med acknowledgments og reclaim, og hvordan de sammenlignes med Pub/Sub og Kafka — værdifuld, praktisk relevant viden for at bygge pålidelig messaging og event-drevne features med Redis, det rigtige valg, når du har brug for leveringsgarantier og message-historie, som Pub/Sub ikke kan levere.