2014-05-23 11 views
8

हम एक ऐसे अनुप्रयोग को विकसित कर रहे हैं जिसमें कुछ प्राथमिक चैट/संदेश गुजरने की कार्यक्षमता शामिल होगी। वेब अनुप्रयोग Wildfly 8.x पर तैनात किया जाता है, और मानक JavaEE का उपयोग करता है 7 पुस्तकालयों (के रूप में वसंत की तरह एक अतिरिक्त आवेदन ढांचे के खिलाफ) हम यह पूरा करने के WebSockets लाभ कर रहे हैं, के रूप में हम धक्का-टू-ब्राउज़र कार्यक्षमता इसकी जरूरत प्रदान करता है। हालांकि, हम क्लस्टर/एचए कॉन्फ़िगरेशन में इस वेब एप्लिकेशन को तैनात कर रहे हैं। यदि उपयोगकर्ता ए नोडा से जुड़ा हुआ है और एक संदेश में गुजरता है जो कि यूडीबीबी से जुड़ा हुआ है, तो हम इस संदेश का परिवहन कैसे करते हैं?वाइल्डफ्लाई - अलग-अलग नोड्स पर 2 वेबसाइटों के बीच संचार?

एक एकल नोड विन्यास में, इसका सरल उत्तर बनाए रखने के लिए किया जाएगा एक स्थिर Map या List उचित संदेश गंतव्य के आधार पर WebSocket को WebSockets और सत्र, और मार्ग के सभी है। लेकिन, एक से अधिक नोड के साथ जो स्पष्ट रूप से काम नहीं करेगा क्योंकि स्थिर Map/List प्रति-जेवीएम है।

हम इस लक्ष्य को पूरा करने के बारे में कैसे जाना होगा? क्या जेएमएस का उपयोग करना संभव होगा और प्रत्येक वेबस्केट एक्ट को जेएमएस श्रोता के रूप में रखना होगा? संसाधन उपयोग या मापनीयता और प्रदर्शन पर इसका क्या असर होगा?

हम कैसे इस समस्या को हल करने के लिए के रूप में एक नुकसान का एक सा पर कर रहे हैं, और वास्तव में किसी भी सलाह आप दे सकते हैं की सराहना करेंगे।

उत्तर

3

आप दो तरह से

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

2) आप एक अलग JVM पर एक JMS कतार बना सकते हैं, प्रकाशक और ग्राहक इस सेवा को सुनने के हैं। ब्रोकर के रूप में इस जेवीएम सेवा का प्रयोग करें।

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

हालांकि मॉडल का उपयोग कर का नुकसान यह आपके आवेदन सेटअप करने के लिए एक और रखरखाव भूमि के ऊपर जोड़ देगा है।

2

मैं एक तुल्यकालन बिंदु के रूप में एक डेटाबेस का उपयोग सुझाव देते हैं।
लंबित संदेशों के साथ एक एकल डीबी तालिका की कल्पना करें, प्रत्येक नोड समय-समय पर पूछताछ करता है और केवल अपने सक्रिय ग्राहकों के लिए संदेश चुनता है, उन्हें वितरित करता है और तालिका अपडेट करता है (और नए प्राप्त संदेशों को सम्मिलित करता है)।

लाभ:

  • आसान लागू करने के लिए
  • (प्रत्येक नोड पर एक ही डेटा स्रोत) कॉन्फ़िगर करने के लिए आसान
  • तेजी
  • सुपर स्केलेबल
  • एक ढांचागत बुरा सपना
  • नहीं होगा
  • की निगरानी करने के लिए आसान
  • व्यवहार (रों के विपरीत ओमे क्लस्टर-वाइड कैश)

एकमात्र जटिलता यह है कि आपको निर्णय लेने का निर्णय लेने की एक अच्छी रणनीति के साथ आना होगा ताकि डीबी को अतिसंवेदनशील न किया जा सके; उदाहरण के लिए आप अन्य नोड्स को सिग्नल करने के लिए एक एकल जेएमएस विषय का उपयोग कर सकते हैं जो एक नया संदेश पहुंचा।
मैं जानता हूँ कि यह async संदेश सेवा से यह कर केवल लेकिन यह एक विचार के रूप में कल्पना के रूप में प्रतीत नहीं होता!

+0

यह सुनिश्चित नहीं है कि यह बहुत तेज़ होगा ... – Gab

+0

+1 सादगी के लिए +1;) – Gab

+0

हालांकि यह काम करेगा, प्रदर्शन और स्केलेबिलिटी भयानक होगी। उल्लेख नहीं है कि नए संदेशों के लिए डीबी के निरंतर मतदान की आवश्यकता होगी। – Shadowman

2

सबसे आसान तरीका शायद क्लस्टर संचार प्रणाली में बनाया गया है, ऐसा करके उपयोग करने के लिए है, तो आप क्षैतिज स्केलेबल रहेगा:

https://docs.jboss.org/author/display/WFLY8/HTTP+Services

http://www.jgroups.org/tutorial/html/ch02.html

आप संदेश गंतव्य नहीं है वर्तमान नोड पर कनेक्शन, बस क्लस्टर के अन्य सभी नोड्स को अग्रेषित करें, अच्छा कनेक्शन प्रबंधित करने वाला व्यक्ति इसे धक्का देगा, अन्य अनदेखा करेंगे।

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

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