वितरित संदेश system, message broker (kafka, खरगोशबिटक को समझने से पहले बुनियादी)

हैलो, यह codeshow है।
इस क्लास में हम डिस्ट्रीब्यूटेड मैसेजिंग सिस्टम सीखेंगे।
मैसेजिंग सिस्टम में, एक संदेश वह डेटा होता है जिसे दो या दो से अधिक रिश्तों के बीच आदान-प्रदान किया जा सकता है।
यहां डेटा आमतौर पर बाइनरी डेटा होता है। json या प्रोटोकॉल बफ़र्स जैसे सीरियलाइज़र का उपयोग करके डेटा भेजें और प्राप्त करें।
बीच में मैसेजिंग सिस्टम के साथ, एक पक्ष का publisher होता है और दूसरे पक्ष का ग्राहक संबंध होता है।
publisher एक ग्राहक है जो संदेश उत्पन्न करता है और उन्हें संदेश कतार में जमा करता है। कतार में संदेश भेजना publish कहलाता है।
सब्सक्राइबर एक क्लाइंट है जो संदेश कतार से संदेश प्राप्त करता है। कतार से संदेश प्राप्त करना consume कहलाता है।
संदेश publisher द्वारा publish हैं, और संदेश संदेश प्रणाली के माध्यम से ग्राहकों तक जाते हैं।
संदेश हमेशा एक तरफ़ा प्रवाहित होते हैं: publisher से संदेश प्रणाली तक ग्राहकों तक।
संदर्भ के लिए, हम publisher के बजाय producer और consumer के बजाय उपभोक्ता शब्द का उपयोग करते हैं।
इसके अलावा पब और सब का उपयोग publisher और ग्राहक को छोटा करके किया जाता है।

publisher और ग्राहक के बीच संबंध को समझने के लिए, मैं कोड को एक उदाहरण के रूप में समझाऊंगा।

package main

import "time"

func main() {
    c := make(chan string)
    go pub(c)
    go sub(c)
    select {}
}

func sub(c <-chan string) {
    for {
        message := <-c
        println(message)
    }
}

func pub(c chan<- string) {
    c <- "Hello World 1"
    time.Sleep(1 * time.Second)
    c <- "Hello World 2"
    time.Sleep(1 * time.Second)
    c <- "Hello World 3"
    time.Sleep(1 * time.Second)
    c <- "Hello World 4"
    time.Sleep(24 * time.Hour)
}

इस कोड में main function में एक string type channel create किया जाता है.
पब समारोह एक “हैलो वर्ल्ड” चरित्र publish है ।
और उप आउटपुट “हैलो वर्ल्ड” जब कोई संदेश चैनल में अनंत लूप के लिए आता है।
पब समारोह के अंदर, हम चैनल के लिए एक स्ट्रिंग publish,
उप फ़ंक्शन चैनल के माध्यम से स्ट्रिंग का consume है ।
एक मॉड्यूल जो consume है और संदेशों को संसाधित करता है उसे worker भी कहा जाता है।

publisher, मैसेजिंग सिस्टम और सब्सक्राइबर के बीच संबंध पर पहले चर्चा की गई थी।
उपरोक्त पुराने भाषा कोड में, पब फ़ंक्शन publisher में कार्य करता है और उप फ़ंक्शन ग्राहक के रूप में कार्य करता है।
और आप इस पब और उप के बीच स्ट्रिंग चैनल प्रकार के c वेरिएबल को मैसेजिंग सिस्टम के रूप में सोच सकते हैं।

यदि कोई भाषा मैसेजिंग प्रदान नहीं करती है, जैसे GoLanguage, तो फ्रेमवर्क करता है।
जावा के स्प्रिंग फ्रेमवर्क को एक उदाहरण के रूप में लेते हुए, यह ApplicationEvent प्रकार के संदेशों का उत्सर्जन करता है।
और आप EventListener एनोटेशन के माध्यम से publish संदेशों की सदस्यता ले सकते हैं।
इस समय, स्प्रिंग फ्रेमवर्क द्वारा संदेश प्रणाली का ध्यान रखा जाता है।
ध्यान दें कि संदेश और ईवेंट समान हैं।
दोनों के बीच अंतर यह है कि मैसेजिंग आमतौर पर क्यू नामक स्टोरेज में संदेशों को स्टोर करता है, इसलिए सब्सक्राइबर उन्हें तुरंत के बजाय बाद में प्रोसेस कर सकते हैं।
घटनाएँ घटित होते ही ग्राहकों को भेज दी जाती हैं, और घटनाएँ नष्ट हो जाती हैं।

