Jak funguje Redis Pub/Sub?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) je messaging pattern Redisu, kde **publikátoři** odesílají zprávy do **kanálů** a **předplatitelé** přijímají zprávy z kanálů, na které jsou přihlášeni — bez toho, aby se publikátoři a předplatitelé navzájem znali. Umožňuje real-time messaging a oddělenou komunikaci mezi službami.

## Pub/Sub model

```bash
# Subscriber listens on a channel
SUBSCRIBE news                    # subscribe to the "news" channel

# Publisher sends a message to the channel (in another connection)
PUBLISH news "Breaking story!"    # all subscribers to "news" receive this instantly

# Pattern subscriptions (wildcards)
PSUBSCRIBE news.*                 # subscribe to news.sports, news.tech, etc.
```

Publikátoři používají `PUBLISH` na kanál; předplatitelé se `SUBSCRIBE` na kanály a přijímají zprávy v reálném čase. Jsou **odděleni** — publikátor neví, kdo (pokud vůbec někdo) naslouchá.

## Případy použití

```text
✓ REAL-TIME notifications — push events to interested services/clients instantly
✓ Chat / messaging — broadcast messages to subscribers
✓ Live updates — dashboards, feeds, multiplayer (broadcast state changes)
✓ Decoupling services — services communicate via channels without direct coupling
✓ Often paired with WebSockets (Redis pub/sub → server → WebSocket → browser)
```

## Důležité omezení: fire-and-forget

```text
⚠️ Redis Pub/Sub is FIRE-AND-FORGET (at-most-once delivery):
  → Messages are delivered ONLY to subscribers connected AT THAT MOMENT.
  → If a subscriber is offline/disconnected, it MISSES the message (no storage/replay).
  → No persistence, no acknowledgment, no delivery guarantee.
→ NOT suitable when you need reliable delivery or message history.
```

## Když potřebujete spolehlivost: použijte Streams

```text
For RELIABLE messaging (persistence, replay, consumer groups, acknowledgments):
  → use Redis STREAMS (a durable, log-based structure) instead of Pub/Sub
  → or a dedicated message broker (Kafka, RabbitMQ)
Pub/Sub → simple real-time broadcast where missing messages is acceptable
Streams → when you need durability and delivery guarantees
```

## Proč to je důležité

Porozumění Redis Pub/Sub je cenné pro **real-time messaging a oddělenou komunikaci**, takže je to užitečné znalosti — ale kriticky je stejně důležité pochopit jeho omezení, abyste ho používali správně.

Pub/Sub umožňuje **real-time messaging**, kde publikátoři vysílají do kanálů a předplatitelé přijímají okamžitě, přičemž publikátoři a předplatitelé jsou **odděleni** (navzájem si nejsou vědomi) — což pohání případy použití jako real-time notifikace, chat, aktualizace live dashboardů a oddělenou komunikaci služeb (často kombinovanou s WebSockets pro push aktualizací do prohlížečů).

To činí Redis jednoduchou a rychlou volbou pro real-time broadcast funkce.

Ale **nejdůležitější bod** je porozumění **fire-and-forget omezení** Pub/Sub: jedná se o doručení maximálně jednou — zprávy dosáhnou pouze předplatitelů připojených v daný moment a offline předplatitelé **trvale propásnou zprávy** (bez persistence, replay, potvrzení nebo záruky doručení).

Toto je klíčové omezení: Pub/Sub je nevhodný, když záleží na spolehlivém doručení nebo historii zpráv, a nepochopení tohoto vede k chybám se ztrátou zpráv.

Znalost alternativ — **Redis Streams** (trvalé, na bázi logu, se skupinami spotřebitelů a potvrzeními) nebo dedikovaných brokerů (Kafka, RabbitMQ) pro spolehlivé messaging — a výběr Pub/Sub pouze pro jednoduchý real-time broadcast, kde je přijatelné, že nějaké zprávy zmizí, odráží zdravý úsudek.

Protože real-time messaging je běžnou potřebou a protože Redis Pub/Sub poskytuje jednoduché řešení, ale s důležitými omezeními spolehlivosti (vyžadujícími Streams nebo broker, když jsou záruky potřebné), porozumění Pub/Sub — jak funguje, jeho případy použití a zejména jeho fire-and-forget omezení a kdy místo toho použít Streams — je cenné, prakticky relevantní znalosti pro správné implementování real-time funkcí, kde je pochopení omezení stejně důležité jako pochopení schopnosti.