Miten Redis Pub/Sub toimii?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) on Redisn viestintäkuvio, jossa **julkaisijat** lähettävät viestejä **kanaviin** ja **tilaajat** vastaanottavat viestejä heille tilatuilta kanavilta — ilman että julkaisijat ja tilaajat tietävät toisistaan. Se mahdollistaa reaaliaikaisen viestinnän ja löyhästi kytketyn viestinnän palveluiden välillä.

## Pub/Sub-malli

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

Julkaisijat käyttävät `PUBLISH`ia kanavan lähettämiseen; tilaajat käyttävät `SUBSCRIBE`ia kanavaan liittymiseen ja vastaanottavat viestejä reaaliajassa. Ne ovat **löyhästi kytkettyjä** — julkaisija ei tiedä kuka (jos kukaan) kuuntelee.

## Käyttötapaukset

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

## Tärkeä rajoitus: lähetetään ja unohdetaan

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

## Kun tarvitset luotettavuutta: käytä Streamsia

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

## Miksi se on tärkeää

Redis Pub/Subin ymmärtäminen on arvokasta **reaaliaikaisen viestinnän ja löyhästi kytketyn viestinnän** vuoksi, joten se on hyödyllistä tietoa — mutta kriittisesti yhtä tärkeää on ymmärtää sen rajoitukset, jotta sitä käytetään asianmukaisesti.

Pub/Sub mahdollistaa **reaaliaikaisen viestinnän**, jossa julkaisijat lähettävät kanaviin ja tilaajat vastaanottavat välittömästi, ja julkaisijat sekä tilaajat ovat **löyhästi kytkettyjä** (tietämättömiä toisistaan) — mikä mahdollistaa reaaliaikaisia ilmoituksia, chatia, live-koontinäyttöjä ja löyhästi kytkettyjä palveluita (usein yhdessä WebSockettien kanssa selainpäivitysten työntämiseksi).

Tämä tekee Redisista yksinkertaisen ja nopean valinnan reaaliaikaisten lähetysominaisuuksien kannalta.

Kuitenkin **tärkein pointti** on Pub/Subin **lähetetään-ja-unohdetaan-rajoituksen** ymmärtäminen: se on korkeintaan kerran -toimitus — viestit saavuttavat vain tilaajat, jotka ovat yhteydessä tuolla hetkellä, ja offline-tilaajat **jäävät pysyvästi ilman viestejä** (ei säilytystä, toistoa, vahvistusta tai toimitustaetta).

Tämä on ratkaiseva rajoitus: Pub/Sub ei sovellu silloin kun luotettava toimitus tai viestien historia on tärkeää, ja jos tätä ei ymmärrä, se johtaa kadonneista viesteistä johtuviin virheisiin.

Vaihtoehdoista tietäminen — **Redis Streams** (kestävä, lokkipohjainen, kuluttajaryhmillä ja vahvistuksilla) tai erityiset välityspalvelimet (Kafka, RabbitMQ) luotettavaa viestintää varten — ja Pub/Sub:n valinta vain yksinkertaiselle reaaliaikaiselle lähettämiselle, jossa viestien puuttuminen on hyväksyttävää, osoittaa hyvää harkintaa.

Koska reaaliaikainen viestintä on yleinen tarve ja koska Redis Pub/Sub tarjoaa sille yksinkertaisen ratkaisun, mutta tärkeillä luotettavuusrajoituksilla (vaatii Streamsia tai välittäjää kun takuut ovat välttämättömiä), Pub/Subin ymmärtäminen — miten se toimii, sen käyttötapaukset ja erityisesti sen lähetetään-ja-unohdetaan-rajoitus sekä milloin käytetään Streamsia — on arvokasta, käytännöllistä tietoa reaaliaikaisten ominaisuuksien oikealle toteutukselle, jossa rajoituksen ymmärtäminen on yhtä tärkeää kuin kyvyn ymmärtäminen.