जैसा कि ऊपर बताया गया है, मैसेजिंग में एक स्टोरेज होता है जिसे क्यू कहा जाता है।
इसलिए इसे संदेश कतार कहा जाता है।

सामान्य तौर पर, मैसेजिंग सिस्टम को वितरित वातावरण में संदेश वितरण और प्रसंस्करण के लिए डिज़ाइन किया गया है।
इसलिए न तो गो भाषा के चैनल और न ही स्प्रिंग फ्रेमवर्क के इवेंट लिस्टनर एक सीमित संदर्भ में मैसेजिंग सिस्टम हैं।
हालाँकि, पूर्ववर्ती और निम्नलिखित दोनों एक घटना संचालित वास्तुकला का पालन करते हैं और इसे व्यापक अर्थों में संदेश प्रणाली के रूप में देखा जा सकता है।

अब से, आइए kafka और रैबिटमैक को देखें, जो सबसे अधिक उपयोग किए जाने वाले वितरित मैसेजिंग सिस्टम हैं।

सबसे पहले, kafka और रैबिटमैक दोनों मैसेजिंग सिस्टम हैं जो एक वितरित वातावरण में काम करते हैं।
message broker भी कहा जाता है।

वितरित मैसेजिंग सिस्टम आमतौर पर मापनीयता, उच्च उपलब्धता और विश्वसनीयता प्रदान करते हैं।

1. स्केलेबिलिटी के लिए, kafka और रैबिटमैक cluster को कॉन्फ़िगर कर सकते हैं।
   यह नोड्स की संख्या बढ़ाकर क्षैतिज स्केलिंग की अनुमति देता है।
   थ्रूपुट को क्षैतिज स्केलिंग के माध्यम से बढ़ाया जा सकता है।
2. उच्च उपलब्धता का मतलब है कि कुछ नोड्स डाउन होने पर भी मैसेजिंग सिस्टम चालू रहता है।
3. विश्वसनीयता संदेश वितरण का विश्वसनीय व्यवहार है, जैसे प्रकाशित संदेशों को न खोना और ग्राहकों को डुप्लिकेट संदेश न भेजना।

वितरित संदेश प्रणाली के रूप में kafka और खरगोशबिट उपरोक्त मानदंडों को पूरा करते हैं।

और publisher एक समय में एक संदेश publish है, लेकिन संदेश प्रणाली के माध्यम से, इस संदेश को दोहराया जा सकता है और कई queue में वितरित किया जा सकता है।

उदाहरण के लिए,

kafka संदेशों को topic में विभाजित करता है।
और इस topic को पुनः कई partition में विभाजित किया गया है।
और ग्राहक पक्ष पर, कई worker consumer समूहों के माध्यम से एक संदेश का उपयोग कर सकते हैं।

RabbitMQ में एक्सचेंज और queue शामिल हैं।
एक्सचेंज रूटिंग निर्धारित करते हैं कि किस queue संदेश वितरित किए जाते हैं।
Rabbitmq में 4 प्रकार के एक्सचेंज हैं: डायरेक्ट, फैनआउट, topic और हेडर।
संदेशों को न केवल विभिन्न एक्सचेंजों को अग्रेषित किया जा सकता है, बल्कि एक्सचेंज से एक्सचेंज तक रूटिंग भी की जा सकती है।
kafka की तुलना में, RabbitMQ में एक बहुत ही लचीला और सुविधाजनक संदेश रूटिंग डिज़ाइन है।

