Pub/Sub (Publish/Subscribe) je Redis-ov vzorec sporočanja, kjer izdajatelji pošiljajo sporočila na kanale in naročniki prejemajo sporočila s kanalov, na katere so naročeni — brez da bi se izdajatelji in naročniki medsebojno poznali. Omogoča sporočanje v realnem času in odklopljeno komunikacijo med storitvami.
Model Pub/Sub
# 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.
Izdajatelji s PUBLISH pošiljajo na kanal; naročniki se SUBSCRIBE na kanale in prejemajo sporočila v realnem času. Sta odklopljena — izdajatelj ne ve, kdo (če sploh kdo) poslušuje.
Primeri uporabe
✓ 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)
Pomembna omejitev: poženi in pozabi
⚠️ 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.
Ko potrebuješ zanesljivost: uporabi Streams
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
Zakaj je to pomembno
Razumevanje Redis Pub/Sub-a je dragoceno za sporočanje v realnem času in odklopljeno komunikacijo, zato je to koristno znanje — vendar je kritično tudi razumevanje njegovih omejitev, da ga uporabiš ustrezno.
Pub/Sub omogoča sporočanje v realnem času, kjer izdajatelji pošiljajo na kanale in naročniki prejemajo takoj, pri čemer sta izdajatelj in naročnik odklopljena (si nista tega zavedna) — to omogoča primere uporabe, kot so obvestila v realnem času, klepet, posodobitve živih nadzornih plošč in odklopljeno komunikacijo med storitvami (pogosto v kombinaciji z WebSocketi za pošiljanje posodobitev v brskalnike).
To naredi Redis enostaven in hiter vir za funkcije oddajanja v realnem času.
Hkrati je najpomembnejša točka razumevanje omejitve poženi-in-pozabi Pub/Sub-a: gre za dostavo največ enkrat — sporočila dosežejo samo naročnike, ki so povezani v tistem trenutku, in naročniki, ki so brez povezave, trajno zamudijo sporočila (brez trajnosti, ponovitve, potrditve ali jamstva za dostavo).
To je ključna omejitev: Pub/Sub ni primeren, ko je zanesljiva dostava ali zgodovina sporočil pomembna, in če te omejitve ne razumeš, to pripelje do hroščev s Lost sporočili.
Znanje o alternativah — Redis Streams (trajni, na dnevniku osnovani, s skupinami potrošnikov in potrdilami) ali namenski posredniki (Kafka, RabbitMQ) za zanesljivo sporočanje — in izbira Pub/Sub-a samo za preprosto oddajanje v realnem času, kjer je sprejemljivo, da zamudijo sporočila, odraža presojnost.
Ker je sporočanje v realnem času pogosta potreba in ker Redis Pub/Sub zagotavlja preprosto rešitev zanjo, vendar z pomembnimi omejitvami zanesljivosti (ki zahtevajo Streams ali posrednika, ko so jamstva potrebna), je razumevanje Pub/Sub-a — kako deluje, njegovi primeri uporabe in še posebej njegova omejitev poženi-in-pozabi ter kdaj namesto tega uporabiti Streams — dragoceno, praktično relevantno znanje za pravilno izvajanje funkcij v realnem času, kjer je razumevanje omejitve prav tako pomembno kot razumevanje zmožnosti.
