संदेश दलालों को समझना। ActiveMQ और Kafka के माध्यम से संदेश भेजने के यांत्रिकी सीखना। अध्याय 2. ActiveMQ

एक छोटी सी पुस्तक के अनुवाद की निरंतरता:
"मैसेज ब्रोकर्स को समझना",
लेखक: जैकब कोरब, प्रकाशक: ओ'रेली मीडिया, इंक।, प्रकाशन तिथि: जून २०१ab, आईएसबीएन: ९ 4929१४ ९ २०४ ९ २ ९ ६६।

अनुवाद पूरा हुआ

पिछला भाग: मैसेज ब्रोकर्स को समझना ActiveMQ और Kafka के माध्यम से संदेश के मैकेनिक्स सीखना। अध्याय 1. परिचय

अध्याय २

ActiveMQ

ActiveMQ को सबसे अच्छा क्लासिक संदेश प्रणाली के रूप में वर्णित किया गया है। यह 2004 में एक ओपन सोर्स मैसेज ब्रोकर की जरूरत को भरने के लिए लिखा गया था। उस समय, यदि आप अपने अनुप्रयोगों में संदेश का उपयोग करना चाहते थे, तो एकमात्र विकल्प महंगे वाणिज्यिक उत्पाद थे।

ActiveMQ को जावा संदेश सेवा (JMS) विनिर्देश के कार्यान्वयन के रूप में विकसित किया गया था। यह निर्णय एक ओपन सोर्स J2EE एप्लिकेशन सर्वर अपाचे गेरोनिमो परियोजना में जेएमएस-अनुरूप संदेश को लागू करने के लिए आवश्यकताओं को पूरा करने के लिए किया गया था।
एक संदेश प्रणाली (या संदेश-उन्मुख मिडलवेयर, जैसा कि कभी-कभी कहा जाता है) कि जेएमएस विनिर्देश में निम्नलिखित घटक शामिल हैं:

दलाल

संदेशों को वितरित करने वाले मिडलवेयर का एक केंद्रीय टुकड़ा।

ग्राहक

सॉफ्टवेयर का वह टुकड़ा जो किसी ब्रोकर के माध्यम से संदेश भेजता है। यह, बदले में, निम्नलिखित कलाकृतियों में शामिल हैं:

• JMS API का उपयोग करके कोड।
• जेएमएस एपीआई जेएमएस विनिर्देश में आगे की गारंटी के अनुसार एक दलाल के साथ बातचीत करने के लिए इंटरफेस का एक सेट है।
• सिस्टम का क्लाइंट लाइब्रेरी जो एपीआई के कार्यान्वयन को प्रदान करता है और ब्रोकर के साथ बातचीत करता है।

क्लाइंट और ब्रोकर एक दूसरे के साथ एप्लिकेशन लेयर प्रोटोकॉल के माध्यम से संवाद करते हैं, जिसे इंटरैक्शन प्रोटोकॉल (चित्र। 2-1) के रूप में भी जाना जाता है। जेएमएस विनिर्देश ने विशिष्ट प्रोटोकॉल के लिए इस प्रोटोकॉल का विवरण छोड़ दिया।


चित्र 2-1। जेएमएस समीक्षा

जेएमएस, जेएमएस एपीआई के अंतर्निहित संदेश प्रणाली के विक्रेता के कार्यान्वयन का वर्णन करने के लिए शब्द प्रदाता का उपयोग करता है, जिसमें दलाल, साथ ही साथ इसके ग्राहक पुस्तकालय भी शामिल हैं।

JMS को लागू करने के पक्ष में विकल्प ActiveMQ लेखकों द्वारा किए गए कार्यान्वयन निर्णयों के दूरगामी परिणाम थे। मैसेजिंग सिस्टम के क्लाइंट की ज़िम्मेदारियों पर ब्रोकर खुद ही स्पष्ट मार्गदर्शन प्रदान करता है और जिस ब्रोकर के साथ वह संपर्क करता है, वह ब्रोकर के दायित्व को प्राथमिकता देता है और संदेश वितरित करता है। ग्राहक की मुख्य जिम्मेदारी उसके द्वारा भेजे गए संदेशों के पता (कतार या विषय) के साथ बातचीत करना है। विनिर्देशन का उद्देश्य है कि ब्रोकर के साथ एपीआई की बातचीत को अपेक्षाकृत सरल बनाना।

यह क्षेत्र, जैसा कि हम बाद में देखेंगे, ActiveMQ प्रदर्शन पर महत्वपूर्ण प्रभाव पड़ा। ब्रोकर की जटिलताओं के अलावा, सन माइक्रोसिस्टम्स द्वारा प्रदान किए गए विनिर्देश के लिए संगतता पैकेज में कई बारीकियां थीं, जिनके प्रदर्शन पर अपना प्रभाव था। ActiveMQ को JMS संगत मानने के लिए इन बारीकियों को ध्यान में रखा जाना चाहिए था।

लिंक

यद्यपि JMS विनिर्देश में API और अपेक्षित व्यवहार को अच्छी तरह से परिभाषित किया गया था, वास्तविक ग्राहक-दलाल संचार प्रोटोकॉल को जानबूझकर विनिर्देश से बाहर रखा गया था ताकि मौजूदा दलालों को JMS-अनुरूप बनाया जा सके। इस प्रकार, ActiveMQ अपने स्वयं के इंटरैक्शन प्रोटोकॉल, ओपनवायर को परिभाषित करने के लिए स्वतंत्र था। ओपनवायर का उपयोग ActiveMQ JMS क्लाइंट लाइब्रेरी कार्यान्वयन द्वारा किया जाता है, साथ ही इसके समकक्षों में .Net और C ++: NMS और CMS, जो कि ApMO सॉफ्टवेयर फाउंडेशन द्वारा होस्ट किए गए ActiveMQ उपप्रोजेक्ट हैं।

समय के साथ, अन्य इंटरैक्शन प्रोटोकॉल का समर्थन ActiveMQ में जोड़ा गया, जिससे अन्य भाषाओं और वातावरणों के साथ बातचीत करने की क्षमता बढ़ गई:

AMQP 1.0

उन्नत संदेश कतारबद्ध प्रोटोकॉल (ISO / IEC 19464: 2014) अपने पूर्ववर्ती 0.X के साथ भ्रमित नहीं होना चाहिए, जो अन्य संदेश प्रणालियों में कार्यान्वित किया जाता है, विशेष रूप से RabbitMQ में, 0.9.1 का उपयोग कर। AMQP 1.0 दो नोड्स के बीच संदेशों के आदान-प्रदान के लिए एक सामान्य-उद्देश्य बाइनरी प्रोटोकॉल है। इसमें ग्राहकों या दलालों की कोई अवधारणा नहीं है और इसमें प्रवाह नियंत्रण, लेनदेन और विभिन्न QoS (कम से कम एक बार, और ठीक एक बार) जैसे कार्य शामिल हैं।

STOMP

सरल / स्ट्रीमिंग टेक्स्ट ओरिएंटेड मैसेजिंग प्रोटोकॉल, एक आसान-से-कार्यान्वयन प्रोटोकॉल है जिसमें विभिन्न भाषाओं में दर्जनों क्लाइंट कार्यान्वयन हैं।

XMPP

एक्स्टेंसिबल मैसेजिंग और उपस्थिति प्रोटोकॉल। (एक्स्टेंसिबल मैसेजिंग एंड प्रेजेंस प्रोटोकॉल)। पूर्व में जब्बार कहा जाता है, यह एक्सएमएल-आधारित प्रोटोकॉल मूल रूप से चैट सिस्टम के लिए विकसित किया गया था, लेकिन प्रकाशन-सदस्यता संदेश शामिल करने के लिए इसके मूल उपयोग मामलों से आगे बढ़ाया गया है।

MQTT

मशीन-टू-मशीन (M2M) और इंटरनेट ऑफ थिंग्स (IoT) अनुप्रयोगों के लिए हल्के प्रकाशित-सदस्यता प्रोटोकॉल (ISO / IEC 20922: 2016) का उपयोग किया जाता है।

ActiveMQ भी WebSockets पर उपरोक्त प्रोटोकॉल को लागू करने का समर्थन करता है, जो ब्रोकर में वेब ब्राउज़र और गंतव्यों में अनुप्रयोगों के बीच पूर्ण-द्वैध डेटा विनिमय प्रदान करता है।

