मुझे वास्तव में delayed_job और background_job जैसे रत्न पसंद नहीं हैं जो असीमित नौकरियों को चलाने के उद्देश्य से डेटाबेस तक बने रहते हैं। यह सिर्फ मेरे लिए गंदा लगता है। क्षणिक सामान डेटाबेस में नहीं है।
मैं अतुल्यकालिक कार्यों से निपटने के लिए संदेश कतारों का एक बड़ा प्रशंसक हूं, भले ही आपको बड़े पैमाने पर स्केलेबिलिटी की आवश्यकता न हो। जिस तरह से मैं इसे देखता हूं, संदेश कतार जटिल प्रणालियों के लिए आदर्श "लिंगुआ फ़्रैंका" हैं। एक संदेश कतार के साथ, ज्यादातर मामलों में, आपके पास ऐसी प्रौद्योगिकियों या भाषाओं पर कोई प्रतिबंध नहीं है जो आप जो भी बना रहे हैं उसमें शामिल हैं।कम-समवर्ती संदेश कतार उपयोग के लाभ शायद "एंटरप्राइज़" वातावरण में सबसे अधिक ध्यान देने योग्य हैं जहां एकीकरण हमेशा एक बड़ा दर्द होता है। इसके अतिरिक्त, संदेश कतार आदर्श हैं जब आपके एसिंक्रोनस वर्कफ़्लो में कई चरण शामिल होते हैं। RabbitMQ मेरा निजी पसंदीदा है।
उदाहरण के लिए, उस परिदृश्य पर विचार करें जहां आप एक खोज इंजन बना रहे हैं। लोग अनुक्रमित होने के लिए यूआरआई जमा कर सकते हैं। जाहिर है, आप पृष्ठ को अनुरोध में पुनर्प्राप्त और अनुक्रमित नहीं करना चाहते हैं। तो आप एक संदेश कतार के चारों ओर बनाते हैं: फ़ॉर्म सबमिशन लक्ष्य यूआरआई लेता है, इसे संदेश कतार में अनुक्रमित करने के लिए फेंकता है। अगली उपलब्ध मकड़ी प्रक्रिया यूआरआई को कतार से बाहर कर देती है, पृष्ठ को पुनर्प्राप्त करती है, सभी लिंक पाती है, अगर उनमें से प्रत्येक अज्ञात हैं तो कतार पर वापस धक्का देती है, और सामग्री को कैश करती है। आखिरकार, कैश की गई सामग्री से निपटने के लिए इंडेक्सर प्रक्रिया के लिए एक नया संदेश दूसरी कतार पर धकेल दिया जाता है। इंडेक्सर प्रक्रिया उस संदेश को कतार से पॉप करती है, और कैश की गई सामग्री को अनुक्रमणित करती है। पाठ्यक्रम के ओवरसम्प्लीफाइड - सर्च इंजन बहुत सारे काम हैं, लेकिन आपको विचार मिलता है।
वास्तविक डेमॉन के लिए, जाहिर है, मैं अपनी लाइब्रेरी (चेनगैंग) के आंशिक हूं, लेकिन यह वास्तव में कर्नेल.फर्क() के आसपास एक रैपर है जो आपको सेटअप और टियरडाउन कोड से निपटने के लिए एक सुविधाजनक स्थान देता है। यह अभी तक काफी कुछ नहीं किया गया है। वास्तव में संदेश कतार की तुलना में डेमॉन टुकड़ा बहुत कम महत्वपूर्ण है।
रेल पर्यावरण के बारे में अच्छी तरह से, यह शायद पाठक के लिए एक अभ्यास के रूप में सबसे अच्छा छोड़ दिया गया है, क्योंकि स्मृति उपयोग लंबे समय तक चलने वाली प्रक्रिया के साथ एक महत्वपूर्ण कारक बनने जा रहा है। आप जो कुछ भी नहीं करना चाहते हैं उसे लोड नहीं करना चाहते हैं। संयोग से, यह एक ऐसा क्षेत्र है जहां DataMapper ActiveRecord के बट को अच्छी तरह से मारता है। पर्यावरण शुरूआत अच्छी तरह से प्रलेखित है, और बहुत कम निर्भरताएं खेलती हैं जो पूरे किट और कैबूडल को और अधिक यथार्थवादी बनाती हैं।
एक चीज जो मुझे क्रॉन + रेक के बारे में पसंद नहीं है वह यह है कि रेक को मानक आउटपुट पर प्रिंट करने की वस्तुतः गारंटी दी जाती है, और यदि क्रॉन नौकरियां उत्पादन का उत्पादन करती हैं तो क्रॉन अत्यधिक चिपचिपा होता है। मैं अपने सभी क्रॉन कार्यों को एक उचित नामित निर्देशिका में रखना चाहता हूं, फिर एक रेक कार्य करें जो उन्हें लपेटता है, ताकि उन्हें मैन्युअल रूप से चलाने के लिए तुच्छ हो। यह एक शर्म की बात है कि रेक यह करता है, क्योंकि मैं वास्तव में निर्भरताओं का लाभ उठाने का विकल्प चुनना चाहता हूं। किसी भी मामले में, आप क्रॉन के माध्यम से उन्हें चलाने के बजाए सीधे स्क्रिप्ट पर क्रॉन को इंगित करते हैं।
मैं वर्तमान में एक वेब ऐप बनाने के बीच में हूं जो असीमित प्रक्रियाओं पर भारी निर्भर करता है, और मुझे कहना है, मैं बहुत खुश हूं कि मैंने रेल का उपयोग न करने का फैसला किया।
मैं यह जोड़ना चाहता हूं कि येहुदा ने यह जवाब स्वीकार कर लिया है, लेकिन मुझे नहीं लगता कि मेरे लिए अन्य लोगों के लिए सबसे अच्छा काम करने के लिए सबसे अच्छा क्या काम करता है। एक भयानक sysadmin के रूप में मेरी प्राथमिकताओं sysadmin कार्यों को कम करने के लिए हैं :) यदि आपके पास अधिक कौशल है या उच्च प्रदर्शन समाधान की आवश्यकता है, तो हर तरह से अधिक गूढ़ क्यूइंग सिस्टमों में से एक को आजमाएं। –