Qu'est-ce que Redis Streams ?

Question

Accepted Answer

**Redis Streams** est une structure de données append-only (journal immuable) — comme une file d'attente de messages persistante ou un journal d'événements — supportant les **groupes de consommateurs**, la persistance des messages, les accusés de réception, et la relecture. C'est la solution de Redis pour la messagerie fiable, plus robuste que Pub/Sub (qui fonctionne sur le modèle du fire-and-forget).

## Journal append-only de messages

```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)
```

Les Streams sont un **journal append-only** : les entrées sont ajoutées avec `XADD` (chacune avec un ID unique, ordonné par le temps) et persistent dans le stream — contrairement à Pub/Sub, les messages ne sont pas perdus ; ils sont stockés et peuvent être relus.

## Groupes de consommateurs — traitement fiable et scalable

```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
```

Les **groupes de consommateurs** distribuent les messages parmi plusieurs consommateurs (pour scaler le traitement), avec chaque message allant à un seul consommateur, les **accusés de réception** (`XACK`) confirmant le traitement, et **pending/reclaim** (`XPENDING`/`XCLAIM`) garantissant que les messages ne sont pas perdus si un consommateur s'arrête — livraison fiable, au moins une fois.

## 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).
```

## Pourquoi c'est important

Comprendre Redis Streams est précieux pour la **messagerie fiable et le traitement d'événements** au sein de Redis, c'est donc une connaissance utile — particulièrement parce que Streams répondent aux limitations clés de Pub/Sub.

Alors que Pub/Sub est simple mais fire-and-forget (les abonnés hors ligne perdent définitivement les messages, pas de persistance), **Streams fournissent une messagerie fiable** : un **journal persistent append-only** où les messages sont stockés (non perdus) et peuvent être relus/rejoués, plus des **groupes de consommateurs** qui distribuent les messages parmi plusieurs consommateurs pour un traitement scalable, des **accusés de réception** (`XACK`) pour confirmer le traitement, et un **reclaim de messages en attente** (`XPENDING`/`XCLAIM`) pour que les messages ne soient pas perdus quand un consommateur s'arrête — offrant un traitement des messages au moins une fois, fiable et scalable.

Comprendre **Streams vs Pub/Sub** (Streams pour une livraison fiable, l'historique et des consommateurs scalables ; Pub/Sub pour la diffusion temps réel simple où la perte est acceptable) est important pour choisir la primitive de messagerie Redis appropriée.

Reconnaître que Streams sont **similaires à un Kafka léger** (basé sur les logs avec groupes de consommateurs) aide à encadrer leur rôle — fournir des capacités de streaming d'événements/file d'attente de messages au sein de Redis sans broker séparé pour les besoins modérés, tandis que les brokers dédiés (Kafka, RabbitMQ) restent appropriés pour une messagerie à plus grande échelle ou plus exigeante.

Comme la messagerie fiable et le traitement d'événements sont des besoins courants, et puisque Redis Streams fournissent une solution robuste, persistante et basée sur des groupes de consommateurs (surmontant la limitation fire-and-forget de Pub/Sub) au sein de Redis, comprendre Redis Streams — le journal append-only, les groupes de consommateurs avec accusés de réception et reclaim, et comment ils se comparent à Pub/Sub et Kafka — est une connaissance précieuse et pratiquement pertinente pour construire des fonctionnalités de messagerie fiable et événementielle avec Redis, le bon choix quand vous avez besoin de garanties de livraison et d'historique de messages que Pub/Sub ne peut pas fournir.