इसे देखते हुए, अब जब हम ActiveMQ के बारे में बात करते हैं, तो हम अब केवल JMS / NMS / CMS पुस्तकालयों और ओपनवायर प्रोटोकॉल पर आधारित इंटरैक्शन स्टैक के लिए विशेष रूप से संदर्भित नहीं करते हैं। भाषाओं, प्लेटफार्मों और बाहरी पुस्तकालयों का संयोजन और चयन जो इस एप्लिकेशन के लिए सबसे उपयुक्त हैं, तेजी से लोकप्रिय हो रहे हैं। उदाहरण के लिए, जावास्क्रिप्ट पॉकेट MQTT लाइब्रेरी का उपयोग करके ब्राउज़र में चलाने के लिए जावास्क्रिप्ट अनुप्रयोग के लिए संभव है कि वेब सॉकेट्स के माध्यम से ActiveMQ को संदेश भेजें, और ये संदेश C ++ सर्वर प्रक्रिया द्वारा पढ़े जाते हैं जो Apache Qpid Proton लाइब्रेरी के माध्यम से AMQP का उपयोग करता है। इस दृष्टिकोण से, मैसेजिंग परिदृश्य अधिक विविध होता जा रहा है।

भविष्य की तलाश में, एएमक्यूपी, विशेष रूप से, अब की तुलना में बहुत अधिक अवसर होंगे, क्योंकि घटक जो न तो ग्राहक हैं और न ही दलाल मैसेजिंग परिदृश्य का अधिक परिचित हिस्सा बन रहे हैं। उदाहरण के लिए, अपाचे क्यूपिड डिस्पैच राउटर एक संदेश राउटर के रूप में कार्य करता है, जिसके लिए क्लाइंट सीधे कनेक्ट होते हैं, जिससे विभिन्न गंतव्यों को अलग-अलग पतों को संसाधित करने की अनुमति मिलती है, साथ ही साथ शार्किंग (अलगाव) की संभावना भी प्रदान की जाती है।

तीसरे पक्ष के पुस्तकालयों और बाहरी घटकों के साथ काम करते समय, कृपया ध्यान दें कि उनके पास चर गुणवत्ता है और ActiveMQ में दिए गए कार्यों के साथ संगत नहीं हो सकती है। एक बहुत ही सरल उदाहरण के रूप में - एमक्यूटीटी के माध्यम से कतार में संदेश भेजना असंभव है (दलाल में रूटिंग स्थापित किए बिना)। इस प्रकार, आपको मैसेजिंग सिस्टम के ढेर को निर्धारित करने के लिए विकल्पों के साथ काम करने में कुछ समय बिताने की आवश्यकता होगी जो आपके आवेदन की आवश्यकताओं के लिए सबसे उपयुक्त है।

प्रदर्शन और विश्वसनीयता के बीच व्यापार

ActiveMQ में पॉइंट-टू-पॉइंट मैसेजिंग कैसे काम करता है, इसके बारे में विस्तार से बताने से पहले, हमें इस बारे में थोड़ी बात करने की ज़रूरत है कि भारी डेटा प्रोसेसिंग फेस वाले सभी सिस्टम: प्रदर्शन और विश्वसनीयता के बीच एक व्यापार-बंद है।

कोई भी सिस्टम जो डेटा को स्वीकार करता है, चाहे वह एक संदेश दलाल या डेटाबेस हो, को निर्देश दिया जाना चाहिए कि विफलता की स्थिति में इस डेटा को कैसे संसाधित किया जाए। असफलता कई रूप ले सकती है, लेकिन सादगी के लिए हम इसे एक ऐसी स्थिति में सीमित कर देंगे, जहां सिस्टम शक्ति खो देता है और तुरंत नीचे गिर जाता है। इस स्थिति में, हमें यह अनुमान लगाने की आवश्यकता है कि सिस्टम में मौजूद डेटा का क्या होगा। यदि डेटा (इस मामले में, संदेश) मेमोरी में या लोहे के अस्थिर हिस्से में था, उदाहरण के लिए, कैश में, तो यह डेटा खो जाएगा। हालांकि, यदि डेटा को गैर-वाष्पशील भंडारण के लिए भेजा गया था, उदाहरण के लिए डिस्क पर, यह तब उपलब्ध होगा जब सिस्टम काम पर लौट आएगा।

इस दृष्टिकोण से, यह समझ में आता है कि यदि हम एक दलाल की विफलता की स्थिति में संदेश खोना नहीं चाहते हैं, तो हमें उन्हें स्थायी भंडारण पर लिखने की आवश्यकता है। दुर्भाग्य से, इस विशेष समाधान की लागत काफी अधिक है।

ध्यान दें कि डिस्क पर डेटा की मेगाबाइट लिखने के बीच का अंतर मेमोरी लिखने की तुलना में 100-1000 गुना धीमा है। इसलिए, एप्लिकेशन डेवलपर को यह तय करना होगा कि संदेश की विश्वसनीयता प्रदर्शन के नुकसान के लायक है या नहीं। उपयोग परिदृश्य के आधार पर इस तरह के निर्णय किए जाने चाहिए।

प्रदर्शन और विश्वसनीयता के बीच का व्यापार विकल्प की एक श्रृंखला पर आधारित है। विश्वसनीयता जितनी अधिक होगी, प्रदर्शन उतना ही कम होगा। यदि आप सिस्टम को कम विश्वसनीय बनाने का निर्णय लेते हैं, उदाहरण के लिए, केवल मेमोरी में संदेशों को संग्रहीत करना, आपकी उत्पादकता में काफी वृद्धि होगी। डिफ़ॉल्ट रूप से, JMS को विश्वसनीयता के लिए ActiveMQ को बॉक्स से बाहर करने के लिए कॉन्फ़िगर किया गया है। ऐसे कई तंत्र हैं जो आपको ब्रोकर को कॉन्फ़िगर करने और इस स्पेक्ट्रम की स्थिति में उसके साथ बातचीत करने की अनुमति देते हैं जो मैसेजिंग सिस्टम का उपयोग करने के विशिष्ट परिदृश्यों के लिए सबसे उपयुक्त है।

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

बचत संदेश

ActiveMQ कई प्लगेबल संदेश प्रतिधारण रणनीतियों के साथ आता है। वे दृढ़ता (दृढ़ता) एडेप्टर के रूप में आते हैं, जिसे संदेश भंडारण इंजन के रूप में माना जा सकता है। इनमें काहेडबी और लेवलबीडी जैसे डिस्क-आधारित समाधान शामिल हैं, साथ ही जेडीबीसी के माध्यम से डेटाबेस का उपयोग करने की क्षमता भी शामिल है। चूंकि पूर्व का सबसे अधिक उपयोग किया जाता है, हम उन पर अपनी चर्चा केंद्रित करेंगे।

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

दृढ़ता डिस्क एडेप्टर सूचकांक फ़ाइलों का समर्थन करते हैं जो ट्रैक करते हैं जहां लॉग में निम्नलिखित अग्रेषित संदेश स्थित हैं। जब लॉग फ़ाइल के सभी संदेश पढ़े जाते हैं, तो उन्हें या तो हटा दिया जाएगा या ActiveMQ पृष्ठभूमि वर्कफ़्लो द्वारा संग्रहीत किया जाएगा। यदि यह लॉग ब्रोकर की विफलता के दौरान क्षतिग्रस्त है, तो ActiveMQ लॉग फ़ाइलों में जानकारी के आधार पर इसका पुनर्निर्माण करेगा।

सभी कतारों के संदेश एक ही लॉग फ़ाइलों को लिखे जाते हैं, जिसका अर्थ है कि यदि एक संदेश नहीं पढ़ा जाता है, तो संपूर्ण फ़ाइल (आमतौर पर डिफ़ॉल्ट 32 एमबी या 100 एमबी है, दृढ़ता एडाप्टर के आधार पर) को मंजूरी नहीं दी जा सकती है। यह समय के साथ कम डिस्क स्थान की समस्या पैदा कर सकता है।

क्लासिक संदेश दलाल लंबे समय तक भंडारण के लिए डिज़ाइन नहीं किए गए हैं - अपने संदेशों को पढ़ें!

