Co jsou Redis Streams?

Question

Accepted Answer

**Redis Streams** jsou append-only log datová struktura — jako trvalá fronta zpráv nebo event log — podporující **consumer groups**, persistenci zpráv, potvrzování a přehrávání. Jsou Redisovy odpovědí na spolehlivé zasílání zpráv, robustnější než Pub/Sub (který je fire-and-forget).

## Append-only log zpráv

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

Streamy jsou **append-only log**: záznamy se přidávají pomocí `XADD` (každý s jedinečným, časově seřazeným ID) a zůstávají v streamu — na rozdíl od Pub/Sub, zprávy nejsou ztraceny; jsou uloženy a mohou být znovu přečteny.

## Consumer groups — spolehlivé, škálovatelné zpracování

```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** distribuují zprávy mezi více spotřebitelů (škálování zpracování), přičemž každá zpráva jde jednomu spotřebiteli, **potvrzování** (`XACK`) potvrzuje zpracování a **pending/reclaim** (`XPENDING`/`XCLAIM`) zajišťuje, že zprávy nejsou ztraceny, pokud spotřebitel padne — spolehlivé, at-least-once doručení.

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

## Proč na tom záleží

Porozumění Redis Streams je cenné pro **spolehlivé zasílání zpráv a zpracování událostí** v rámci Redisu, takže je to užitečné znalosti — zvláště proto, že Streams řeší klíčová omezení Pub/Sub.

Zatímco Pub/Sub je jednoduchý ale fire-and-forget (offline odběratelé trvale zmešují zprávy, bez persistence), **Streams poskytují spolehlivé zasílání zpráv**: **append-only persistent log**, kde jsou zprávy uloženy (ne ztraceny) a mohou být znovu přečteny/přehrány, plus **consumer groups**, které distribuují zprávy mezi více spotřebitelů pro škálovatelné zpracování, **potvrzování** (`XACK`) k potvrzení zpracování a **pending-message reclaim** (`XPENDING`/`XCLAIM`), takže zprávy nejsou ztraceny, když spotřebitel padne — poskytuje at-least-once, spolehlivé, škálovatelné zpracování zpráv.

Porozumění **Streams vs Pub/Sub** (Streams pro spolehlivé doručení, historii a škálovatelné spotřebitele; Pub/Sub pro jednoduché broadcast v reálném čase, kde ztráta je přijatelná) je důležité pro volbu správné Redisovy messaging primitivy.

Vnímání, že Streams jsou **podobné lehkému Kafce** (log-based s consumer groups) pomáhá zarámovat jejich roli — poskytování event-streaming/message-queue schopností v rámci Redisu bez samostatného brokera pro střední potřeby, zatímco dedikovaní brokeři (Kafka, RabbitMQ) zůstávají vhodní pro větší nebo náročnější messaging.

Keďže spolehlivé zasílání zpráv a zpracování událostí jsou běžné potřeby a keďže Redis Streams poskytují robustní, persistentní, consumer-group-based řešení (překonávají fire-and-forget omezení Pub/Sub) v rámci Redisu, porozumění Redis Streams — append-only log, consumer groups s potvrzováním a reclaim, a jejich srovnání s Pub/Sub a Kafcem — je cenné, prakticky relevantní znalosti pro budování spolehlivého zasílání zpráv a event-driven funkcí s Redisem, správná volba, když potřebujete záruky doručení a historii zpráv, kterou Pub/Sub nemůže poskytnout.