प्ले फ्रेमवर्क: स्टेटलेस मॉडल पर नौकरियों का प्रभाव

Question

Play ढांचे के बारे में महान चीजों में से एक यह है कि यह पूरी तरह से स्टेटलेस है और केवल अनुरोध/प्रतिक्रिया-उन्मुख है। यह वास्तव में अच्छा है क्योंकि यह मुझे अपने ऐप को क्लाउड पर तैनात करने और राज्य लोड (सत्र) प्रतिकृति के बारे में चिंता किए बिना मेरे लोड बैलेंसर के पीछे प्ले इंस्टेंस की संख्या को स्केल करने की अनुमति देता है ...

हाल ही में, मुझे इसकी आवश्यकता थी किसी HTTP अनुरोध के बाहर कुछ एप्लिकेशन तर्क निष्पादित करें और पता चला कि Play में उन नौकरियों को परिभाषित करने की संभावना है जो ढांचे द्वारा पूरी तरह से प्रबंधित हैं। शानदार लगता है लेकिन यह सवाल उठता है: इन नौकरियों को प्लेलेस द्वारा उपयोग किए जाने वाले स्टेटलेस मॉडल में कैसे फिट किया जाता है?

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

मैं एक गैर-क्लस्टर सर्वर पर एक नया प्ले उदाहरण बनाने के बारे में सोच रहा था, मौजूदा (क्लस्टर) उदाहरण के जेपीए मॉडल का पुन: उपयोग कर रहा हूं (और इस प्रकार एक ही डेटाबेस से कनेक्ट हो रहा है)। इस नए उदाहरण में केवल रखरखाव की नौकरियां होंगी और चूंकि यह गैर-क्लस्टर सर्वर पर होस्ट की जाती है, इसलिए नौकरी के साथ-साथ चलने का कोई खतरा नहीं होता है। साथ ही, यह मुझे अपने मौजूदा, क्लस्टर किए गए उदाहरण को पूरी तरह से स्टेटलेस और मेजबान/लोड संतुलन को आसान रखने की अनुमति देगा। क्या यह एक अच्छा दृष्टिकोण होगा?

Answer 1

मैं भी नौकरी क्लस्टर करने की सिफारिश करता हूं। आप यह सुनिश्चित करने के लिए डेटाबेस में एक सेमफोर सेट कर सकते हैं कि केवल एक ही काम चल रहा है। एक और विचार अक्का-फ्रेमवर्क पर नजर डालना है, जिसे Play 2.0 में शामिल किया जाएगा। मुझे लगता है कि इस समस्या को संभालने के साथ तंत्र में निर्माण हुआ है, लेकिन मुझे यकीन नहीं है। मुझे अक्का के साथ अनुभव नहीं हुआ है।

Answer 2

डीबी में ध्वज रखने का उल्लेख करने वाले नील्स के रूप में यह पता लगाने में मदद मिलती है कि क्या नौकरी पहले से चल रही है या नहीं। मैं नौकरी की स्थिति और अतिरिक्त जानकारी देने के लिए अन्य झंडे के साथ एक डीबी सेमफोर का उपयोग करता हूं।

एक और चीज जो आप कर सकते हैं Play.id का उपयोग करने और परिभाषित करने के लिए कि कौन सा उदाहरण नौकरियों को चलाया जाना चाहिए। हम का उपयोग करें "शुरू खेलने -% prod", "नाटक शुरू -% prod1" ... क्षुधा शुरू करने के लिए और() विधि मेरी doJob में निम्नलिखित:

doJob(){ 
    if ("prod".equalsIgnoreCase(Play.id)) { 
    ... 
    } 
} 

Answer 3

बाद में शीघ्रता से अवलोकन किया था Play Framework का स्रोत कोड (कक्षा Job और JobsPlugin) मुझे लगता है कि यह क्लस्टर वातावरण में उपयोग करने के लिए उपयुक्त नहीं है जब यह महत्वपूर्ण है कि नौकरी केवल कुछ समय अंतराल (बदसूरत हैक्स के परिचय के बिना) चलती है।

1. एक नौकरी अनुसूचक जो क्लस्टरिंग का समर्थन करता है का उपयोग करें:

   मैं तीन संभावित हल देखते हैं। स्पष्ट विकल्प Quartz है। Play क्वार्ट्ज के भागों का उपयोग करता है (सीआरओएन अभिव्यक्तियों को पार्स करने के लिए), लेकिन वह हिस्सा नहीं जो शेड्यूलिंग करता है।

2. Play 2 का उपयोग करते समय, संभवतः Akka पर जाएं, जो a scheduler प्रदान करता है।

3. अपनी नौकरी बदलें ताकि इससे कोई फर्क नहीं पड़ता कि यह दो बार चल रहा है (कुछ उपयोग मामलों के लिए संभव है)।