Hur fungerar Redis Pub/Sub?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) är Redisens meddelandemönster där **publishers** (utgivare) skickar meddelanden till **channels** (kanaler) och **subscribers** (prenumeranter) tar emot meddelanden från kanaler de är prenumeranter på — utan att utgivare och prenumeranter känner till varandra. Det möjliggör realtidsmeddelanden och avkopplad kommunikation mellan tjänster.

## Pub/Sub-modellen

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

Utgivare använder `PUBLISH` för att skicka till en kanal; prenumeranter använder `SUBSCRIBE` för att prenumerera på kanaler och tar emot meddelanden i realtid. De är **avkopplade** — utgivaren vet inte vem (om någon) som lyssnar.

## Användningsfall

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

## Viktig begränsning: "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.
```

## När du behöver tillförlitlighet: använd 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
```

## Varför det spelar roll

Att förstå Redis Pub/Sub är värdefullt för **realtidsmeddelanden och avkopplad kommunikation**, så det är användbar kunskap — men kritiskt sett är det lika viktigt att förstå dess begränsningar för att använda det på rätt sätt.

Pub/Sub möjliggör **realtidsmeddelanden** där utgivare sänder till kanaler och prenumeranter tar emot omedelbar, med utgivare och prenumeranter **avkopplade** (omedvetna om varandra) — vilket driver användningsfall som realtidsnotifieringar, chatt, uppdateringar av live-instrumentpaneler och avkopplad tjänstkommunikation (ofta tillsammans med WebSockets för att skicka uppdateringar till webbläsare).

Detta gör Redis till ett enkelt, snabbt alternativ för realtidssändningsfunktioner.

Men den **viktigaste punkten** är att förstå Pub/Subs **"fire-and-forget"-begränsning**: det är "högst en gång"-leverans — meddelanden når endast prenumeranter som är anslutna vid det tillfället, och offlineprenumeranter **missar meddelanden permanent** (ingen persistens, omuppspelning, bekräftelse eller leveransgaranti).

Detta är en avgörande begränsning: Pub/Sub är olämpligt när tillförlitlig leverans eller meddelandehistorik spelar roll, och att inte förstå detta leder till buggar med förlorade meddelanden.

Att känna till alternativen — **Redis Streams** (hållbar, loggbaserad, med konsumentgrupper och bekräftelser) eller dedikerade mäklare (Kafka, RabbitMQ) för tillförlitlig meddelanden — och välja Pub/Sub endast för enkel realtidssändning där förlorade meddelanden är acceptabelt reflekterar sunt omdöme.

Eftersom realtidsmeddelanden är ett vanligt behov, och eftersom Redis Pub/Sub tillhandahåller en enkel lösning för det men med viktiga tillförlitlighetsbegränsningar (kräver Streams eller en mäklare när garantier är nödvändiga), är det värdefullt och praktiskt relevant att förstå Pub/Sub — hur det fungerar, dess användningsfall och särskilt dess "fire-and-forget"-begränsning och när du bör använda Streams istället — för att implementera realtidsfunktioner på rätt sätt, där förståelsen för begränsningen är lika viktig som förståelsen för möjligheten.