लाखों विषयों के लिए संदेश कतार समाधान

Question

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

मुझे लगता है कि इस संदेश में कुछ संदेश कतार प्रणाली उचित होगी, लेकिन मुझे यकीन नहीं है कि इस तथ्य को कैसे संभाला जाए कि मेरे पास लाखों ऑब्जेक्ट होंगे - प्रत्येक ऑब्जेक्ट के लिए अलग-अलग विषय का उपयोग करना अच्छा नहीं लगता [या यह ठीक है?]।

क्या आप कृपया सुझाव दे सकते हैं कि मुझे लेना चाहिए और शायद कुछ ओपन सोर्स संदेश क्यूइंग सिस्टम भी उचित होगा?

कुछ और विवरण:

• वहाँ, सदस्य [उनमें से बहुत सारे नहीं जिसका अर्थ है] के हजारों किया जाएगा
• ग्राहकों दसियों या वस्तुओं प्रत्येक के सैकड़ों करने के लिए सदस्यता होगा,
• होगा ~ 5 -20 मिलियन वस्तुओं,
• घटनाओं को स्वयं को कोई संदेश नहीं लेना पड़ता है। सिर्फ जानकारी है कि उस वस्तु में बदल गया था पर्याप्त है,
• वस्तुओं के विशाल बहुमत के लिए सदस्यता ली होगा कभी नहीं किया,
• घटनाओं प्रति सेकंड कुछ सैकड़ों की अधिकतम दर पर होते हैं,
• आदर्श सर्वर linux के अंतर्गत चलाने चाहिए, हो सकता है http लंबे मतदान के माध्यम से शेष पारिस्थितिकी तंत्र के साथ एकीकृत करने में सक्षम [नोड जेएस का उपयोग कर? जेटी के तहत निरंतरता?]।

आपकी प्रतिक्रिया के लिए अग्रिम धन्यवाद और कुछ अस्पष्ट प्रश्न के लिए खेद है!

Answer 1

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

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

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

विकल्प है कि मैं सिर के ऊपर की सिफारिश करेंगे ActiveMQ, RabbitMQ और Redis PUB उप (वास्तव में redis पब-उप पर काम किया havent, आपके कारण diligance का इस्तेमाल करें) कर रहे हैं

अंत में यहाँ RabbitMQ के लिए कुछ प्रदर्शन मानक हैं और Redis

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

Answer 2

यदि यह मैं ActiveMQ के लिए जाना चाहते हैं खुला स्रोत है, और विषयों के लिए JMS सुविधा प्रदान करने के लिए एक आवेदन सर्वर हो गया है और यह Ajax Support ताकि आप

तो अपने ग्राहक से उन तक पहुँच सकते हैं, तो आप का प्रयोग करेंगे वस्तुओं के लिए विषयों को प्रकाशित करने के लिए जेएमएस इंफ्रास्ट्रक्चर, और आप can create topis as you need them

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

उम्मीद है कि मदद करता है !!!

Answer 3

मैं अत्यधिक RabbitMQ की सिफारिश कर सकता हूं। मैंने इसे अपने अनुभव से पहले और कुछ परियोजनाओं में उपयोग किया है, मुझे लगता है कि यह बहुत विश्वसनीय है और कॉन्फ़िगरेशन की एक विस्तृत श्रृंखला प्रदान करता है। असल में, खरगोश एमक्यू open-source (मोज़िला पब्लिक लाइसेंस (एमपीएल)) संदेश ब्रोकर है जो Advanced Message Queuing Protocol (AMQP) मानक लागू करता है।

RabbitMQ वेब साइट पर लिखित रूप में:

RabbitMQ संभवतः किसी भी मंच कि Erlang एम्बेडेड सिस्टम से, का समर्थन करता है मल्टी कोर समूहों और क्लाउड-आधारित सर्वर पर चला सकते हैं।

... जिसका अर्थ है कि लिनक्स जैसे ऑपरेटिंग सिस्टम समर्थित है।

यहाँ Node.js के लिए एक पुस्तकालय है: https://github.com/squaremo/rabbit.js

यह प्रबंधन और RabbitMQ सर्वर की निगरानी के लिए एक HTTP आधारित एपीआई के साथ आता है - एक कमांड लाइन उपकरण और एक ब्राउज़र आधारित उपयोगकर्ता इंटरफ़ेस के रूप में शामिल अच्छी तरह से देखें: http://www.rabbitmq.com/management.html।

परियोजनाओं में जिनके साथ मैं काम कर रहा हूं, मैंने सी # और दो अलग-अलग रैपर, EasyNetQ और Burrow.NET का उपयोग करके खरगोश एमक्यू के साथ संवाद किया है। दोनों RabbitMQ के लिए उत्कृष्ट रैपर हैं लेकिन मैं Burrow.NET के सबसे प्रशंसक होने के बाद समाप्त हुआ क्योंकि यह काम करना आसान और अधिक स्पष्ट है (हुड के नीचे बहुत सारे जादू नहीं करता है) और लॉगर्स, सीरिएलाइज़र को इंजेक्ट करने के लिए अच्छी लचीलापन प्रदान करता है, आदि

मैंने कभी भी उन वस्तुओं की मात्रा के साथ काम नहीं किया है जिनके साथ आप काम करने जा रहे हैं - मैंने हजारों (लाखों नहीं) के साथ काम किया है। हालांकि, इससे कोई फर्क नहीं पड़ता कि मैं कितनी वस्तुओं के साथ खेल रहा हूं, खरगोश एमक्यू ने हमेशा वास्तव में स्थिर काम किया है और कभी भी सिस्टम में त्रुटियों का स्रोत नहीं रहा है।

तो समेट करने के लिए - खरगोश एमक्यू का उपयोग करना आसान है और सेटअप, एएमक्यूपी का समर्थन करता है, HTTP के माध्यम से प्रबंधित किया जा सकता है और मुझे सबसे ज्यादा पसंद है - यह रॉक ठोस है।

Answer 4

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

यदि उपर्युक्त समाधान संतुष्ट है, तो आप किसी भी संदेश समाधान का उपयोग कर सकते हैं: activeMQ, WMQ, RabbitMQ।

Answer 5

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

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