लॉग को संग्रहीत करने और बाद में संदेशों को पुनर्प्राप्त करने के लिए एक अत्यंत कुशल तंत्र है, क्योंकि डिस्क का उपयोग दोनों कार्यों के लिए अनुक्रमिक है। पारंपरिक हार्ड डिस्क पर, यह सिलेंडर द्वारा डिस्क खोज की संख्या को कम करता है, क्योंकि डिस्क पर सिर बस डिस्क के घूर्णन सब्सट्रेट पर सेक्टर पढ़ना या लिखना जारी रखते हैं। इसी तरह, SSDs पर, अनुक्रमिक पहुंच यादृच्छिक पहुँच की तुलना में बहुत तेज़ है, क्योंकि पूर्व में ड्राइव के मेमोरी पेजों का बेहतर उपयोग होता है।

डिस्क प्रदर्शन कारक

ऐसे कई कारक हैं जो उस गति को निर्धारित करते हैं जिस पर डिस्क काम कर सकती है। इसे समझने के लिए, एक पाइप के सरलीकृत मानसिक मॉडल ( चित्रा 2-2 ) के माध्यम से एक डिस्क को लिखने की विधि पर विचार करें।


चित्र 2-2। डिस्क प्रदर्शन ट्यूब मॉडल

एक पाइप के तीन आयाम होते हैं:

लंबाई

एक ऑपरेशन को पूरा करने के लिए अपेक्षित विलंबता के अनुरूप। अधिकांश स्थानीय ड्राइव के लिए, यह बहुत अच्छा है, लेकिन यह क्लाउड वातावरण में एक प्रमुख सीमित कारक बन सकता है जहां स्थानीय ड्राइव वास्तव में ऑनलाइन है। उदाहरण के लिए, लेखन के समय (अप्रैल 2017), अमेज़ॅन गारंटी देता है कि उनके ईबीएस स्टोरेज को लिखना "2 एमएस से कम होगा।" यदि हम क्रमिक रूप से रिकॉर्ड करते हैं, तो यह प्रति सेकंड 500 रिकॉर्ड की अधिकतम सीमा देता है।

चौड़ाई

किसी एकल ऑपरेशन की वहन क्षमता या बैंडविड्थ को निर्धारित करता है। फ़ाइल सिस्टम कैश डिस्क पर किए गए बड़े लेखन कार्यों के एक छोटे सेट में कई छोटे रिकॉर्डों को मिलाकर इस संपत्ति का उपयोग करता है।

समय के साथ बैंडविड्थ

यह विचार उन घटनाओं की एक श्रृंखला के रूप में प्रस्तुत किया जाता है जो एक ही समय में पाइप में हो सकते हैं, IOPS नामक एक मीट्रिक (प्रति सेकंड I / O संचालन की संख्या) द्वारा व्यक्त किया गया है। IOPS का उपयोग आमतौर पर प्रदर्शन को मापने के लिए भंडारण निर्माताओं और क्लाउड प्रदाताओं द्वारा किया जाता है। हार्ड ड्राइव में अलग-अलग संदर्भों में अलग-अलग IOPS मान होंगे: क्या कार्यभार में मुख्य रूप से पढ़ने, लिखने या इनमें से एक संयोजन है, और क्या ये ऑपरेशन अनुक्रमिक, मनमाना या मिश्रित हैं। आईओपीएस माप जो ब्रोकर के दृष्टिकोण से सबसे दिलचस्प हैं, क्रमिक पढ़ने और लिखने के संचालन हैं, क्योंकि वे लॉग के लॉग को पढ़ने और लिखने के अनुरूप हैं।

एक संदेश ब्रोकर का अधिकतम थ्रूपुट इन प्रतिबंधों में से पहली की उपलब्धि से निर्धारित होता है , और ब्रोकर कॉन्फ़िगरेशन काफी हद तक डिस्क के साथ बातचीत करने के तरीके पर निर्भर करता है। यह न केवल कैसे का एक कारक है, उदाहरण के लिए, ब्रोकर कॉन्फ़िगर किया गया है, बल्कि यह भी निर्भर करता है कि निर्माता ब्रोकर के साथ कैसे बातचीत करते हैं। जैसा कि प्रदर्शन से जुड़ी हर चीज के साथ होता है, एक प्रतिनिधि कार्यभार (यानी, वास्तविक संदेशों के जितना करीब हो) पर ब्रोकर का परीक्षण करना आवश्यक है और वास्तविक संग्रहण कॉन्फ़िगरेशन पर जो कि PROM में उपयोग किया जाएगा। यह समझने के लिए किया जाता है कि सिस्टम वास्तविकता में कैसे व्यवहार करेगा।

जेएमएस एपीआई

इससे पहले कि हम ActiveMQ ग्राहकों के साथ कैसे संवाद करते हैं, के विवरण में जाने के लिए, हमें सबसे पहले JMS API सीखना होगा। API क्लाइंट कोड द्वारा उपयोग किए जाने वाले प्रोग्रामिंग इंटरफेस के एक सेट को परिभाषित करता है:

ConnectionFactory

यह ब्रोकर के साथ कनेक्शन स्थापित करने के लिए उपयोग किया जाने वाला शीर्ष-स्तरीय इंटरफ़ेस है। एक सामान्य संदेश अनुप्रयोग में, इस इंटरफ़ेस का केवल एक उदाहरण है। ActiveMQ में, यह एक ActiveMQConnectionFactory है। शीर्ष स्तर पर, यह डिज़ाइन संदेश दलाल के स्थान को बताता है, साथ ही निम्न-स्तरीय विवरणों के साथ कि इसके साथ कैसे संपर्क करें। जैसा कि नाम से ही स्पष्ट है, ConnectionFactory वह तंत्र है जिसके द्वारा कनेक्शन ऑब्जेक्ट बनाए जाते हैं।

संबंध

यह एक लंबे समय तक रहने वाली वस्तु है जो लगभग टीसीपी कनेक्शन जैसा दिखता है - निर्माण के बाद, यह आमतौर पर आवेदन के पूरे जीवन चक्र में मौजूद होता है जब तक कि यह बंद नहीं होता है। कनेक्शन थ्रेड सुरक्षित है और एक साथ कई थ्रेड्स के साथ काम कर सकता है। कनेक्शन ऑब्जेक्ट आपको सत्र ऑब्जेक्ट बनाने की अनुमति देते हैं।

अधिवेशन

ब्रोकर के साथ बातचीत करते समय यह एक स्ट्रीम हैंडल है। सत्र ऑब्जेक्ट्स थ्रेड सुरक्षित नहीं हैं, जिसका अर्थ है कि उन्हें एक ही समय में कई थ्रेड्स द्वारा एक्सेस नहीं किया जा सकता है। सत्र मुख्य लेन-देन विवरणक होता है जिसके साथ प्रोग्रामर कमिट कर सकता है और यदि वह ट्रांजेक्शनल मोड में है तो रोलबैक मैसेज कर सकता है। इस ऑब्जेक्ट का उपयोग करके, आप Message, MessageConsumer और MessageProducer ऑब्जेक्ट बनाते हैं, और Topic और Queue ऑब्जेक्ट्स को पॉइंटर्स (डिस्क्रिप्टर) भी प्राप्त करते हैं।

MessageProducer

यह इंटरफ़ेस आपको प्राप्तकर्ता को एक संदेश भेजने की अनुमति देता है।

MessageConsumer

यह इंटरफ़ेस डेवलपर को संदेश प्राप्त करने की अनुमति देता है। दो संदेश पुनर्प्राप्ति तंत्र हैं:

• MessageListener रजिस्टर करें। यह आपके द्वारा लागू किया गया संदेश हैंडलर इंटरफ़ेस है, जो एक धारा का उपयोग करके दलाल द्वारा जारी किए गए किसी भी संदेश को क्रमिक रूप से संसाधित करेगा।
• प्राप्त () विधि का उपयोग कर संदेशों के लिए मतदान।

संदेश

यह संभवतः सबसे महत्वपूर्ण संरचना है क्योंकि यह आपके डेटा को स्थानांतरित करता है। जेएमएस में संदेश दो पहलुओं से मिलकर बनता है:

• संदेश मेटाडेटा। संदेश में हेडर और गुण शामिल हैं। दोनों कि, और कहा कि एक नक्शे के तत्वों के रूप में माना जा सकता है। हेडर्स जेएमएस विनिर्देश द्वारा परिभाषित और एलएमएस के माध्यम से सीधे उपलब्ध जेएमडेस्टीनेशन और जेएमएसटीमस्टैम्प जैसे प्रसिद्ध तत्व हैं। गुण संदेश की जानकारी के अनियंत्रित टुकड़े हैं जो संदेश पेलोड को स्वयं पढ़े बिना संदेशों के प्रसंस्करण या मार्ग को सरल बनाने के लिए निर्धारित हैं। उदाहरण के लिए, आप हेडर को खाता या ऑर्डरटाइप पर सेट कर सकते हैं।
• संदेश शरीर। सत्र से, शरीर में भेजे जाने वाले सामग्री के प्रकार के आधार पर कई अलग-अलग प्रकार के संदेश बनाए जा सकते हैं, जिनमें से सबसे आम हैं स्ट्रिंग्स के लिए टेक्स्टमैसेज और बाइनरी डेटा के लिए बाइट्समैसेज।

कैसे काम करता है: दो दिमाग की कहानी

एक उपयोगी, यद्यपि गलत, ActiveMQ कार्य का मॉडल मस्तिष्क के दो हिस्सों का एक मॉडल है। एक हिस्सा निर्माता से संदेश प्राप्त करने के लिए जिम्मेदार है, और दूसरा इन संदेशों को उपभोक्ताओं को भेजता है। प्रदर्शन अनुकूलन उद्देश्यों के लिए संबंध वास्तव में अधिक जटिल हैं, लेकिन एक बुनियादी समझ के लिए मॉडल पर्याप्त है।

कतार में संदेश भेजना

आइए एक संदेश भेजते समय होने वाली बातचीत को देखें। चित्र 2-3 हमें उस प्रक्रिया का सरलीकृत मॉडल दिखाता है जिसके द्वारा दलाल द्वारा संदेश प्राप्त किए जाते हैं। यह पूरी तरह से प्रत्येक मामले में व्यवहार के अनुरूप नहीं है, लेकिन यह बुनियादी समझ पाने के लिए काफी उपयुक्त है।


चित्र 2-3। जेएमएस को संदेश भेजना

एक क्लाइंट एप्लिकेशन में, थ्रेड को एक संदेशप्रदाता को पॉइंटर प्राप्त होता है। यह एक अनुमानित संदेश पेलोड के साथ एक संदेश बनाता है और संदेश के अंतिम गंतव्य के रूप में कतार के साथ MessageProducer.send ("आदेश", संदेश) को कॉल करता है। चूंकि प्रोग्रामर संदेश को खोना नहीं चाहता है यदि ब्रोकर टूट गया, तो संदेश शीर्षलेख JMSDeliveryMode को PERSISTENT (डिफ़ॉल्ट व्यवहार) पर सेट किया गया था।

इस बिंदु (1) पर, भेजने वाली स्ट्रीम क्लाइंट लाइब्रेरी को कॉल करती है और ओपनवायर प्रारूप में संदेश को मार्शल्स करती है। फिर दलाल को संदेश भेजा जाता है।

ब्रोकर में, प्राप्त करने वाली धारा लाइन से संदेश को हटा देती है और इसे आंतरिक ऑब्जेक्ट पर अनमर्श करती है। फिर, संदेश ऑब्जेक्ट दृढ़ता एडाप्टर के लिए प्रेषित किया जाता है, जो Google प्रोटोकॉल बफ़र्स प्रारूप का उपयोग करके संदेश को मार्शल करता है और इसे स्टोरेज (2) में लिखता है।
संदेश को स्टोरेज में रिकॉर्ड करने के बाद, दृढ़ता एडेप्टर को यह पुष्टि प्राप्त करनी चाहिए कि संदेश वास्तव में रिकॉर्ड किया गया था (3)। यह आमतौर पर पूरी बातचीत का सबसे धीमा हिस्सा है; इस पर बाद में।

जैसे ही ब्रोकर यह सुनिश्चित करता है कि संदेश सहेज लिया गया है, वह ग्राहक को एक पुष्टिकरण प्रतिक्रिया (4) भेजेगा। उसके बाद, क्लाइंट थ्रेड जिसे मूल रूप से सेंड () ऑपरेशन कहा जाता है, अपना काम जारी रख सकता है।

लगातार संदेशों की यह लंबित पुष्टि जेएमएस एपीआई द्वारा प्रदान की गई गारंटी का आधार है - यदि आप चाहते हैं कि संदेश सहेजा जाए, तो संभवतः यह आपके लिए भी महत्वपूर्ण है कि क्या संदेश पहले दलाल द्वारा प्राप्त किया गया था। कई कारण हैं कि यह संभव नहीं हो सकता है, उदाहरण के लिए, एक मेमोरी या डिस्क सीमा तक पहुंच गया है। विफलता के बजाय, दलाल या तो भेजने के संचालन को निलंबित कर देता है, निर्माता को प्रतीक्षा करने के लिए मजबूर करता है जब तक कि संदेश को संसाधित करने के लिए पर्याप्त सिस्टम संसाधन उपलब्ध न हों (निर्माता प्रवाह नियंत्रण नामक एक प्रक्रिया), या वह अपवाद को फेंकते हुए निर्माता को एक नकारात्मक पुष्टि भेजेगा। सटीक व्यवहार प्रत्येक दलाल के लिए अनुकूलन योग्य है।

इस सरल ऑपरेशन में, I / O इंटरैक्शन की एक महत्वपूर्ण संख्या होती है: निर्माता और दलाल के बीच दो नेटवर्क संचालन, एक सेव ऑपरेशन और एक पुष्टिकरण कदम। स्टोरेज सर्वर पर सेव ऑपरेशन डिस्क या किसी अन्य नेटवर्क संक्रमण के लिए एक सरल लेखन हो सकता है।

यह संदेश दलालों के बारे में एक महत्वपूर्ण सवाल उठाता है: उनका काम I / O संचालन की एक अत्यंत गहन धारा के साथ जुड़ा हुआ है और वे विशेष रूप से डिस्क के लिए उपयोग किए जाने वाले बुनियादी ढांचे के प्रति बहुत संवेदनशील हैं।

आइए उपरोक्त बातचीत में पुष्टि कदम (3) पर करीब से नज़र डालें। यदि दृढ़ता एडेप्टर फ़ाइल-आधारित है, तो संदेश को संग्रहीत करना फ़ाइल सिस्टम में लिखना शामिल है। यदि ऐसा है, तो मुझे यह पुष्टि करने की आवश्यकता क्यों है कि लेखन ऑपरेशन पूरा हो गया है? क्या रिकॉर्डिंग पूरी करने के कार्य का वास्तव में मतलब है कि रिकॉर्डिंग हुई है?
वास्तव में नहीं।जैसा कि आमतौर पर होता है, आप किसी चीज का जितना गहरा अध्ययन करते हैं, वह उतनी ही जटिल होती जाती है। इस विशेष मामले में, कैशिंग अपराधी है ।

हर जगह कैश, कैश

जब एक ऑपरेटिंग सिस्टम प्रक्रिया, जैसे कि ब्रोकर डिस्क पर डेटा लिखते हैं, तो यह फाइल सिस्टम के साथ इंटरैक्ट करता है। एक फाइल सिस्टम एक ऐसी प्रक्रिया है जो उपयोग किए गए स्टोरेज माध्यम के साथ इंटरैक्शन के विवरण को सार करती है, फाइल ऑपरेशन जैसे कि OPEN, CLOSE, READ और WRITE प्रदान करती है। इनमें से एक कार्य ऑपरेटिंग सिस्टम द्वारा लिखित डेटा को उन ब्लॉकों में बफ़र करके लेखन कार्यों की संख्या को कम करना है जिन्हें एक दृष्टिकोण में डिस्क में सहेजा जा सकता है। फ़ाइल सिस्टम लिखने का संचालन जो दिखता है जैसे वे डिस्क के साथ बातचीत करते हैं, वास्तव में इस बफर कैश में लिखे जाते हैं ।

वैसे, आपके कंप्यूटर की शिकायत तब होती है जब आप किसी USB ड्राइव को अनसैच करते हैं - आपके द्वारा कॉपी की गई फाइलें वास्तव में नहीं लिखी जा सकती हैं!
जैसे ही डेटा बफर कैश से आगे जाता है, यह कैशिंग के अगले स्तर पर जाता है, इस बार हार्डवेयर स्तर पर - डिस्क नियंत्रक कैश । वे विशेष रूप से RAID आधारित प्रणालियों के लिए महत्वपूर्ण हैं और ऑपरेटिंग सिस्टम स्तर पर कैशिंग के समान कार्य करते हैं: स्वयं ड्राइव के लिए आवश्यक इंटरैक्शन की संख्या को कम करें। ये कैश दो श्रेणियों में आते हैं:

राइट-थ्रू राइट रिसीव

करने पर तुरंत डिस्क में ट्रांसफर हो जाते हैं।

Writeback (लिखने-वापस)

रिकॉर्डिंग केवल डिस्क पर की जाती है जब बफर पूर्ण होता है एक निश्चित सीमा मूल्य पर पहुंचता है।

इन कैश में संग्रहीत डेटा को बिजली की विफलता के दौरान आसानी से खो दिया जा सकता है, क्योंकि वे जिस मेमोरी का उपयोग करते हैं वह आमतौर पर अस्थिर (अस्थिर) है । अधिक महंगे कार्ड में निरर्थक बैटरी पैक (BBU) होते हैं जो कैश पावर का समर्थन करते हैं जब तक कि पूरा सिस्टम पावर बहाल नहीं कर सकता है, जिसके बाद डेटा डिस्क पर लिखा जाएगा।
पिछले कैश स्तर स्वयं डिस्क पर है। डिस्क कैशहार्ड ड्राइव पर (दोनों मानक हार्ड ड्राइव पर और ठोस राज्य ड्राइव पर) स्थित है और या तो राइट-थ्रू या राइट-बैक हो सकता है। अधिकांश वाणिज्यिक ड्राइव राइट-बैक कैश का उपयोग करते हैं और अस्थिर होते हैं, जिसका अर्थ है कि बिजली की विफलता की स्थिति में डेटा खो सकता है।

संदेश ब्रोकर के पास लौटने पर, आपको यह सुनिश्चित करने के लिए पुष्टिकरण चरण को पूरा करना होगा कि डेटा वास्तव में डिस्क तक पहुंच गया है। दुर्भाग्य से, इन हार्डवेयर बफ़र्स के साथ बातचीत फ़ाइल सिस्टम पर निर्भर करती है, इसलिए ActiveMQ जैसी एक प्रक्रिया फ़ाइल सिस्टम को एक संकेत भेजती है कि वह उपयोग में डिवाइस के साथ सभी सिस्टम बफ़र्स को सिंक्रनाइज़ करना चाहती है। ऐसा करने के लिए, दलाल java.io.FileDescriptor.sync () विधि को कॉल करता है, जो बदले में, POSIX fsync () ऑपरेशन शुरू करता है।

यह सिंक्रोनाइज़ेशन व्यवहार जेएमएस की एक आवश्यकता है, यह सुनिश्चित करने के लिए कि निरंतर के रूप में चिह्नित सभी संदेश वास्तव में डिस्क पर सहेजे जाते हैं और इसलिए लेनदेन में प्रत्येक संदेश या संबंधित संदेशों के सेट प्राप्त होने के बाद निष्पादित किया जाता है। इसलिए, जिस गति पर एक डिस्क सिंक को निष्पादित कर सकता है () ब्रोकर के प्रदर्शन के लिए महत्वपूर्ण है।

आंतरिक संघर्ष

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

प्रत्येक संदेश अगले संदेश को संसाधित करने से पहले पूरी तरह से रिकॉर्ड और सिंक्रनाइज़ किया जाना चाहिए। यह प्रतिबंध एक ही समय में ब्रोकर की सभी कतारों को प्रभावित करता है। इस प्रकार, किसी संदेश को कितनी जल्दी प्राप्त किया जा सकता है, इसकी गति डिस्क को लिखने में लगने वाला समय है, साथ ही रिकॉर्डिंग को समाप्त करने के लिए अन्य धाराओं के लिए किसी भी प्रतीक्षा समय की।

ActiveMQ में एक लिखित बफ़र शामिल है, जिसमें प्राप्त करने वाले स्ट्रीम अपने संदेश लिखते हैं, पिछली रिकॉर्डिंग के पूरा होने की प्रतीक्षा कर रहे हैं। जब संदेश उपलब्ध हो जाता है तब बफर को एक कार्रवाई में लिखा जाता है। पूरा होने पर, थ्रेड्स को सूचित किया जाता है। इस प्रकार, ब्रोकर स्टोरेज बैंडविड्थ के उपयोग को अधिकतम करता है।

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

लेन-देन

सभी कतारों के लिए एकल पत्रिका का उपयोग करने का लाभ यह है कि दलाल के लेखकों के दृष्टिकोण से, लेनदेन को लागू करना बहुत आसान है।

आइए एक उदाहरण देखें जहां एक निर्माता द्वारा कई कतारों में कई संदेश भेजे जाते हैं। लेनदेन का उपयोग करने का मतलब है कि भेजे जाने वाले संदेशों के पूरे सेट को एक परमाणु संचालन के रूप में माना जाना चाहिए। इस इंटरैक्शन में, ActiveMQ क्लाइंट लाइब्रेरी कुछ अनुकूलन करने में सक्षम है जो भेजने की गति में काफी वृद्धि करेगा। चित्रा 2-4

में दिखाए गए ऑपरेशन मेंनिर्माता तीन संदेश भेजता है, सभी अलग-अलग कतारों में। ब्रोकर के साथ सामान्य बातचीत के बजाय, जब प्रत्येक संदेश की पुष्टि हो जाती है, तो क्लाइंट सभी तीन संदेशों को अतुल्यकालिक रूप से भेजता है, अर्थात् प्रतिक्रिया की प्रतीक्षा किए बिना। ये संदेश ब्रोकर की मेमोरी में संग्रहीत किए जाते हैं। जैसे ही ऑपरेशन पूरा हो जाता है, निर्माता अपने सत्रों को प्रतिबद्ध करने की आवश्यकता के बारे में सूचित करता है, जो बदले में दलाल को एक सिंक्रनाइज़ेशन ऑपरेशन के साथ एक बड़ा रिकॉर्ड करने के लिए मजबूर करता है।


चित्र 2-4। लेन-देन

में संदेश भेजना इस प्रकार के संचालन में, ActiveMQ गति बढ़ाने के लिए दो अनुकूलन का उपयोग करता है:

• निर्माता द्वारा अगले प्रेषण से पहले प्रतीक्षा समय निकालना संभव हो जाता है
• कई छोटे डिस्क संचालन को एक बड़े में संयोजित करना - यह आपको डिस्क बस के पूरे बैंडविड्थ का उपयोग करने की अनुमति देता है

यदि हम इसकी तुलना उस स्थिति से करते हैं जब प्रत्येक कतार अपने लॉग में संग्रहीत होती है, तो ब्रोकर को सभी रिकॉर्डों के बीच लेन-देन के समन्वय जैसा कुछ प्रदान करना होगा।

कतार से संदेशों को घटाना

, MessageListener , MessageConsumer.receive () ( Figure 2-5 ).


Figure 2-5. JMS

ActiveMQ , (ActiveMQ) (pages) (1). (dispatched) (2), . , .

, , , , प्रीफ़ेच बफर (प्रीफ़ेच बफर) । इस बफ़र का उद्देश्य संदेश प्रवाह को सुव्यवस्थित करना है ताकि दलाल पर्यवेक्षक को संदेश जारी कर सके क्योंकि वे भेजने के लिए उपलब्ध हो जाते हैं, जबकि उपभोक्ता उन्हें एक समय में एक आदेश प्राप्त कर सकता है।

प्रीफ़ैच बफर में जाने के बाद कुछ बिंदु पर, संदेश एप्लिकेशन लॉजिक (एक्स) द्वारा पढ़े जाते हैं और प्रूफरीड की पुष्टि दलाल (3) को भेजी जाती है। संदेश प्रसंस्करण और पुष्टि के बीच के समय को जेएमएस सत्र पैरामीटर जिसे पावती मोड कहा जाता है , का उपयोग करके कॉन्फ़िगर किया गया है , जिसके बारे में हम थोड़ी देर बाद चर्चा करेंगे।
जैसे ही ब्रोकर मैसेज डिलीवरी कन्फर्मेशन स्वीकार करता है, उसे मैमोरी से और मैसेज स्टोर (4) से डिलीट कर दिया जाता है। शब्द "विलोपन" कुछ भ्रामक है, क्योंकि वास्तव में एक पुष्टि रिकॉर्ड पत्रिका को लिखा जाता है और सूचकांक में वृद्धि होती है। संदेश वाली लॉग फ़ाइल का वास्तविक विलोपन इस जानकारी के आधार पर बैकग्राउंड थ्रेड में गारबेज कलेक्टर द्वारा किया जाएगा।