इसके बजाय, क्योंकि RabbitMQ queue है, यदि consumer queue से संदेश को हटा देता है, तो संदेश queue से हटा दिया जाता है।
दूसरी ओर, kafka में, भंडारण इकाइयाँ topic और partition हैं, queue नहीं।
topic एक तार्किक इकाई है जो संदेशों को अलग करता है, और एक इकाई जो वास्तव में संग्रहीत होती है वह partition है।
इसके अलावा, जब consumer partition से संदेशों का उपभोग करता है, तो यह queue जैसे संदेशों को नहीं हटाता है।
एक विशिष्ट offset याद रखें और offset के बाद डेटा की सदस्यता लें। यह एक सरणी की तरह है।

इस अंतर में, RabbitMQ कई ग्राहकों को एक queue में संलग्न कर सकता है, लेकिन kafka केवल एक consumer समूह को एक partition में संलग्न कर सकता है।

दोनों के बीच का अंतर स्टोरेज में भी अंतर है।
RabbitMQ ज्यादातर मेमोरी में होता है और kafka डिस्क पर होता है।

इसलिए हम kafka का उपयोग डेटाबेस की तरह लगातार डेटा स्टोर के रूप में करते हैं।

मैसेजिंग सिस्टम के डिजाइन के आधार पर व्यवहार में यह अंतर मैसेजिंग सिस्टम के डिजाइन में परिलक्षित होता है।
rabbit mq का उद्देश्य message कतारबद्ध करना है।
तो kafka की तुलना में, रूटिंग और queue निर्माण और विलोपन के बारे में संदेश कतार बहुत लचीला है।
kafka का लक्ष्य रैबिटमैक की तुलना में बड़े संदेश प्रसंस्करण के लिए है।
इसलिए, RabbitMQ की तुलना में, बड़े पैमाने पर काम करने के लिए इसका बेहतर प्रदर्शन है।

ऊपर, हमने वितरित मैसेजिंग सिस्टम को देखा और संक्षेप में RabbitMQ और kafka को देखा।
हम कोड के माध्यम से kafka और रैबिटमैक पर करीब से नज़र डालेंगे।

अंत में, हमने मैसेजिंग सिस्टम का उपयोग करने के 5 कारणों का सारांश दिया है।

1. संचार: डेटा publisher और ग्राहक के बीच पारित किया जा सकता है। यह आपको विभिन्न भाषाओं, प्लेटफार्मों और विषमताओं के बीच की बाधाओं से मुक्त करता है।
2. अतुल्यकालिक: तुल्यकालिक संचार की तुलना में, अतुल्यकालिक संचार प्रक्रियात्मक संचार की तुलना में प्रदर्शन बढ़ा सकता है।
3. उच्च उपलब्धता: एक वितरित मैसेजिंग सिस्टम में, कुछ मैसेजिंग सिस्टम के डाउन होने पर भी सामान्य ऑपरेशन की गारंटी होती है, हालांकि प्रदर्शन में गिरावट आ सकती है।
4. पुन: प्रयास करें: भले ही worker नीचे जाता है, संदेश queue में रहता है, इसलिए यदि worker वापस ऊपर आता है, तो यह पिछले विफल ऑपरेशन के बाद भी जारी रह सकता है। भले ही रीयल-टाइम कम हो, डेटा की स्थिरता विश्वसनीय हो जाती है।
5. लूज कपलिंग: डायरेक्ट कॉल के बजाय मैसेजिंग सिस्टम के माध्यम से अप्रत्यक्ष कॉल के माध्यम से, publisher पक्ष को संदेश प्रकाशन के बाद सभी व्यावसायिक तर्क जानने की आवश्यकता नहीं होती है। प्रकाशन तक केवल publisher की ही भूमिका होती है। मैसेजिंग सिस्टम के जरिए सब्सक्राइबर को मैसेज डिलीवर किया जाता है। अब यह सब्सक्राइबर है जो संदेश को संभालने के लिए जिम्मेदार है। प्रत्यक्ष के बजाय अप्रत्यक्ष, publisher कॉल के माध्यम से हासिल किया गया ढीला युग्मन हमारे सॉफ़्टवेयर को अधिक लचीला और स्केलेबल बनाता है।

सब्सक्राइब और लाइक नोटिफिकेशन सेटिंग्स कंटेंट क्रिएटर्स के लिए बहुत मददगार हैं।

धन्यवाद