पब्लिश/सब्सक्राइब (या pub/sub) एक सॉफ्टवेयर इंजीनियरिंग पैटर्न है जिसका उपयोग दशकों से किया जा रहा है लेकिन अक्सर उपयोगी होने के लिए समर्पित मैसेजिंग सर्वर और विशेष ज्ञान की आवश्यकता होती थी।
Redis pub/sub पब्लिश/सब्सक्राइब पैटर्न का एक लीन और सरल कार्यान्वयन है जो 2.0 रिलीज़ के बाद से सभी Redis सर्वरों की एक विशेषता रही है। इसका मतलब है कि यह कहीं भी उपयोग करना आसान है जहां Redis डिप्लॉय किया गया है, और Redis डिप्लॉय करके एक तेज़ और सरल pub/sub सिस्टम को जल्दी से बनाया जा सकता है।
यह समझने के लिए कि Redis pub/sub किसी ऐप के लिए उपयुक्त है या नहीं, पहले pub/sub के डिज़ाइन और लक्ष्य को समझना महत्वपूर्ण है, फिर Redis pub/sub कार्यान्वयन की विशेषताओं पर विचार करना।
Pub/sub अवलोकन
Pub/sub डिज़ाइन: "पब्लिशर्स" को "सब्सक्राइबर्स" से अलग करना
निर्भरता कम करना और ज्ञान को विभाजित करना स्केलेबल सॉफ्टवेयर डिज़ाइन में प्रमुख लक्ष्य हैं। पब्लिश/सब्सक्राइब मैसेजिंग पैटर्न, जिसे pub/sub के नाम से भी जाना जाता है, आपके सॉफ्टवेयर के उन हिस्सों को अलग करता है जो मैसेजेस पब्लिश करते हैं उन हिस्सों से जो मैसेजेस पर कार्रवाई करते हैं। इसे बेहतर ढंग से समझने के लिए, आइए कुछ उदाहरण देखें:
"पब्लिशर्स" के उदाहरण
- एक ऐप जो आपको चैट रूम में मैसेज भेजने देता है
- एक डॉकर कंटेनर जो अपने स्वास्थ्य या सेवाओं की घोषणा करता है
- एक ऐप जो स्टॉक ट्रेड की कीमतों की घोषणा करता है
- आपके घर में एक तापमान सेंसर जो अपनी रीडिंग की घोषणा करता है
- एक मल्टीप्लेयर गेम में मैसेज ब्रॉडकास्टर ("एलन को एक ग्रू द्वारा खाया गया")
"सब्सक्राइबर्स" के उदाहरण
- चैट रूम में मैसेजेस सुनने वाले ऐप्स।
- एक ऐप जो नोटिफिकेशन्स को Slack पर फॉरवर्ड करता है
- रीयल-टाइम में क्या हो रहा है यह देखने के लिए उपयोग किया जाने वाला मोबाइल क्लाइंट
- एक लॉगिंग सर्विस जो बाद में विश्लेषण के लिए इवेंट्स रिकॉर्ड करती है
Pub/sub पैटर्न आपको पब्लिशर्स** पर काम करते समय **सब्सक्राइबर्स के बारे में बहुत अधिक सोचने से बचने में मदद करता है, और इसके विपरीत। उपरोक्त उदाहरणों में हम कई सब्सक्राइबर्स की कल्पना कर सकते हैं जो किसी एक पब्लिशर के मैसेजेस में रुचि रखते हैं। सब्सक्राइबर्स सभी पब्लिशर्स को सुनना भी चाह सकते हैं।
Pub/sub में एक पब्लिशर को अपने सब्सक्राइबर्स के बारे में जानने की आवश्यकता नहीं होती - यह एक मैसेज को एक चैनल पर पुश करता है (अक्सर अन्य सिस्टम्स में टॉपिक कहा जाता है) और आगे बढ़ जाता है। उस चैनल को सुनने वाले कोई भी सब्सक्राइबर्स जब मैसेज पब्लिश होता है तो उसे प्राप्त करेंगे।
सब्सक्राइबर्स को एक या अधिक चैनल्स सुनने और मैसेजेस आने पर प्रतिक्रिया करने के लिए डिज़ाइन किया गया है। यदि कोई सब्सक्राइबर पब्लिश किए गए मैसेजेस की गति के साथ तालमेल नहीं रख पाता है, तो वह कुछ मैसेजेस मिस कर देगा। यह एक उपयोगी डिज़ाइन है: यह सिस्टम को किसी धीमे सब्सक्राइबर्स की क्षमता से आगे स्केल करने की अनुमति देता है। पब्लिशर्स सब्सक्राइबर व्यवहार से धीमे हुए बिना तेजी से आगे बढ़ते हैं।
Pub/sub का लक्ष्य: डिलीवरी स्केल करना, वर्कलोड नहीं
Pub/sub सॉफ्टवेयर स्केलिंग में उपयोग किया जाने वाला एक पैटर्न है - यह समझना महत्वपूर्ण है कि यह किस प्रकार की स्केलिंग में मदद करता है। Pub/sub और मैसेज क्यूइंग के बीच एक महत्वपूर्ण अंतर है।
क्यूइंग पैटर्न में, एक क्यू (या Redis में लिस्ट) प्रोसेस किए जाने वाले मैसेजेस को बफर करता है जबकि वर्कर्स का एक पूल लिस्ट से आइटम्स पॉप करता है और उन्हें हैंडल करता है। इस मॉडल में, अपने वर्कर्स के पूल का आकार बढ़ाने से आपकी क्यू को प्रोसेस करने की गति बढ़ जाती है, क्योंकि प्रत्येक मैसेज केवल एक वर्कर को पास किया जाता है। सभी वर्कर्स किसी दिए गए मैसेज को ठीक उसी तरह हैंडल करते हैं।
दूसरी ओर pub/sub में, सिस्टम एक चैनल के सभी मैसेजेस को उसके सभी सब्सक्राइबर्स तक पहुंचाने का प्रयास करता है। यह एक कई-से-कई पैटर्न है, जहां प्रत्येक अलग-अलग सब्सक्राइबर मैसेज के साथ कुछ अनूठा करता है - एक इसे ड्यूरेबल लॉग में लिखता है, एक इसे Slack चैनल पर भेजता है, एक स्थानीय बिक्री कार्यालय में घंटी बजाता है, आदि।
संक्षेप में, pub/sub मैसेज डिलीवरी को स्केल करता है, और क्यूइंग मैसेज वर्कलोड प्रोसेसिंग को स्केल करता है। Redis अक्सर दोनों लक्ष्यों के लिए उपयोग किया जाता है। Redis के साथ क्यूइंग के लोकप्रिय उदाहरण के लिए Sidekiq देखें।
Redis pub/sub की विशेषताएं
Pub/sub एक ऐसा पैटर्न है जो बहुत लंबे समय से मौजूद है, और जबकि कोर पैटर्न समान है, विशिष्ट विशेषताएं कार्यान्वयन से कार्यान्वयन में काफी भिन्न होती हैं।
Redis pub/sub एक हल्का, तेज़ कार्यान्वयन है। इसके डिज़ाइन को सर्वोत्तम रूप से समझने के लिए, उन विशेषताओं को देखना उपयोगी होगा जो Redis pub/sub का हिस्सा नहीं हैं:
- कोई पर्सिस्टेंस या वैल्यू कैशिंग नहीं
- कोई डिलीवरी गारंटी नहीं
- कोई क्लस्टर ऑप्टिमाइज़ेशन नहीं... अभी तक
कोई पर्सिस्टेंस नहीं: "लेकिन मुझे लगा यह चैट रूम जैसा है..."
अधिकांश Redis ऑपरेशन्स के विपरीत, जिन्हें डिस्क पर लिखा जा सकता है, Redis pub/sub नॉन-पर्सिस्टेंट है। पब्लिश किए गए मैसेजेस सीधे सब्सक्राइबर्स को पास किए जाते हैं और फिर ड्रॉप कर दिए जाते हैं, Redis की मेमोरी या डिस्क पर कोई रिकॉर्ड बरकरार नहीं रहता।
यह नए उपयोगकर्ताओं के लिए कभी-कभी भ्रमित करने वाला हो सकता है जो सुनते हैं कि Redis pub/sub का उपयोग अक्सर चैट रूम लागू करने के लिए किया जाता है। हम में से कई Slack जैसे टूल्स को चैट रूम के रूप में सोचते हैं - आप लॉग इन करते हैं और हालिया मैसेजेस देखते हैं और फिर सभी नए प्राप्त करते हैं। वास्तव में "हालिया मैसेजेस देखना" pub/sub का हिस्सा बिल्कुल नहीं है, और इसे अलग माध्यम से हैंडल किया जाना चाहिए। Pub/sub केवल नए मैसेजेस की डिलीवरी की सुविधा देता है। इस अर्थ में pub/sub एक लाइव स्ट्रीम की तरह है - जब आप इसे चालू करते हैं तो आप जानकारी प्राप्त करना शुरू करते हैं, लेकिन आप इससे पहले जो हुआ उसके बारे में कुछ नहीं सीखते। एक तरफ: इंटरनेट रिले चैट (IRC) बिना बिल्ट-इन हिस्ट्री या मैसेज रिटेंशन के pub/sub मॉडल का उपयोग करता है - इसीलिए चैट रूम रूपक इतना आम है।
वास्तव में आप अभी भी Redis और pub/sub के साथ एक चैट रूम लागू कर सकते हैं। ऐसा करने के लिए आप यह सुनिश्चित करेंगे कि मैसेजेस न केवल पब्लिश किए जाएं बल्कि एक लिस्ट पर भी पुश किए जाएं ताकि उपयोगकर्ता मैसेज हिस्ट्री देख सकें।
कोई डिलीवरी गारंटी नहीं
Pub/sub मॉडल में सब्सक्राइबर्स को मैसेजेस प्राप्त करने की गारंटी नहीं होती। यदि किसी सब्सक्राइबर को नेटवर्किंग समस्या है, वह मैसेजेस को पर्याप्त तेजी से पढ़ने में विफल रहता है, या अन्यथा मैसेज पब्लिश होने पर जुड़ा हुआ नहीं लगता है, तो उसे मैसेज प्राप्त नहीं होगा। पब्लिशर्स चैनल्स पर मैसेजेस भेज सकते हैं तब भी जब कोई सब्सक्राइबर सुन नहीं रहा हो - वे मैसेजेस ड्रॉप हो जाते हैं।
कुछ अन्य मैसेजिंग सिस्टम रीड रिसीप्ट्स या "एक्स" या एक सब्सक्राइबर के लिए बफर स्टोर कर सकते हैं जो डिस्कनेक्शन की छोटी अवधि के खिलाफ सुरक्षा करता है। Redis यहां सरल विकल्प चुनता है: यदि आप एक मैसेज मिस करते हैं, तो आपने मैसेज मिस कर दिया है। मैसेजेस जो अवश्य अपने प्राप्तकर्ता तक पहुंचने चाहिए, उन्हें अन्य माध्यमों से डिलीवर किया जाना चाहिए।
यह ट्रेडऑफ सुनने से भी बदतर लगता है। मैसेज एकनॉलेजमेंट और सब्सक्राइबर-विशिष्ट बफरिंग को छोड़ देने से Redis pub/sub मैसेजेस को बहुत तेजी से प्रोसेस करता है, और कई सिस्टम हैं जो फेयर-वेदर मैसेज डिलीवरी से लाभान्वित होते हैं।
अभी के लिए अकुशल क्लस्टर स्केलिंग...
Pub/sub स्केलिंग का एक समाधान है, इसलिए अपने मैसेजेस के साथ-साथ मैसेज डिलीवर करने के लिए उपयोग की जा रही सेवा को स्केल करने पर विचार करना महत्वपूर्ण है। कई मैसेजिंग सिस्टम, जिनमें RabbitMQ और Kafka शामिल हैं, को उच्च उपलब्धता और उचित स्केलिंग गुणों के लिए डिज़ाइन किया गया था जैसे-जैसे मैसेजिंग सर्विस सेटअप बढ़ता है।
Redis Cluster (Redis 3.0 का हिस्सा) में Redis pub/sub के लिए बिल्ट-इन सपोर्ट है, एक महत्वपूर्ण चेतावनी के साथ। हर पब्लिश किया गया मैसेज Redis क्लस्टर के हर सदस्य को ब्रॉडकास्ट किया जाता है, जो बड़े क्लस्टर्स को जल्दी से ट्रैफिक से अभिभूत कर सकता है।
इसका संक्षिप्त उत्तर यह है कि pub/sub का उपयोग केवल व्यक्तिगत Redis सर्वर्स या छोटे pub/sub-विशिष्ट क्लस्टर्स पर करें - ये दोनों विकल्प बड़ी संख्या में मैसेजेस को संभाल सकते हैं। लंबी अवधि में Redis Cluster में केवल आवश्यकतानुसार मैसेजेस को रूट करने के लिए स्मार्ट फीचर्स होंगे, लेकिन वह फीचर अभी भी डिज़ाइन चरण में है।
समापन
कुल मिलाकर Redis pub/sub सॉफ्टवेयर स्केलिंग के लिए एक उपयोगी टूल है। ऊपर देखी गई प्रत्येक विशेषता की अनुपस्थिति एक डिज़ाइन ट्रेडऑफ है, जिसके परिणामस्वरूप Redis के लिए सरलता और गति होती है, सभी मैसेजिंग उद्देश्यों के लिए रामबाण होने की कीमत पर।
Redis के कई अन्य हिस्सों की तरह यह हर विशेष उपयोग के मामले के लिए सिलवाया नहीं गया है लेकिन थोड़ी समझ के साथ यह आपको बहुत दूर ले जा सकता है। Redis की अन्य विशेषताओं के साथ जोड़े जाने पर यह डेवलपर के टूलबेल्ट में एक बहुत शक्तिशाली टूल बन जाता है।
उस उच्च-स्तरीय अवलोकन के पूरा होने के साथ, आप शायद कुछ pub/sub कोड उदाहरण देखने के लिए तैयार हैं। अगला Redis Pub/Sub: How To देखें।
