Pub/Sub (Publish/Subscribe) Redis को मेसेजिङ प्याटर्न हो जहाँ publishers ले channels मा मेसेजहरू पठाउँछन् र subscribers ले आफूले सबस्क्राइब गरेका च्यानलहरूबाट मेसेजहरू प्राप्त गर्छन् — बिना publishers र subscribers एकअर्काको बारेमा जान्नु। यसले रियल-टाइम मेसेजिङ र सेवाहरू बीच अलग-थलग संचार सक्षम गर्छ।
SUBSCRIBE news
PUBLISH news
PSUBSCRIBE news.*
Publishers PUBLISH लाई चेनलमा पठाउँछन्; subscribers SUBSCRIBE गरेर च्यानलहरूमा सबस्क्राइब गर्छन् र रियल-टाइममा मेसेजहरू प्राप्त गर्छन्। तिनीहरू अलग-थलग छन् — publisher लाई कसले (यदि कोही छ) सुनिरहेको छ भन्ने थाह छैन।
✓ 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
Redis Pub/Sub बुझ्न रियल-टाइम मेसेजिङ र अलग-थलग संचार को लागि मूल्यवान छ, त्यसैले यो उपयोगी ज्ञान हो — तर महत्त्वपूर्ण रूपमा, यसको सीमा बुझ्न पनि समान रूपमा महत्त्वपूर्ण छ यसलाई उपयुक्तरूपमा प्रयोग गर्न।
Pub/Sub ले रियल-टाइम मेसेजिङ सक्षम गर्छ जहाँ publishers च्यानलहरूमा प्रसारण गर्छन् र subscribers तत्काल प्राप्त गर्छन्, publishers र subscribers अलग-थलग (एकअर्काको बारेमा अनजान) — रियल-टाइम सूचनाहरू, च्याट, लाइभ ड्यासबोर्ड अपडेटहरू, र अलग-थलग सेवा संचार (प्राय: WebSockets सँग ब्राउजरहरूमा अपडेटहरू पुश गर्न जोडिएको) जस्ता प्रयोग मामिलाहरू चलाउँछ।
यो Redis लाई रियल-टाइम प्रसारण सुविधाहरूको लागि सरल, द्रुत विकल्प बनाउँछ।
तथापि, सबैभन्दा महत्त्वपूर्ण बिन्दु Pub/Sub को अग्निशमन-र-बिर्सनु सीमा बुझ्नु हो: यो अधिकतम-एक पल को लागि डिलिभरी हो — मेसेजहरू केवल त्यस क्षणमा जोडिएका subscribers मा पुग्छन्, र अफलाइन subscribers स्थायी रूपमा मेसेजहरू हराउँछन् (कुनै दृढता, रिप्ले, स्वीकृति, वा डिलिभरी ग्यारान्टी छैन)।
यो एक महत्त्वपूर्ण अवरोध हो: Pub/Sub अनुपयुक्त छ जब विश्वसनीय डिलिभरी वा मेसेज इतिहास मामिलेमा, र यो बुझ्न नसकेमा खोइएको-मेसेज बग्सको दिशा लाग्छ।
वैकल्पिकहरू जान्न — Redis Streams (टिकाऊ, लग-आधारित, उपभोक्ता समूह र स्वीकृतिहरू सहित) वा समर्पित ब्रोकरहरू (Kafka, RabbitMQ) विश्वसनीय मेसेजिङको लागि — र Pub/Sub चयन गर्न केवल सरल रियल-टाइम प्रसारणको लागि जहाँ मेसेजहरू हराउनु स्वीकार्य छ ठोस फैसला प्रतिफलित गर्छ।
रियल-टाइम मेसेजिङ एक सामान्य आवश्यकता छ, र Redis Pub/Sub यसको लागि सरल समाधान प्रदान गर्छ तर महत्त्वपूर्ण विश्वसनीयता सीमाहरू सहित (ग्यारान्टीहरू आवश्यक हुँदा Streams वा ब्रोकर आवश्यक छ), Pub/Sub बुझ्न — यो कसरी काम गर्छ, यसको प्रयोग मामिलाहरू, र विशेष गरी यसको अग्निशमन-र-बिर्सनु सीमा र कहिले यसको सट्टा Streams प्रयोग गर्ने — मूल्यवान, व्यावहारिक-सम्बन्धित ज्ञान हो रियल-टाइम सुविधाहरू सही तरिकामा लागू गर्न, जहाँ सीमा बुझ्न क्षमता बुझ्ने जतनै महत्त्वपूर्ण छ।