संदेश क्विकिंग समाधान को कार्यान्वित करने के लिए कैसे करें

मेरे पास एक परिदृश्य है जहां लगभग 10 अलग-अलग संदेशों को एनक्यूड करने की आवश्यकता होगी और फिर अस्वीकार/संसाधित किया जाएगा। एक ग्राहक को सभी 10 संदेशों की आवश्यकता होगी, लेकिन किसी को केवल 10 संदेशों में से 8 की आवश्यकता होगी। मैं यह समझने की कोशिश कर रहा हूं कि इस प्रकार के आर्किटेक्चर को स्थापित करने का सबसे अच्छा तरीका क्या है। क्या आप प्रत्येक संदेश प्रकार के लिए कतार बनाते हैं ताकि ग्राहक केवल प्रासंगिक कतारों की सदस्यता ले सकें या आप उन्हें सभी को एक ही कतार में डंप कर सकें और उन संदेशों को अनदेखा कर सकें जो उस ग्राहक से प्रासंगिक नहीं हैं? मैं सुनिश्चित करने के लिए समाधान लचीला/स्केलेबल है, आदि चाहतेसंदेश क्विकिंग समाधान को कार्यान्वित करने के लिए कैसे करें

प्रक्रिया:

10 अलग एक्सएमएल संदेशों एक आईबीएम WebSphere MQ सर्वर से कतारबद्ध कर दिया जाएगा।
हम नेट (सबसे अधिक संभावना WCF के बाद से WebSphere MQ 7.1 WCF समर्थन में जोड़ा गया है) का उपयोग करेगा
हम संदेशों विपंक्ति जाएगा और एक अन्य बैकएंड डीबी में उन्हें लोड (सबसे अधिक संभावना एसक्यूएल सर्वर)।
समाधान को अच्छी तरह से स्केल करने की आवश्यकता है क्योंकि हम बहुत बड़ी संख्या में संदेश संसाधित करेंगे और यह बढ़ सकता है (शायद 40-50,000/घंटा)। हमारे लिए कम से कम बड़ी राशि।

हमेशा जानकारी की सराहना करते हैं।

--S

स्रोत

2011-10-30 scarpacci

उन संदेशों के बारे में क्या अलग है जिन्हें अनदेखा करने की आवश्यकता है? यहां कई अलग-अलग विकल्प हैं - चयनकर्ता, विषय, गुण। उपयोग करने के लिए इस बात पर निर्भर करता है कि ऐप या क्यूएमग्री किस प्रकार अलग-अलग संदेशों को अलग करेगा। –

हाय @ टी। रॉब सभी 10 के लिए संदेश का शीर्षलेख समान होगा, लेकिन सामग्री अलग होगी। तो हम यह निर्धारित करने के लिए हेडर को देख सकते हैं कि संदेश की सामग्री प्रासंगिक है या नहीं। नीचे की रेखा दो संदेशों के लिए है, हम नहीं चाहते कि ग्राहकों में से एक उन्हें प्राप्त करे। – scarpacci

ठीक है, टिप्पणियों के आधार पर, यहां एक सुझाव है जो स्केल करेगा और ऐप्स पर अधिक परिवर्तन की आवश्यकता नहीं है।

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

उपभोक्ता पक्ष पर आपके पास कुछ विकल्प हैं। एक प्रत्येक ऐप के लिए प्रशासनिक सदस्यता बनाना और सदस्यता में चयनकर्ता का उपयोग करना है। संदेशों को चयन मानदंडों के आधार पर प्रति उपभोक्ता समर्पित कतार में फ़नल किया जाता है। ऐप्स सोचते हैं कि वे बस संदेश ले रहे हैं।

वैकल्पिक रूप से ऐप बस विषय की सदस्यता ले सकता है। यह आपको एक गतिशील सदस्यता का विकल्प देता है जो ऐप डिस्कनेक्ट होने पर संदेशों को प्राप्त नहीं करता है (यदि वास्तव में आप चाहते थे) या एक टिकाऊ सदस्यता जो कार्यात्मक रूप से प्रशासनिक सदस्यता के बराबर है।

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

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

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

स्रोत

2011-10-30 19:30:07

धन्यवाद @ टी। रोब बहुत जानकारीपूर्ण। – scarpacci

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

स्केलिंग के रूप में, मैं वेबस्पेयर एमक्यू या अन्य आईबीएम उत्पादों के लिए बात नहीं कर सकता, लेकिन प्रति घंटे 40-50K संदेश विंडोज सर्वर पर एमएसएमक्यू के लिए विशेष रूप से कठिन नहीं है, इसलिए मुझे लगता है कि आईबीएम ऐसा कर सकता है भी। आम तौर पर बाधा कतार प्लेटफार्म नहीं बल्कि व्यक्तिगत संदेशों को हटाने और संसाधित करने की प्रक्रिया है।

स्रोत

2011-10-30 18:55:07 kprobst

समझ में आता है बहुत @ kprobst धन्यवाद। तो बेहतर होगा कि आप ऊपर बताए अनुसार प्रत्येक ग्राहक के लिए केवल एक कतार बनाएं। यह एक अच्छी रणनीति की तरह प्रतीत होता है। यही वह है जो मुझे इस बात से चिंतित था कि संदेश को आंशिक रूप से संसाधित करना है या नहीं, यह देखने के लिए कि इसे खींचा जाना चाहिए या नहीं, आदि – scarpacci

फिर सवाल यह हो जाता है कि आप प्रत्येक कतार में प्रत्येक संदेश को कैसे प्राप्त करते हैं। क्या आप निर्माता ऐप को कई संदेश बनाने की योजना बना रहे हैं और जानते हैं कि प्रत्येक व्यक्ति कहां जाता है? यही कारण है कि मैंने ऊपर पूछा कि मेरी टिप्पणी में संदेशों को कैसे अलग किया जा सकता है। –

@ टी। रोब हाँ हम निर्माता को यह तय करना होगा कि कहां जाता है। जो मुझे लगता है कि संभावित रूप से एक बाधा हो सकती है। केवल हेडर में एक मान (संपत्ति) द्वारा अंतर कर सकता है जो हमें बताता है कि संदेश के शरीर में किस प्रकार का संदेश निहित है। – scarpacci

संदेश क्विकिंग समाधान को कार्यान्वित करने के लिए कैसे करें

उत्तर

संबंधित मुद्दे