क्या मैं एक वितरित ऐप द्वारा किए गए अनुरोधों को थ्रॉटल कर सकता हूं?

Question

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

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

अब, हम एक सर्वर से क्लस्टर में माइग्रेट कर रहे हैं, इसलिए एप्लिकेशन की दो प्रतियां चल रही हैं।

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

यह एक JavaEE 5 माहौल है। एप्लिकेशन द्वारा भेजे गए अनुरोधों को कम करने का सबसे अच्छा तरीका क्या है?

Answer 1

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

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

परिणाम किसी अन्य कतार (या प्रति आवेदन उदाहरण के लिए भी एक कतार) के माध्यम से वापस किया जा सकता है।

Answer 2

ऐसा करने के कई तरीके: आपके पास "समन्वय एजेंट" हो सकता है जो सर्वरों को "टोकन" सौंपने के लिए जिम्मेदार है। प्रत्येक "टोकन" कार्य करने के लिए अनुमति का प्रतिनिधित्व करता है। प्रत्येक एप्लिकेशन को कॉल करने के लिए "टोकन" का अनुरोध करने की आवश्यकता होती है।

एक बार जब कोई एप्लिकेशन अपने टोकन को कम कर देता है, तो उसे वेब सेवा को फिर से हिट करने से पहले कुछ और पूछना चाहिए।

बेशक, वेब सेवा की सहमति के कारण प्रत्येक एप्लिकेशन के प्रत्येक कॉल के समय के संबंध में आवश्यकताएं होती हैं, तो यह सब जटिल हो जाता है।

आप पर निर्भर हो सकते हैं RabbitMQ मैसेजिंग फ्रेमवर्क के रूप में: जावा बाइंडिंग उपलब्ध हैं।

Answer 3

एन नोड्स को संवाद करने की आवश्यकता है। विभिन्न रणनीतियों हैं:

• प्रसारण: प्रत्येक नोड किसी और को प्रसारित करेगा कि यह कॉल को मैक कर रहा है, और अन्य सभी नोड्स इसे ध्यान में रखेंगे। नोड्स बराबर हैं और व्यक्तिगत वैश्विक गिनती बनाए रखते हैं (प्रत्येक नोड हर दूसरे नोड के कॉल के बारे में जानते हैं)।
• मास्टर नोड: एक नोड विशेष है, इसके मास्टर और अन्य सभी नोड्स कॉल करने से पहले मास्टर से अनुमति मांगते हैं। मास्टर ही एकमात्र ऐसा है जो वैश्विक गिनती को जानता है।
• समर्पित मास्टर: मास्टर के समान, लेकिन 'मास्टर' इसके बारे में कॉल नहीं करता है, केवल एक सेवा है जो कॉल का ट्रैक रखती है।

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

नोड्स कैसे संवाद करते हैं, आपके ऊपर है। आप एक टीसीपी पाइप खोल सकते हैं, आप यूडीपी को प्रसारित कर सकते हैं, आप अकेले इस उद्देश्य के लिए पूरी तरह से विकसित डब्ल्यूएस कर सकते हैं, आप फ़ाइल शेयर प्रोटोकॉल का उपयोग कर सकते हैं। आप जो कुछ भी करते हैं, अब आप एक प्रक्रिया के अंदर नहीं हैं, इसलिए सभी fallacies of distributed computing लागू होते हैं।

Answer 4

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

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

जेबॉस कैश आमतौर पर हेवी-ड्यूटी वितरित कैशिंग के लिए उपयोग किया जाता है, लेकिन मुझे यह हल्का वजन वाली नौकरियों के लिए भी पसंद है। यह शुद्ध जावा है, और जेवीएम (टेराकोटा के विपरीत) के बारे में कोई मजाक नहीं है।

Answer 5

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

Answer 6

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