Pub/Sub (Publish/Subscribe) to wzorzec wiadomości Redis, w którym wydawcy wysyłają wiadomości do kanałów, a subskrybenci odbierają wiadomości z kanałów, na które się zasubskrybowali — bez wiedzy wydawców i subskrybentów o sobie nawzajem. Umożliwia wysyłanie wiadomości w czasie rzeczywistym i rozdzielną komunikację między usługami.
SUBSCRIBE news
PUBLISH news
PSUBSCRIBE news.*
Wydawcy PUBLISH do kanału; subskrybenci SUBSCRIBE do kanałów i odbierają wiadomości w czasie rzeczywistym. Są rozdzieleni — wydawca nie wie, kto (jeśli w ogóle) słucha.
✓ 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
Zrozumienie Redis Pub/Sub jest cenne dla wysyłania wiadomości w czasie rzeczywistym i rozdzielnej komunikacji, dlatego jest użyteczną wiedzą — ale krytycznie, zrozumienie jego ograniczeń jest równie ważne, aby używać go właściwie.
Pub/Sub umożliwia wysyłanie wiadomości w czasie rzeczywistym, gdzie wydawcy transmitują do kanałów, a subskrybenci odbierają natychmiast, przy czym wydawcy i subskrybenci są rozdzieleni (nieświadomi siebie nawzajem) — zasilając przypadki użycia takie jak powiadomienia w czasie rzeczywistym, czat, aktualizacje paneli na żywo i rozdzielną komunikację usług (często sparowaną z WebSocketami do wysyłania aktualizacji do przeglądarek).
To czyni Redis prostą, szybką opcją dla funkcji transmisji w czasie rzeczywistym.
Jednak najważniejszym punktem jest zrozumienie ograniczenia fire-and-forget w Pub/Sub: to dostawa co najwyżej raz — wiadomości docierają tylko do subskrybentów połączonych w tym momencie, a subskrybenci offline trwale tracą wiadomości (brak trwałości, odtwarzania, potwierdzenia lub gwarancji dostarczenia).
To kluczowe ograniczenie: Pub/Sub jest nieodpowiedni, gdy niezawodna dostawa lub historia wiadomości ma znaczenie, a niezrozumienie tego prowadzi do błędów utraty wiadomości.
Znajomość alternatyw — Redis Streams (trwałe, oparte na dzienniku, z grupami konsumentów i potwierdzeniami) lub dedykowanych brokerów (Kafka, RabbitMQ) dla niezawodnego wysyłania wiadomości — oraz wybór Pub/Sub tylko dla prostej transmisji w czasie rzeczywistym, gdzie brakujące wiadomości są dopuszczalne, odzwierciedla rozsądny osąd.
Ponieważ wysyłanie wiadomości w czasie rzeczywistym jest powszechną potrzebą, a Redis Pub/Sub zapewnia proste rozwiązanie, ale z istotnymi ograniczeniami niezawodności (wymagającymi Streams lub brokera, gdy gwarancje są potrzebne), zrozumienie Pub/Sub — jak działa, jego przypadki użycia i zwłaszcza jego ograniczenie fire-and-forget oraz kiedy zamiast tego używać Streams — jest cenną, praktycznie istotną wiedzą do prawidłowego wdrażania funkcji w czasie rzeczywistym, gdzie zrozumienie ograniczenia jest równie ważne jak zrozumienie możliwości.