. , ActiveMQ (page) , , . , , , . , , . (coherency) — , ActiveMQ , Kafka, .

विभिन्न पुष्टिकरण मोड, जो प्रूफरीडिंग और पुष्टिकरण के बीच के आदेश को निर्धारित करते हैं, ग्राहक में किस तर्क को लागू करने की आवश्यकता पर महत्वपूर्ण प्रभाव डालते हैं। वे इस प्रकार हैं:

AUTO_ACKNOWLEDGE

यह सबसे अधिक इस्तेमाल किया जाने वाला मोड है, संभवतः क्योंकि इसमें ऑटो शब्द है। यह मोड क्लाइंट लाइब्रेरी को संदेश को उसी समय स्वीकार करने के लिए बाध्य करता है जब संदेश प्राप्त () कॉल द्वारा पढ़ा जाता है। इसका मतलब यह है कि यदि संदेश द्वारा शुरू किया गया व्यावसायिक तर्क अपवाद को फेंकता है, तो संदेश खो जाता है क्योंकि यह पहले ही ब्रोकर पर हटा दिया गया है। यदि संदेश श्रोता के माध्यम से पढ़ा जाता है, तो संदेश की पुष्टि सफलतापूर्वक काम पूरा होने के बाद ही की जाएगी।

CLIENT_ACKNOWLEDGE

एक पुष्टिकरण तभी भेजा जाएगा जब उपभोक्ता कोड Message.acknowledge () विधि को स्पष्ट रूप से कॉल करेगा।

DUPS_OK_ACKNOWLEDGE

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

कन्फ़र्मेशन मोड्स को ट्रांसेक्शनल रीडिंग टूल्स द्वारा पूरक किया जाता है। एक सत्र बनाते समय, इसे लेन-देन के रूप में चिह्नित किया जा सकता है। इसका मतलब है कि प्रोग्रामर को स्पष्ट रूप से Session.commit () या Session.rollback () कॉल करना होगा। उपभोक्ता पक्ष में, लेन-देन बातचीत की सीमा का विस्तार करता है जो कोड एक परमाणु संचालन के रूप में प्रदर्शन कर सकता है। उदाहरण के लिए, आप संपूर्ण के रूप में एक से अधिक संदेशों को पढ़ और संसाधित कर सकते हैं, या किसी संदेश को एक कतार से घटा सकते हैं, और फिर उसी सत्र ऑब्जेक्ट का उपयोग करके दूसरे को भेज सकते हैं।

डिस्पैच और कई उपभोक्ता

अब तक, हम एक एकल उपभोक्ता के साथ संदेश पढ़ने के व्यवहार पर चर्चा कर रहे हैं। आइए अब देखें कि यह मॉडल कई उपभोक्ताओं पर कैसे लागू होता है।

जब कई उपभोक्ता कतार में जाते हैं, तो ब्रोकर का डिफ़ॉल्ट व्यवहार उन उपभोगकर्ताओं को राउंड-रॉबिन संदेश भेजना होता है, जो प्रीफ़ेच बफ़र्स में एक स्थान रखते हैं। संदेशों को उस क्रम में भेजा जाएगा जिसमें वे कतार में पहुंचे - यह केवल FIFO गारंटी प्रदान की गई है (पहले, पहले बाहर; पहले अंदर, पहले बाहर)।

जब उपभोक्ता अचानक बंद हो जाता है, तो उसे भेजे गए सभी संदेश, लेकिन अभी तक पुष्टि नहीं की गई है, दूसरे उपलब्ध ग्राहक के प्रति नाराजगी होगी।

यह एक महत्वपूर्ण प्रश्न उठाता है: यहां तक ​​कि जहां उपभोक्ता लेनदेन का उपयोग किया जाता है, वहाँ कोई गारंटी नहीं है कि संदेश को कई बार संसाधित नहीं किया जाएगा।

उपभोक्ता के अंदर निम्नलिखित प्रसंस्करण तर्क पर विचार करें:

1. संदेश कतार से घटाया जाता है। लेन-देन शुरू होता है।
2. संदेश की सामग्री के साथ एक वेब सेवा कहा जाता है।
3. लेन-देन प्रतिबद्ध है। ब्रोकर को एक पुष्टिकरण भेजा जाता है।

यदि क्लाइंट चरण 2 और 3 के बीच पूरा होता है, तो संदेश के प्रूफरीडिंग ने पहले से ही वेब सेवा को कॉल करके किसी अन्य सिस्टम को प्रभावित किया है। वेब सेवा कॉल HTTP अनुरोध हैं और, जैसे, लेन-देन नहीं हैं।

यह व्यवहार सभी कतारबद्ध प्रणालियों के लिए सत्य है - भले ही वे लेन-देन कर रहे हों, वे इस बात की गारंटी नहीं दे सकते कि उनमें संदेश संसाधित करते समय कोई दुष्प्रभाव नहीं होगा। संदेशों के प्रसंस्करण की विस्तार से जांच करने के बाद, हम विश्वास के साथ कह सकते हैं:

केवल एक बार संदेश वितरण जैसी कोई चीज नहीं है।

कतारें कम से कम एक बार वितरण की गारंटी प्रदान करती हैं , और कोड के संवेदनशील भागों को हमेशा दोहराया संदेशों को प्राप्त करने की संभावना पर विचार करना चाहिए। हम बाद में चर्चा करेंगे कि एक मैसेजिंग क्लाइंट कैसे संदेशों को ट्रैक करने और डुप्लिकेट से बचने के लिए बेकार पढ़ने का उपयोग कर सकता है।

संदेश क्रमबद्ध करें

[A, B, C, D] और दो उपभोक्ताओं C1 और C2 के क्रम में आने वाले संदेशों के एक सेट के लिए, संदेशों का सामान्य वितरण निम्नानुसार होगा:

C1: [A, C]
C2: [B, D]
चूंकि ब्रोकर रीडिंग प्रक्रियाओं के संचालन को नियंत्रित नहीं करता है और प्रोसेसिंग ऑर्डर समानांतर है, इसलिए यह गैर-नियतात्मक है। यदि C1 C2 की तुलना में धीमा है, तो संदेशों के प्रारंभिक सेट को [B, D, A, C] के रूप में संसाधित किया जा सकता है।

यह व्यवहार शुरुआती लोगों को आश्चर्यचकित कर सकता है, जो संदेश को क्रम में संसाधित करने की अपेक्षा करते हैं और इस आधार पर, अपना स्वयं का संदेश अनुप्रयोग विकसित कर रहे हैं। एक ही प्रेषक द्वारा भेजे जाने वाले संदेशों को एक-दूसरे के सापेक्ष संसाधित करने की आवश्यकता, जिसे कारण-क्रम के रूप में भी जाना जाता है, काफी सामान्य है।

उदाहरण के रूप में ऑनलाइन सट्टेबाजी से लिए गए निम्नलिखित उपयोग के मामले को लें:

1. उपयोगकर्ता खाता कॉन्फ़िगर किया गया है।
2. खाते में पैसा जमा किया जाता है।
3. एक शर्त लगाई जाती है जो खाते से पैसे निकालती है।

यहां यह समझ में आता है कि संदेशों को उस क्रम में संसाधित किया जाता है जिसमें उन्हें भेजा गया था, ताकि खाते की सामान्य स्थिति को ध्यान में रखा जाए। अजीब चीजें हो सकती हैं यदि सिस्टम उस खाते से धन निकालने की कोशिश करता है जिसमें कोई धन नहीं है। बेशक, इसके आसपास के तरीके हैं।

