Pub/Sub (Publish/Subscribe) ialah corak pemesejan Redis di mana publishers menghantar mesej ke channels dan subscribers menerima mesej daripada channel yang mereka langgan — tanpa publishers dan subscribers mengetahui antara satu sama lain. Ia membolehkan pemesejan masa nyata dan komunikasi yang dipisahkan antara perkhidmatan.
SUBSCRIBE news
PUBLISH news
PSUBSCRIBE news.*
Publishers PUBLISH ke channel; subscribers SUBSCRIBE ke channel dan menerima mesej secara masa nyata. Mereka dipisahkan — publisher tidak tahu siapa (jika ada) yang mendengar.
✓ 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
Memahami Redis Pub/Sub adalah bernilai untuk pemesejan masa nyata dan komunikasi yang dipisahkan, jadi ia adalah pengetahuan yang berguna — tetapi yang kritikal, memahami batasannya adalah sama pentingnya untuk menggunakannya dengan sewajarnya.
Pub/Sub membolehkan pemesejan masa nyata di mana publishers menyiarkan ke channels dan subscribers menerima serta-merta, dengan publishers dan subscribers dipisahkan (tidak menyedari antara satu sama lain) — memacu kes penggunaan seperti pemberitahuan masa nyata, chat, kemas kini dashboard langsung, dan komunikasi perkhidmatan yang dipisahkan (sering digandingkan dengan WebSockets untuk menolak kemas kini ke pelayar).
Ini menjadikan Redis pilihan yang mudah dan pantas untuk ciri siaran masa nyata.
Walau bagaimanapun, perkara paling penting ialah memahami batasan fire-and-forget Pub/Sub: ia adalah penghantaran at-most-once — mesej hanya sampai kepada subscribers yang disambungkan pada masa itu, dan subscribers luar talian terlepas mesej secara kekal (tiada kegigihan, replay, akuan, atau jaminan penghantaran).
Ini adalah kekangan penting: Pub/Sub tidak sesuai apabila penghantaran yang boleh dipercayai atau sejarah mesej penting, dan tidak memahami ini membawa kepada pepijat mesej hilang.
Mengetahui alternatif — Redis Streams (tahan lama, berasaskan log, dengan consumer groups dan akuan) atau message broker khusus (Kafka, RabbitMQ) untuk pemesejan yang boleh dipercayai — dan memilih Pub/Sub hanya untuk siaran masa nyata mudah di mana kehilangan mesej boleh diterima mencerminkan pertimbangan yang baik.
Memandangkan pemesejan masa nyata adalah keperluan biasa, dan kerana Redis Pub/Sub menyediakan penyelesaian mudah untuknya tetapi dengan batasan kebolehpercayaan penting (memerlukan Streams atau broker apabila jaminan diperlukan), memahami Pub/Sub — bagaimana ia berfungsi, kes penggunaannya, dan terutamanya batasan fire-and-forget dan bila menggunakan Streams sebaliknya — adalah pengetahuan bernilai yang relevan dari segi praktikal untuk melaksanakan ciri masa nyata dengan betul, di mana memahami batasan adalah sama pentingnya dengan memahami keupayaan.