Cosa sono i Redis Streams?

Question

Accepted Answer

**Redis Streams** sono una struttura dati append-only log — come una message queue durevole o un event log — che supporta **consumer groups**, persistenza dei messaggi, acknowledgment e replay. Sono la risposta di Redis per il messaging affidabile, più robusti di Pub/Sub (che è fire-and-forget).

## Log append-only di messaggi

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

Gli Streams sono un **log append-only**: le voci vengono aggiunte con `XADD` (ognuna con un ID univoco ordinato nel tempo) e persistono nello stream — a differenza di Pub/Sub, i messaggi non vengono persi; vengono archiviati e possono essere riletti.

## Consumer groups — elaborazione affidabile e scalabile

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

I **consumer groups** distribuiscono i messaggi tra più consumer (scalando l'elaborazione), con ogni messaggio che va a un consumer, **acknowledgment** (`XACK`) che confermano l'elaborazione, e **pending/reclaim** (`XPENDING`/`XCLAIM`) che garantiscono che i messaggi non vengano persi se un consumer si arresta — consegna affidabile, at-least-once.

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

## Perché è importante

Comprendere Redis Streams è prezioso per il **messaging affidabile e l'event processing** all'interno di Redis, quindi è una conoscenza utile — in particolare perché Streams affrontano le limitazioni chiave di Pub/Sub.

Mentre Pub/Sub è semplice ma fire-and-forget (i subscriber offline perdono permanentemente i messaggi, nessuna persistenza), **Streams forniscono messaging affidabile**: un **log persistente append-only** dove i messaggi vengono archiviati (non persi) e possono essere riletti/riprodotti, oltre a **consumer groups** che distribuiscono i messaggi tra più consumer per l'elaborazione scalabile, **acknowledgment** (`XACK`) per confermare l'elaborazione, e **reclaim di messaggi in sospeso** (`XPENDING`/`XCLAIM`) in modo che i messaggi non vengano persi quando un consumer si arresta — fornendo consegna affidabile, at-least-once e elaborazione dei messaggi scalabile.

Comprendere **Streams vs Pub/Sub** (Streams per consegna affidabile, cronologia e consumer scalabili; Pub/Sub per broadcast real-time semplice dove la perdita è accettabile) è importante per scegliere la giusta primitiva di messaging Redis.

Riconoscere che Streams sono **simili a un Kafka leggero** (basato su log con consumer groups) aiuta a inquadrare il loro ruolo — fornendo capacità di event-streaming/message-queue all'interno di Redis senza un broker separato per esigenze moderate, mentre i broker dedicati (Kafka, RabbitMQ) rimangono appropriati per messaging su larga scala o più esigente.

Poiché il messaging affidabile e l'event processing sono esigenze comuni, e poiché Redis Streams fornisce una soluzione robusta, persistente, basata su consumer group (superando la limitazione fire-and-forget di Pub/Sub) all'interno di Redis, comprendere Redis Streams — il log append-only, i consumer group con acknowledgment e reclaim, e come si confrontano con Pub/Sub e Kafka — è una conoscenza preziosa e praticamente rilevante per costruire messaging affidabile e funzionalità event-driven con Redis, la scelta giusta quando hai bisogno di garanzie di consegna e cronologia dei messaggi che Pub/Sub non può fornire.