Pub/Sub (Publish/Subscribe) er Redisens meldingsmønster der publishere sender meldinger til kanaler og abonnenter mottar meldinger fra kanaler de er abonnert på — uten at publishere og abonnenter kjenner til hverandre. Det muliggjør sanntidsmeldinger og frakoblet kommunikasjon mellom tjenester.
SUBSCRIBE news
PUBLISH news
PSUBSCRIBE news.*
Publishere PUBLISH til en kanal; abonnenter SUBSCRIBE til kanaler og mottar meldinger i sanntid. De er frakoblet — publisheren vet ikke hvem (hvis noen) som lytter.
✓ 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)
⚠️ 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.
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
Å forstå Redis Pub/Sub er verdifullt for sanntidsmeldinger og frakoblet kommunikasjon, så det er nyttig kunnskap — men kritisk sett er det like viktig å forstå begrensningene for å bruke det på riktig måte.
Pub/Sub muliggjør sanntidsmeldinger der publishere sender ut meldinger til kanaler og abonnenter mottar øyeblikkelig, med publishere og abonnenter frakoblet (ubevisst om hverandre) — som driver brukstilfeller som sanntidsvarslinger, chat, live dashboardoppdateringer og frakoblet tjenestekommunikasjon (ofte kombinert med WebSockets for å pushe oppdateringer til nettlesere).
Dette gjør Redis til et enkelt, raskt alternativ for sanntidsut sendelsesegenskaper.
Men det viktigste punktet er å forstå Pub/Subs fire-and-forget-begrensning: det er at-mest-en-gang-levering — meldinger når bare abonnenter som er tilkoblet på det tidspunktet, og offline-abonnenter mister meldinger permanent (ingen persistering, gjensending, bekreftelse eller leveransegaranti).
Dette er en kritisk begrensning: Pub/Sub er upassende når pålitelig levering eller meldingshistorikk er viktig, og manglende forståelse av dette fører til bugs med tapte meldinger.
Å kjenne alternativene — Redis Streams (holdbar, loggbasert, med forbrukergrupper og bekreftelser) eller dedikerte meglere (Kafka, RabbitMQ) for pålitelig meldingsutveksling — og velge Pub/Sub bare for enkel sanntidsutsendig der tapte meldinger er akseptabelt reflekterer sunn dømmekraft.
Siden sanntidsmeldinger er et vanlig behov, og siden Redis Pub/Sub tilbyr en enkel løsning for det men med viktige pålitelighetsbegrensninger (som krever Streams eller en megler når garantier er nødvendige), er det verdifullt, praktisk relevant kunnskap å forstå Pub/Sub — hvordan det fungerer, dets brukstilfeller, og spesielt dets fire-and-forget-begrensning og når man skal bruke Streams i stedet — for å implementere sanntidsfunksjoner riktig, der forståelse av begrensningen er like viktig som forståelse av muligheten.