अनन्य ग्राहक मॉडल में कतार से एक ग्राहक को सभी संदेश भेजना शामिल है। इस दृष्टिकोण का उपयोग करते हुए, अनुप्रयोगों या थ्रेड्स के कई उदाहरणों को कतार में जोड़ते समय, उन्हें एक विशेष प्राप्तकर्ता पैरामीटर का उपयोग करके हस्ताक्षरित किया जाता है : my.queue?consumer.exclusive=true । जब आप एक एकाधिकार उपभोक्ता को जोड़ते हैं, तो वह सभी संदेश प्राप्त करता है। जब दूसरा उपभोक्ता जुड़ा होता है, तो उसे तब तक कोई संदेश नहीं मिलेगा, जब तक कि पहले वाला डिस्कनेक्ट न हो जाए। यह दूसरा उपभोक्ता वास्तव में एक हॉट रिज़र्व है, जबकि पहला उपभोक्ता अब ठीक उसी तरह से संदेश प्राप्त करेगा, जिस क्रम में वे जर्नल में दर्ज किए गए थे - एक कारण क्रम में।
इस दृष्टिकोण का नुकसान यह है कि यद्यपि संदेश प्रसंस्करण सुसंगत है, यह एक प्रदर्शन अड़चन है क्योंकि सभी संदेशों को एक एकल कम्प्यूरेटर द्वारा संसाधित किया जाना चाहिए।

इस उपयोग के मामले को अधिक समझदारी से समझने के लिए, आपको समस्या पर पुनर्विचार करने की आवश्यकता है। क्या सभी संदेशों को क्रम में संसाधित करने की आवश्यकता है? ऊपर वर्णित प्रसंस्करण बोलियों के मामले में, केवल एक खाते से संबंधित संदेशों को क्रमिक रूप से संसाधित करना आवश्यक है। ActiveMQ JMS संदेश समूहों नामक इस स्थिति से निपटने के लिए एक तंत्र प्रदान करता है।

संदेश समूह एक प्रकार का विभाजन तंत्र है जो उत्पादकों को उन समूहों में संदेश वितरित करने की अनुमति देता है जिन्हें व्यावसायिक कुंजी के अनुसार क्रमिक रूप से संसाधित किया जाएगा। यह व्यावसायिक कुंजी संदेश संपत्ति में सेट है जिसे JMSXGroupID कहा जाता है।

प्रसंस्करण बोलियों के मामले में प्राकृतिक कुंजी खाता पहचानकर्ता होगी।
यह बताने के लिए कि कैसे काम करता है, निम्नलिखित क्रम में आने वाले संदेशों के सेट पर विचार करें:

 [(A, Group1), (B, Group1), (C, Group2), (D, Group3), (E, Group2)] 

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

यहां समूहों को दो उपभोक्ताओं के बीच सौंपा जाएगा: C1 और C2, निम्नानुसार हैं:

 C1: [Group1, Group3] C2: [Group2] 

संदेशों को पुनर्निर्देशित और निम्नानुसार संसाधित किया जाएगा:

 C2: [B, D] C2: [(C, Group2), (E, Group2)] 

यदि उपभोक्ता टूट जाता है, तो उसे सौंपे गए सभी समूहों को बाकी उपभोक्ताओं के बीच पुनर्वितरित कर दिया जाएगा और किसी भी अपुष्ट संदेशों को फिर से निर्देशित किया जाएगा। इसलिए, यद्यपि हम गारंटी दे सकते हैं कि सभी संबंधित संदेशों को क्रम में संसाधित किया जाएगा, हम यह दावा नहीं कर सकते हैं कि वे एक ही उपभोक्ता द्वारा संसाधित किए जाएंगे।

उच्च उपलब्धता

ActiveMQ साझा संग्रहण के आधार पर एक मास्टर-दास के साथ उच्च उपलब्धता प्रदान करता है। इस योजना में, दो या दो से अधिक दलालों (हालांकि आमतौर पर दो) अलग-अलग सर्वरों पर कॉन्फ़िगर किए जाते हैं, और उनके संदेश बाहरी स्थान पर स्थित संदेश स्टोर में संग्रहीत किए जाते हैं। ब्रोकर के कई उदाहरणों से एक संदेश स्टोर का एक साथ उपयोग नहीं किया जा सकता है, इसलिए इसका (स्टोरहाउस) द्वितीयक फ़ंक्शन यह निर्धारित करने के लिए एक अवरुद्ध तंत्र के रूप में कार्य करता है कि कौन सा ब्रोकर अनन्य पहुंच प्राप्त करेगा ( चित्र 2-6 )।


चित्र 2-6। ब्रोकर ए लीड है, ब्रोकर बी दास के रूप में स्टैंडबाय पर है

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

उसी समय, क्लाइंट ट्रांसपोर्ट कनेक्टर के रूप में जाने वाले इनबाउंड पोर्ट से कनेक्ट करने के प्रयास में दो दलालों के पते को वैकल्पिक करता है। जैसे ही मुख्य ब्रोकर उपलब्ध हो जाता है, क्लाइंट अपने पोर्ट से जुड़ जाता है और संदेश भेज और पढ़ सकता है।
जब ब्रोकर ए, एक नेता के रूप में कार्य करता है, तो प्रक्रिया की विफलता ( चित्र 2-7 ) के कारण विफल हो जाता है, निम्नलिखित घटनाएं होती हैं:

1. क्लाइंट दो दलालों के पते को बारी-बारी से डिस्कनेक्ट करता है और फिर से जोड़ने की कोशिश करता है।
2. संदेश में लॉक जारी किया गया है। इस का समय भंडारण कार्यान्वयन पर निर्भर करता है।
3. ब्रोकर बी, जो दास मोड में थे, समय-समय पर ताला पाने की कोशिश करते थे, अंततः सफल होते हैं और अपने बंदरगाहों को खोलते हुए, मास्टर की भूमिका ग्रहण करते हैं।
4. ग्राहक ब्रोकर बी से जुड़ता है और अपना काम जारी रखता है।

चित्र 2-7। ब्रोकर ए रिपॉजिटरी से संबंध खो कर समाप्त हो जाता है। ब्रोकर बी का नेतृत्व करता है

कई ब्रोकर के पते के बीच वैकल्पिक तर्क क्लाइंट लाइब्रेरी में बनाए जाने की गारंटी नहीं है, जैसा कि जेएमएस / एनएमएस / सीएमएस कार्यान्वयन में होता है। यदि पुस्तकालय केवल एक पते पर पुन: संयोजन प्रदान करता है, तो आपको लोड बैलेंसर के पीछे दलालों के एक जोड़े को रखने की आवश्यकता हो सकती है, जो अत्यधिक उपलब्ध होना चाहिए।

इस दृष्टिकोण का मुख्य नुकसान यह है कि एक तार्किक ब्रोकर के काम को आसान बनाने के लिए, कई भौतिक सर्वरों की आवश्यकता होती है। इस मामले में, ब्रोकर के दो सर्वरों में से एक बेकार है, काम शुरू करने से पहले अपने साथी के वियोग के लिए इंतजार कर रहा है।

इस दृष्टिकोण में जोड़ा गया जटिलता भी है जो ब्रोकर भंडारण का उपयोग करता है, चाहे वह एक साझा नेटवर्क फ़ाइल सिस्टम या डेटाबेस हो, अत्यधिक सुलभ होना चाहिए। यह उपकरण और ब्रोकर सेटिंग्स के प्रशासन के लिए अतिरिक्त लागत की ओर जाता है। इस परिदृश्य में, यह बुनियादी ढांचे के अन्य भागों जैसे डेटाबेस के रूप में उपयोग की जाने वाली मौजूदा उच्च-उपलब्धता रिपॉजिटरी का पुन: उपयोग करने के लिए लुभाता है, लेकिन यह एक गलती है।

यह याद रखना महत्वपूर्ण है कि ब्रोकर के समग्र प्रदर्शन पर डिस्क मुख्य सीमक है। यदि संदेश ब्रोकर के अलावा किसी अन्य प्रक्रिया में डिस्क का उपयोग एक साथ किया जाता है, तो डिस्क के साथ इस प्रक्रिया की बातचीत संभवतः ब्रोकर से रिकॉर्डिंग को धीमा कर देती है और इसलिए, संदेश जिस गति से सिस्टम के माध्यम से जा सकता है। इस तरह की मंदी का निदान करना मुश्किल है और उनके आसपास का एकमात्र तरीका दोनों प्रक्रियाओं को अलग-अलग भंडारण संस्करणों में अलग करना है।

ब्रोकर के स्थिर संचालन को सुनिश्चित करने के लिए, एक समर्पित और अनन्य भंडारण की आवश्यकता होती है।

ऊर्ध्वाधर और क्षैतिज स्केलिंग

परियोजना के जीवन के कुछ बिंदु पर, आप संदेश दलाल पर एक प्रदर्शन सीमा का सामना कर सकते हैं। ये सीमाएँ आमतौर पर संसाधनों से संबंधित होती हैं, विशेष रूप से उपयोग किए जाने वाले भंडारण के साथ ActiveMQ इंटरैक्शन में। ये समस्याएं आमतौर पर प्राप्तकर्ता के बीच संदेश की मात्रा या बैंडविड्थ के टकराव के कारण उत्पन्न होती हैं, उदाहरण के लिए, जब एक कतार ब्रोकर को पीरियड्स के दौरान ओवरफ्लो करती है।

ब्रोकर के बुनियादी ढांचे से अधिक प्रदर्शन प्राप्त करने के कई तरीके हैं:

• आवश्यकता न होने पर दृढ़ता का प्रयोग न करें। कुछ उपयोग परिदृश्य क्रैश के दौरान संदेशों के नुकसान की अनुमति देते हैं, खासकर जब एक सिस्टम कतार के माध्यम से दूसरे को पूर्ण स्नैपशॉट स्थिति भेजता है, या तो समय-समय पर या मांग पर।
• ब्रोकर को तेज ड्राइव पर चलाएं। वास्तविक परिस्थितियों में, मानक HDD और मेमोरी-आधारित विकल्पों के बीच रिकॉर्डिंग बैंडविड्थ में महत्वपूर्ण अंतर नोट किया गया था।
• डिस्क आकार का सबसे अच्छा उपयोग करें। जैसा कि ऊपर वर्णित डिस्क पाइपलाइन इंटरैक्शन मॉडल में दिखाया गया है, संदेशों के समूहों को भेजने के लिए लेनदेन का उपयोग करके उच्चतर थ्रूपुट प्राप्त किया जा सकता है, जिससे कई लेखन कार्यों को एक बड़े में जोड़ा जा सकता है।
• ट्रैफ़िक विभाजन का उपयोग करें। आप निम्न तरीकों में से किसी एक में गंतव्य को विभाजित करके उच्च थ्रूपुट प्राप्त कर सकते हैं:

1. एक दलाल के भीतर कई डिस्क, उदाहरण के लिए, कई निर्देशिकाओं के लिए mKahaDB दृढ़ता एडेप्टर का उपयोग करके, जिनमें से प्रत्येक को एक अलग डिस्क पर रखा गया है।
2. कई ब्रोकर और ट्रैफ़िक का विभाजन क्लाइंट एप्लिकेशन द्वारा मैन्युअल रूप से किया जाता है। ActiveMQ इस उद्देश्य के लिए कोई मूल कार्य प्रदान नहीं करता है।

ब्रोकर प्रदर्शन समस्याओं के सबसे आम कारणों में से एक बस एक उदाहरण के साथ बहुत अधिक करने का प्रयास है। एक नियम के रूप में, यह उन स्थितियों में होता है जहां ब्रोकर को वर्तमान में ब्रोकर पर मौजूदा लोड को ध्यान में रखते हुए या वॉल्यूम को समझने के बिना कई अनुप्रयोगों के बीच विभाजित किया जाता है। समय के साथ, एक दलाल को अधिक से अधिक लोड किया जाता है जब तक कि वह उचित व्यवहार करना बंद नहीं करता है।

समस्या अक्सर सिस्टम डिज़ाइन चरण के दौरान उत्पन्न होती है, जब सिस्टम वास्तुकार चित्रा 2-8 में इस तरह की योजना का प्रस्ताव कर सकता है।


चित्र 2-8। मैसेजिंग इन्फ्रास्ट्रक्चर का वैचारिक दृश्य

लक्ष्य कई अनुप्रयोगों के लिए ActiveMQ के माध्यम से एक दूसरे के साथ संचार करने के लिए है। लक्ष्य अब निर्दिष्ट नहीं है और फिर योजना वास्तविक ब्रोकर कॉन्फ़िगरेशन के आधार को निर्धारित करती है। इस दृष्टिकोण को यूनिवर्सल डेटा पाइपलाइन कहा जाता है।

यह ऊपर उल्लिखित वैचारिक डिजाइन और भौतिक कार्यान्वयन के बीच विश्लेषण के मूलभूत कदम को ध्यान में नहीं रखता है। एक विशिष्ट कॉन्फ़िगरेशन के निर्माण के साथ आगे बढ़ने से पहले, एक विश्लेषण करना आवश्यक है, जो तब भौतिक परियोजना को सही ठहराने के लिए उपयोग किया जाएगा। इस प्रक्रिया में पहला कदम यह निर्धारित करना है कि कौन से सिस्टम एक-दूसरे के साथ बातचीत करते हैं - आयतों और तीर के साथ एक काफी सरल आरेख ( चित्र 2-9 )।


चित्र 2-9। स्केच संदेश सिस्टम के बीच बहता है

इसकी मंजूरी के बाद, आप निम्नलिखित सवालों के जवाब के लिए विवरण पर जा सकते हैं:

• कितने कतारों और विषयों का उपयोग किया जाएगा?
• उनमें से प्रत्येक के लिए क्या संदेश वॉल्यूम की उम्मीद है?
• प्रत्येक प्राप्तकर्ता में संदेश कितने बड़े हैं? बड़े संदेश पेजिंग प्रक्रिया में समस्याएं पैदा कर सकते हैं, जिससे मेमोरी सीमाएं पार हो जाती हैं और ब्रोकर अवरुद्ध हो जाते हैं।
• क्या संदेश प्रवाह पूरे दिन समान रहेगा या बैच नौकरियों के कारण स्पाइक्स होंगे? एक कम उपयोग की जाने वाली कतार में बड़े बैच उच्च प्रदर्शन वाले गंतव्यों के लिए समयबद्ध डिस्क के साथ हस्तक्षेप कर सकते हैं।
• क्या सिस्टम एक ही डेटा सेंटर में या अलग-अलग हैं? दूरस्थ संचार में कुछ प्रकार के नेटवर्क दलाल शामिल हैं।

विचार अलग-अलग मैसेजिंग परिदृश्यों को परिभाषित करने के लिए है जो व्यक्तिगत दलालों ( चित्रा 2-10 ) द्वारा संयुक्त या विभाजित किए जा सकते हैं।
इस तरह के टूटने के बाद, किसी भी समस्या की पहचान करने के लिए ActiveMQ प्रदर्शन मॉड्यूल का उपयोग करके एक दूसरे के साथ संयोजन करके उपयोग परिदृश्यों को सिम्युलेटेड किया जा सकता है।


चित्र 2-10। व्यक्तिगत दलालों की पहचान

तार्किक दलालों की उचित संख्या निर्धारित करने के बाद, आप निर्धारित कर सकते हैं कि अत्यधिक सुलभ कॉन्फ़िगरेशन और ब्रोकर नेटवर्क का उपयोग करके उन्हें भौतिक स्तर पर कैसे लागू किया जाए।

परिणाम

इस अध्याय में, हमने उस तंत्र की जांच की जिसके द्वारा ActiveMQ संदेश प्राप्त करता है और वितरित करता है। हमने उन सुविधाओं पर चर्चा की जो इस वास्तुकला द्वारा समर्थित हैं, जिसमें संबंधित संदेशों और लेनदेन के चिपचिपा लोड-संतुलन शामिल हैं। उसी समय, हमने सभी संदेश प्रणालियों के लिए आम अवधारणा का एक सेट पेश किया, जिसमें संचार प्रोटोकॉल और पत्रिकाएं शामिल थीं। हमने डिस्क पर लिखने में आने वाली कठिनाइयों और कैसे दलालों ने प्रदर्शन में सुधार के लिए पैकेट लेखन जैसी तकनीकों का उपयोग कर सकते हैं, इसकी विस्तार से जांच की। अंत में, हमने जांच की कि कैसे ActiveMQ को अत्यधिक उपलब्ध कराया जा सकता है और व्यक्तिगत ब्रोकर की क्षमताओं से परे इसे कैसे बढ़ाया जा सकता है।

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

अगला भाग: मैसेज ब्रोकर्स को समझना ActiveMQ और Kafka के माध्यम से संदेश के मैकेनिक्स सीखना। अध्याय 3. काफ्का

अनुवाद पूरा हुआ: tele.gg/middle_java