अजवाइन के 50 शेड

आप यहाँ हैं यदि आप जानना चाहते हैं कि एक रूपरेखा को कैसे व्यवस्थित किया जाए जो व्यापक रूप से पाइथन डेवलपर्स के हलकों में जाना जाता है जिसे सेलेरी कहा जाता है। और यहां तक ​​कि अगर सेलेरी आत्मविश्वास से आपकी परियोजना में बुनियादी आदेशों को पूरा करता है, तो फिनटेक अनुभव आपके लिए अज्ञात पक्षों को खोल सकता है। क्योंकि फिनटेक हमेशा बिग डेटा होता है, और इसके साथ पृष्ठभूमि कार्यों, बैच प्रसंस्करण, अतुल्यकालिक एपीआई, आदि की आवश्यकता होती है।


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


स्पीकर और प्रोजेक्ट के बारे में: ओलेग चर्किन ( बहूस ) 8 वर्षों से विभिन्न जटिलता के पायथन प्रोजेक्ट विकसित कर रहा है, कई प्रसिद्ध कंपनियों में काम किया है : यांडेक्स, रामब्लर , आरबीसी, कास्परस्की लैब। अब फिनटेक-स्टेटपॉनी स्टार्टअप में टेकलाइड करें।

परियोजना उपयोगकर्ताओं (1.5 टेराबाइट्स) के वित्तीय डेटा की एक बड़ी मात्रा के साथ काम करती है: खाते, लेनदेन, व्यापारी, आदि। यह हर दिन एक लाख कार्यों तक चलता है। हो सकता है कि यह संख्या वास्तव में किसी के लिए बड़ी नहीं होगी, लेकिन मामूली क्षमताओं वाले एक छोटे से स्टार्टअप के लिए यह एक महत्वपूर्ण मात्रा में डेटा है, और डेवलपर्स को एक स्थिर प्रक्रिया के रास्ते में विभिन्न समस्याओं का सामना करना पड़ा।

ओलेग ने काम के प्रमुख बिंदुओं के बारे में बात की:

• आप फ्रेमवर्क के साथ किन कार्यों को हल करना चाहते हैं, आपने सेलेरी क्यों चुना।
• अजवाइन ने कैसे मदद की।
• लोड के तहत अजवाइन को कैसे कॉन्फ़िगर करें।
• अजवाइन की स्थिति की निगरानी कैसे करें।

और उन्होंने डिजाइन उपयोगिताओं के एक जोड़े को साझा किया जो कि सेलेरी में लापता कार्यक्षमता को लागू करते हैं। जैसा कि यह निकला, 2018 में, और यह हो सकता है। निम्नलिखित पहले व्यक्ति में रिपोर्ट का एक पाठ संस्करण है।

समस्याओं

निम्नलिखित कार्यों को हल करना आवश्यक था:

• अलग बैकग्राउंड टास्क चलाएं।
• कार्यों की बैच प्रोसेसिंग करें, यानी एक साथ कई कार्य चलाएं।
• प्रक्रिया निकालें, रूपांतरण, लोड करें ।
• अतुल्यकालिक एपीआई को लागू करें। यह पता चला है कि अतुल्यकालिक एपीआई को न केवल अतुल्यकालिक रूपरेखाओं का उपयोग करके लागू किया जा सकता है, बल्कि पूरी तरह से तुल्यकालिक भी;
• आवधिक कार्य करें । एक भी परियोजना आवधिक कार्यों के बिना नहीं कर सकती; कुछ के लिए, क्रोन के साथ तिरस्कृत किया जा सकता है, लेकिन अधिक सुविधाजनक उपकरण भी हैं।
• ट्रिगर आर्किटेक्चर का निर्माण करें : ट्रिगर को ट्रिगर करने के लिए, डेटा को अपडेट करने वाले कार्य को चलाएं। यह पृष्ठभूमि में पूर्व-कंप्यूटिंग डेटा द्वारा रनटाइम-पावर की कमी की भरपाई करने के लिए किया जाता है।

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

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

पृष्ठभूमि कार्यों की अंतिम श्रेणी रखरखाव कार्य है : किसी चीज़ को देखना, देखना, ठीक करना, मॉनिटर करना आदि।

बल्क नोटिफिकेशन के लिए, बैच प्रोसेसिंग का उपयोग किया जाता है । बड़ी मात्रा में डेटा जो हमें अपने उपयोगकर्ताओं से प्राप्त होता है, उसकी गणना और एक निश्चित तरीके से संसाधित करना पड़ता है, जिसमें शामिल हैं बैच मोड में।

एक ही अवधारणा में क्लासिक एक्सट्रैक्ट, ट्रांसफॉर्म, लोड शामिल हैं :

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

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

• अन्य कार्यों से मतदान कार्य चलाना;
• शर्तों के आधार पर अलग-अलग कार्य चलाएं।

हमारी सेवा में, यह अभी के लिए पर्याप्त है, लेकिन भविष्य में हमें शायद कुछ और लिखना होगा।

उपकरण की आवश्यकताएं

इन कार्यों को लागू करने के लिए, हमारे पास उपकरणों के लिए निम्नलिखित आवश्यकताएं थीं:

• हमारी महत्वाकांक्षाओं को साकार करने के लिए कार्यशीलता आवश्यक है।
• बैसाखी के बिना स्केलेबिलिटी ।
• यह कैसे काम करता है यह समझने के लिए सिस्टम की निगरानी करना । हम बग रिपोर्टिंग का उपयोग करते हैं, इसलिए सेंट्री के साथ एकीकरण भी जगह से बाहर नहीं होगा, साथ ही Django भी।
• प्रदर्शन , क्योंकि हमारे पास बहुत सारे कार्य हैं।
• परिपक्वता, विश्वसनीयता और सक्रिय विकास स्पष्ट चीजें हैं। हम एक ऐसे उपकरण की तलाश कर रहे थे जो समर्थित और विकसित हो।
• प्रलेखन की पर्याप्तता - कहीं भी कोई दस्तावेज नहीं ।

कौन सा उपकरण चुनना है?

इन समस्याओं को हल करने के लिए 2018 में बाजार पर क्या विकल्प हैं?

कम महत्वाकांक्षी कार्यों के लिए एक बार, मैंने एक आसान पुस्तकालय लिखा जो अभी भी कुछ परियोजनाओं में उपयोग किया जाता है। पृष्ठभूमि में कार्यों को संचालित करना और प्रदर्शन करना आसान है। लेकिन एक ही समय में, न तो दलालों की आवश्यकता होती है (न ही सेलेरी, न ही अन्य), केवल uwsgi एप्लिकेशन सर्वर, जिसमें स्पूलर होता है, एक ऐसी चीज है जो एक अलग कार्यकर्ता के रूप में शुरू होती है। यह एक बहुत ही सरल उपाय है - सभी कार्यों को फाइलों में सशर्त रूप से संग्रहीत किया जाता है। सरल परियोजनाओं के लिए, यह पर्याप्त है, लेकिन हमारे लिए यह पर्याप्त नहीं था।

किसी तरह हमने माना:

• अजवाइन (गिटहब पर 10K सितारे);
• आरक्यू (गिटहब पर 5K सितारे);
• ह्यूय (गीथहब पर 2K सितारे);
• ड्रामातिक (गीथहब पर 1K सितारे);
• टास्किगर (गीथहब पर 0.5K सितारे);
• हवा का प्रवाह? लुइगी?

होनहार उम्मीदवार 2018

अब मैं आपका ध्यान Dramatiq की ओर आकर्षित करना चाहता हूँ। यह निपुण सेलेरी का एक पुस्तकालय है, जो अजवाइन के सभी नुकसानों को जानता था और सब कुछ फिर से लिखने का फैसला किया, केवल बहुत ही खूबसूरती से। Dramatiq के लाभ:

• सभी आवश्यक सुविधाओं का एक सेट।
• उत्पादकता पर पैनापन।
• प्रोमेथियस के लिए संतरी और मैट्रिक्स समर्थन बॉक्स से बाहर
• एक छोटा और स्पष्ट रूप से लिखित कोड आधार, कोड ऑटोरेलोड।

कुछ समय पहले, Dramatiq को लाइसेंस की समस्या थी: पहले AGPL था, फिर इसे LGPL द्वारा बदल दिया गया। लेकिन अब आप कोशिश कर सकते हैं।

लेकिन 2016 में, सेलेरी के अलावा, लेने के लिए कुछ खास नहीं था। हमें इसकी समृद्ध कार्यक्षमता पसंद आई, और फिर इसने हमारे कार्यों को आदर्श रूप से अनुकूल किया, क्योंकि तब भी यह परिपक्व और कार्यात्मक था:

• समय-समय पर कार्य बॉक्स से बाहर होते थे;
• कई दलालों का समर्थन किया;
• Django और संतरी के साथ एकीकृत।

परियोजना सुविधाएँ

मैं आपको हमारे संदर्भ के बारे में बताऊंगा, ताकि आगे की कहानी स्पष्ट हो जाए।

हम रेडिस का उपयोग एक संदेश दलाल के रूप में करते हैं । मैंने कई कहानियां और अफवाहें सुनी हैं कि रेडिस संदेश खो रहा है, कि यह एक संदेश दलाल बनने के लिए अनुकूलित नहीं है। उत्पादन अनुभव पर, यह पुष्टि नहीं की गई है, लेकिन, जैसा कि यह पता चला है, रेडिस अब RabbitMQ की तुलना में अधिक कुशलता से काम करता है (यह सेलेरी के साथ है, कम से कम, जाहिर है, समस्या दलालों के साथ एकीकरण कोड में है)। संस्करण 4 में, रेडिस ब्रोकर तय किया गया था, इसने वास्तव में पुनरारंभ के दौरान कार्यों को खोना बंद कर दिया और काफी काम करता है। 2016 में, सेलेरी ने रेडिस को छोड़ने और रैबिटएमक्यू के साथ एकीकरण पर ध्यान केंद्रित करने जा रहा था, लेकिन, सौभाग्य से, ऐसा नहीं हुआ।

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

हम परिणामों को संग्रहीत करने के लिए परिणाम बैकएंड का उपयोग नहीं करते हैं , क्योंकि हम उन परिणामों को स्वयं संग्रहीत करना चाहते हैं जहां हम चाहते हैं, और उन्हें जिस तरह से हम चाहते हैं, उन्हें जांचें। हम नहीं चाहते कि सेलेरी हमारे लिए ऐसा करे।

हम एक कंकड़ पूल का उपयोग करते हैं, अर्थात, प्रक्रिया कार्यकर्ता जो अतिरिक्त संगामिति के लिए प्रक्रियाओं के अलग-अलग कांटे बनाते हैं।

काम की इकाई

हम उन मूल तत्वों पर चर्चा करेंगे, जिन्होंने आज तक सेलेरी की कोशिश नहीं की है, लेकिन केवल करने जा रहे हैं। सेलेरी के लिए काम की इकाई एक चुनौती है । मैं एक सरल कार्य का एक उदाहरण दूंगा जो एक ईमेल भेजता है।

सरल समारोह और डेकोरेटर:

@current_app.task def send_email(email: str): print(f'Sending email to email={email}') 

कार्य शुरू करना सरल है: या तो हम फ़ंक्शन को कॉल करते हैं और कार्य रनटाइम में भेजा जाएगा (send_email (ईमेल = "python@example.com")), या कार्यकर्ता में, अर्थात पृष्ठभूमि में कार्य का बहुत प्रभाव:

 send_email.delay(email="python@example.com") send_email.apply_async( kwargs={email: "python@example.com"} ) 

उच्च भार के तहत सेलेरी के साथ काम करने के दो साल के लिए, हम अच्छे फॉर्म के नियमों के साथ आए हैं। बहुत सारी रेक थीं, हमने सीखा कि उनके आसपास कैसे जाना है, और मैं कैसे साझा करूँगा।

कोड डिजाइन

कार्य में भिन्न तर्क हो सकते हैं। सामान्य तौर पर, सेलेरी आपको फ़ाइलों या पैकेज कार्यों में कार्यों को रखने या उन्हें कहीं से आयात करने में मदद करती है। कभी-कभी आपको एक मॉड्यूल में व्यावसायिक तर्क का ढेर मिलता है। हमारी राय में, आवेदन की प्रतिरूपकता के दृष्टिकोण से सही दृष्टिकोण कार्य में न्यूनतम तर्क रखना है। हम कोड के "ट्रिगर" के रूप में केवल पहेलियों का उपयोग करते हैं। यही है, कार्य अपने आप में तर्क नहीं रखता है, लेकिन पृष्ठभूमि में कोड के लॉन्च को ट्रिगर करता है।

 @celery_app.task(queue='...') def run_regular_update(provider_account_id, *args, **kwargs): """...""" flow = flows.RegularSyncProviderAccountFlow(provider_account_id) return flow.run(*args, **kwargs) 

हम सभी कोड को बाहरी कक्षाओं में डालते हैं जो कुछ अन्य वर्गों का उपयोग करते हैं। सभी कार्यों में अनिवार्य रूप से दो लाइनें शामिल हैं।

मापदंडों में सरल वस्तुओं

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

यदि आप ऐसा नहीं करते हैं, तो हमने रेडिस में खपत मेमोरी का एक बहुत बड़ा मिश्रण देखा। संदेश अधिक मेमोरी लेना शुरू कर देता है, नेटवर्क बहुत अधिक लोड होता है, संसाधित कार्यों (प्रदर्शन) की संख्या कम हो जाती है। जब तक ऑब्जेक्ट पूरा हो जाता है, तब तक कार्य अप्रासंगिक हो जाते हैं, ऑब्जेक्ट पहले ही हटा दिया गया है। क्रमबद्ध होने के लिए आवश्यक डेटा - पाइथन में JSON में सब कुछ अच्छी तरह से क्रमबद्ध नहीं है। हमें उस अवसर की आवश्यकता थी, जब कार्यों को पुन: प्रयास करें, किसी तरह जल्दी से इस डेटा के साथ क्या करना है, यह तय करें, इसे फिर से प्राप्त करें, उन पर कुछ चेक चलाएँ

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

बेरोजगारी की समस्या

सेलेरी डेवलपर्स खुद इस दृष्टिकोण की सलाह देते हैं। जब कोड अनुभाग दोहराया जाता है, तो कोई साइड इफेक्ट नहीं होना चाहिए, परिणाम समान होना चाहिए। यह हमेशा प्राप्त करना आसान नहीं होता है, खासकर अगर कई सेवाओं के साथ बातचीत होती है, या दो-चरण का काम होता है।

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

पिछड़ी अनुकूलता

जब हमने एप्लिकेशन को लागू किया तो हमारे कुछ रोचक दुष्प्रभाव थे। इससे कोई फर्क नहीं पड़ता कि आप किस प्रकार की तैनाती का उपयोग करते हैं (नीला + हरा या रोलिंग अद्यतन), हमेशा एक ऐसी स्थिति होगी जहां पुराना सेवा कोड नए कार्यकर्ता कोड के लिए संदेश बनाता है, और इसके विपरीत, पुराने कार्यकर्ता को नए सेवा कोड से संदेश प्राप्त होता है, क्योंकि यह पहले "रोल आउट" करता है। और वहाँ यातायात चला गया।

हमने त्रुटियों और खोए हुए कार्यों को तब तक पकड़ा जब तक हमने सीखा कि रिलीज के बीच पिछड़े संगतता को कैसे बनाए रखा जाए। पिछड़ी अनुकूलता यह है कि रिलीज के बीच कार्यों को सुरक्षित रूप से काम करना चाहिए, कोई फर्क नहीं पड़ता कि इस कार्य में क्या पैरामीटर आते हैं। इसलिए, सभी कार्यों में अब हम एक "रबर" हस्ताक्षर (** kwargs) बना रहे हैं। जब आपको अगली रिलीज़ में एक नया पैरामीटर जोड़ने की आवश्यकता होती है, तो आप इसे नए रिलीज़ में ** kwargs से लेंगे, लेकिन इसे पुराने में नहीं लेंगे - कुछ भी नहीं टूटेगा। जैसे ही हस्ताक्षर बदलते हैं, और सेलेरी इसके बारे में नहीं जानता है, यह दुर्घटनाग्रस्त हो जाता है और यह त्रुटि देता है कि कार्य में ऐसा कोई पैरामीटर नहीं है।

इस तरह की समस्याओं से बचने का एक अधिक कठोर तरीका है कि रिलीज के बीच कार्य कतारों को संस्करणबद्ध किया जाए, लेकिन इसे लागू करना काफी कठिन है और हमने इसे अभी के लिए बैकलॉग में छोड़ दिया है।

समय समाप्ति

अपर्याप्त संख्या या गलत टाइमआउट के कारण समस्याएं उत्पन्न हो सकती हैं।

किसी कार्य के लिए टाइमआउट सेट नहीं करना बुराई है। इसका मतलब यह है कि आप यह नहीं समझते हैं कि कार्य क्या चल रहा है, व्यापार तर्क कैसे काम करना चाहिए।

इसलिए, हमारे सभी कार्यों को टाइमआउट के साथ लटका दिया जाता है, जिसमें सभी कार्यों के लिए वैश्विक भी शामिल हैं, और प्रत्येक विशिष्ट कार्य के लिए टाइमआउट भी निर्धारित हैं।

Affixed होना चाहिए: soft_limit_timeout और समय सीमा समाप्त हो रही है।

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

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

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

नीति फिर से लें

उन कार्यों के लिए जिन्हें दोहराया जा सकता है, या जो विफल हो सकते हैं, हम रिट्री पॉलिसी का उपयोग करते हैं। लेकिन हम इसका उपयोग सावधानीपूर्वक करते हैं ताकि बाहरी सेवाओं पर काबू न पाए। यदि आप एक घातीय बैकऑफ़ निर्दिष्ट किए बिना कार्यों को जल्दी से दोहराते हैं, तो एक बाहरी सेवा, या शायद एक आंतरिक एक, बस इसे खड़ा नहीं कर सकता है।

पैरामीटर retry_backoff , retry_jitter और max_retries को स्पष्ट रूप से निर्दिष्ट करना अच्छा होगा, विशेष रूप से max_retries। retry_jitter - एक पैरामीटर जो आपको थोड़ी अराजकता लाने की अनुमति देता है ताकि कार्य एक ही समय में दोहराना शुरू न करें।

स्मृति लीक

दुर्भाग्य से, मेमोरी लीक बहुत आसान है, और उन्हें ढूंढना और ठीक करना मुश्किल है।

सामान्य तौर पर, पायथन में मेमोरी के साथ काम करना बहुत विवादास्पद है। आपको यह समझने में बहुत समय और नसों का खर्च होगा कि रिसाव क्यों होता है, और फिर यह पता चलता है कि यह आपके कोड में भी नहीं है। इसलिए, हमेशा, एक परियोजना शुरू करते समय, कार्यकर्ता पर एक स्मृति सीमा डालें: कार्यकर्ता_मैक्स_मेमोरी_पर_चिल्ड ।

यह सुनिश्चित करता है कि OOM किलर एक दिन नहीं आता है, सभी श्रमिकों को नहीं मारता है, और आप सभी कार्यों को नहीं खोते हैं। जरूरत पड़ने पर सेलेरी श्रमिकों को फिर से शुरू करेगी।

प्राथमिकता कार्य

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

हम एक अलग दृष्टिकोण का उपयोग करते हैं - प्राथमिकताओं के लिए अलग कार्यकर्ता , अर्थात्। पुराने तरीके से, हम अलग-अलग "महत्व" के साथ अजवाइन के श्रमिक बनाते हैं:

 celery multi start high_priority low_priority -c:high_priority 2 -c:low_priority 6 -Q:high_priority urgent_notifications -Q:low_priority emails,urgent_notifications 

सेलेरी मल्टी स्टार्ट एक सहायक है जो आपको एक मशीन पर और एक ही कमांड लाइन से पूरे सेलेरी कॉन्फ़िगरेशन को चलाने में मदद करता है। इस उदाहरण में, हम नोड्स (या श्रमिक) बनाते हैं: high_priority और low_priority, 2 और 6 समसामयिक हैं।

दो उच्च_परायणता कार्यकर्ता लगातार अत्यावश्यकता की प्रक्रिया करते हैं। इन श्रमिकों को कोई और नहीं लेगा, वे केवल अत्यावश्यकताएं_नोटबंदी से महत्वपूर्ण कार्यों को पढ़ेंगे।

महत्वहीन कार्यों के लिए निम्न_ पंक्तिबद्धता कतार है। 6 श्रमिक हैं जो अन्य सभी कतारों से संदेश प्राप्त करते हैं। हम अत्यावश्यकता के लिए निम्न_परायणता कार्यकर्ताओं की भी सदस्यता लेते हैं ताकि यदि उच्च_प्रतिनिधि कार्यकर्ता सामना न कर सकें तो वे मदद कर सकें।

हम इस क्लासिक योजना का उपयोग कार्यों को प्राथमिकता देने के लिए करते हैं।

निकालें, रूपांतरण, लोड

ज्यादातर, ईटीएल कार्यों की एक श्रृंखला की तरह दिखता है, जिनमें से प्रत्येक पिछले कार्य से इनपुट प्राप्त करता है।

 @task def download_account_data(account_id) … return account_id @task def process_account_data(account_id, processing_type) … return account_data @task def store_account_data(account_data) … 

उदाहरण के तीन कार्य हैं। अजवाइन में वितरित प्रसंस्करण और कई उपयोगी उपयोगिताओं के लिए एक दृष्टिकोण है, जिसमें चेन फ़ंक्शन शामिल है, जो इस तरह के तीन कार्यों में से एक पाइपलाइन बनाता है:

 chain( download_account_data.s(account_id), process_account_data.s(processing_type='fast'), store_account_data.s() ).delay() 

अजवाइन पाइपलाइन के अलावा ले जाएगा, क्रम में पहला कार्य करें, फिर प्राप्त डेटा को दूसरे में स्थानांतरित करें, और उस डेटा को स्थानांतरित करें जो दूसरा कार्य तीसरे पर लौटता है। इसी तरह से हम सरल ईटीएल पाइपलाइनों को लागू करते हैं।

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

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

बैच कार्य प्रसंस्करण

अब सबसे दिलचस्प बात: क्या होता है जब आपको दो मिलियन उपयोगकर्ताओं को एक ईमेल भेजने की आवश्यकता होती है।

आप सभी उपयोगकर्ताओं को बायपास करने के लिए ऐसा फ़ंक्शन लिखते हैं:

 @task def send_report_emails_to_users(): for user_id in User.get_active_ids(): send_report_email.delay(user_id=user_id) 

हालांकि, सबसे अधिक बार फ़ंक्शन को न केवल उपयोगकर्ता आईडी प्राप्त होगी, बल्कि सामान्य रूप से पूरे उपयोगकर्ता तालिका को भी धोना होगा। प्रत्येक उपयोगकर्ता का अपना कार्य होगा।

इस कार्य में कई समस्याएं हैं:

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

मैंने इसे टास्क फ्लड कहा, चार्ट कुछ इस तरह दिखता है।

ऐसे कार्यों का एक प्रवाह है जो श्रमिक धीरे-धीरे प्रक्रिया करना शुरू करते हैं। निम्न तब होता है जब कार्य एक मास्टर प्रतिकृति का उपयोग करते हैं, पूरी परियोजना दरार करने लगती है, कुछ भी काम नहीं करता है। नीचे हमारे अभ्यास से एक उदाहरण है, जहां DB CPU उपयोग कई घंटों के लिए 100% था, ईमानदार होने के लिए, हम डरने में कामयाब रहे।

समस्या यह है कि सिस्टम उपयोगकर्ताओं की संख्या में वृद्धि के साथ बहुत नीचा है। शेड्यूलिंग से संबंधित कार्य:

• अधिक से अधिक स्मृति की आवश्यकता है;
• लंबे समय तक चलता है और टाइमआउट द्वारा "मारा" जा सकता है।

टास्क की बाढ़ आती है: कार्य कतार में जमा होते हैं और न केवल आंतरिक सेवाओं पर, बल्कि बाहरी लोगों पर भी एक बड़ा भार पैदा करते हैं।

हमने श्रमिकों की प्रतिस्पर्धात्मकता को कम करने की कोशिश की, इससे एक मायने में मदद मिलती है - सेवा पर भार कम हो जाता है। या आप आंतरिक सेवाओं को माप सकते हैं । लेकिन इससे जनरेटर की समस्या का समाधान नहीं होगा, जो अभी भी बहुत कुछ लेता है। और किसी भी तरह से बाहरी सेवाओं के प्रदर्शन पर निर्भरता को प्रभावित नहीं करता है।

टास्क जनरेशन

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

पहले हमने Celery.chunks का उपयोग करने की कोशिश की:

 send_report_email.chunks( ({'user_id': user.id} for user in User.objects.active()), n=100 ).apply_async() 

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

हमने श्रमिकों के लिए rate_limit सेट करने की कोशिश की, ताकि वे प्रति सेकंड निश्चित संख्या में कार्यों को संसाधित करें, और हमें पता चला कि वास्तव में कार्य के लिए rate_limit निर्दिष्ट किया गया है जो कार्यकर्ता के लिए rate_limit है। यही है, यदि आप कार्य के लिए rate_limit निर्दिष्ट करते हैं, तो इसका मतलब यह नहीं है कि कार्य प्रति सेकंड 70 बार किया जाएगा। इसका मतलब है कि कार्यकर्ता इसे प्रति सेकंड 70 बार निष्पादित करेगा, और आपके पास श्रमिकों के साथ क्या है, इसके आधार पर, यह सीमा गतिशील रूप से बदल सकती है, अर्थात। वास्तविक सीमा rate_limit * लेन (कार्यकर्ता)।

यदि कार्यकर्ता शुरू या रोकता है, तो कुल rate_limit बदल जाता है। इसके अलावा, यदि आपके कार्य धीमी गति से होते हैं, तो कार्यकर्ता को भरने वाले कतार में सभी प्रीफैच इन धीमी कार्यों के साथ भरा जाएगा। वर्कर देखता है: “ओह, मेरे पास यह कार्य रेट_लीमिट में है, मैं अब इसे नहीं कर सकता। और कतार में निम्नलिखित सभी कार्य बिल्कुल समान हैं - उन्हें लटका दें! " - और प्रतीक्षा।

Chunkificator

अंत में, हमने फैसला किया कि हम अपना खुद का लेखन करेंगे, और एक छोटा पुस्तकालय बनाया, जिसे चंकसिपेटर कहा जाता था।

 @task @chunkify_task(sleep_timeout=...l initial_chunk=...) def send_report_emails_to_users(chunk: Chunk): for user_id in User.get_active_ids(chunk=chunk): send_report_email.delay(user_id=user_id) 

यह sleep_timeout और initial_chunk लेता है, और खुद को एक नया हिस्सा कहता है। चंक पूर्णांक सूचियों, या ओवर डेट या डेटाइम सूचियों पर एक अमूर्तन है। हम एक फ़ंक्शन को चंक पास करते हैं जो केवल इस चंक के साथ उपयोगकर्ताओं को प्राप्त करता है, और केवल उस चंक के लिए कार्य चलाता है।

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

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

लाइब्रेरी को Python 3.6+ के लिए लागू किया गया है और यह GitHub पर उपलब्ध है। एक अति सूक्ष्म अंतर है जिसे मैं ठीक करने की योजना बना रहा हूं, लेकिन अभी के लिए डेटाइम-चंक को अचार बनाने वाले धारावाहिक की आवश्यकता है - कई ऐसा करने में सक्षम नहीं होंगे।

कुछ अलंकारिक प्रश्न - यह सारी जानकारी कहाँ से आई? हमें कैसे पता चला कि हमें समस्याएं थीं? आप कैसे जानते हैं कि एक समस्या जल्द ही गंभीर हो जाएगी और आपको इसे पहले ही हल करने की आवश्यकता है?

जवाब, ज़ाहिर है, निगरानी।

निगरानी

मुझे वास्तव में निगरानी पसंद है, मुझे हर चीज की निगरानी करना और अपनी उंगली को नाड़ी पर रखना पसंद है। यदि आप अपनी उंगली को नाड़ी पर नहीं रखते हैं, तो आप लगातार रेक पर कदम रखेंगे।

मानक निगरानी प्रश्न:

• क्या वर्तमान कार्यकर्ता / संगामिति कॉन्फ़िगरेशन लोड को संभालता है?
• कार्य निष्पादन समय की गिरावट क्या है?
• कार्य कितने समय तक लाइन में लटका रहता है? अचानक लाइन पहले से ही भीड़ है?

हमने कई विकल्प आजमाए। Celery में एक CLI इंटरफ़ेस है, यह काफी समृद्ध है और देता है:

• निरीक्षण - सिस्टम के बारे में जानकारी;
• नियंत्रण - सिस्टम सेटिंग्स का प्रबंधन;
• purge - स्पष्ट कतारों (बल majeure);
• ईवेंट - प्रदर्शन किए जा रहे कार्यों के बारे में जानकारी प्रदर्शित करने के लिए यूआई कंसोल।

लेकिन वास्तव में किसी चीज़ की निगरानी करना कठिन है। यह स्थानीय तामझाम के लिए बेहतर है, या यदि आप रनटाइम पर कुछ rate_limit बदलना चाहते हैं।

एनबी: आपको सीएलआई इंटरफ़ेस का उपयोग करने के लिए उत्पादन ब्रोकर तक पहुंच की आवश्यकता होती है।

सेलेरी फ्लावर आपको सीएलआई के समान ही करने की अनुमति देता है, केवल वेब इंटरफेस के माध्यम से, और यह सब नहीं है। लेकिन यह कुछ सरल रेखांकन बनाता है और आपको मक्खी पर सेटिंग्स बदलने की अनुमति देता है।

सामान्य तौर पर, सेलेरी फ्लावर सिर्फ यह देखने के लिए उपयुक्त है कि छोटे सेटअपों में सब कुछ कैसे काम करता है। इसके अलावा, यह HTTP एपीआई का समर्थन करता है, जो कि ऑटोमेशन लिखते समय सुविधाजनक है।

लेकिन हम प्रोमेथियस पर बस गए। उन्होंने वर्तमान निर्यातक को ले लिया: इसमें निश्चित मेमोरी लीक; अपवाद प्रकारों के लिए जोड़े गए मीट्रिक; कतारों में संदेशों की संख्या के लिए जोड़े गए मीट्रिक; Grafana और आनन्द में अलर्ट के साथ एकीकृत। इसे GitHub पर भी पोस्ट किया गया है, आप इसे यहाँ देख सकते हैं।

ग्राफाना में उदाहरण

सभी अपवादों के लिए उपरोक्त आंकड़े: किन कार्यों के लिए अपवाद। नीचे कार्यों को पूरा करने का समय है।

सेलेरी में क्या गायब है?

यह एक पत्तेदार रूपरेखा है, इसमें बहुत सी चीजें हैं, लेकिन हम गायब हैं! पर्याप्त छोटी विशेषताएं नहीं हैं, जैसे:

• विकास के दौरान कोड को स्वचालित रूप से पुनः लोड करना - इस सेलेरी का समर्थन नहीं करता है - पुनरारंभ करें।
• प्रोमेथियस के लिए मेट्रिक्स बॉक्स से बाहर हैं , लेकिन ड्रामैटिक कर सकते हैं।
• टास्क लॉक के लिए सपोर्ट - ताकि एक बार में केवल एक ही टास्क चले। आप इसे स्वयं कर सकते हैं, लेकिन ड्रामैटिक और टास्कटीगर में एक सुविधाजनक सज्जाकार है जो यह सुनिश्चित करता है कि अन्य सभी समान कार्य अवरुद्ध हो जाएंगे।
• एक कार्य के लिए Rate_limit - कार्यकर्ता के लिए नहीं।

निष्कर्ष

इस तथ्य के बावजूद कि सेलेरी एक ढांचा है जो उत्पादन में कई उपयोग करता है, इसमें 3 पुस्तकालय शामिल हैं - सेलेरी, कोम्बू और बिलार्ड। इन सभी पुस्तकालयों को सह-डेवलपर्स द्वारा विकसित किया गया है, और वे एक निर्भरता को छोड़ सकते हैं और आपकी विधानसभा को तोड़ सकते हैं।

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

वास्तव में, निष्कर्ष इतने दुखी नहीं हैं। अजवाइन अपने कार्यों के साथ हमारे फिनटेक प्रोजेक्ट में हमारे लोड के तहत आता है। हमने अनुभव प्राप्त किया है जो मैंने आपके साथ साझा किया है, और आप हमारे समाधानों को लागू कर सकते हैं या उन्हें परिष्कृत कर सकते हैं और आपकी सभी कठिनाइयों को भी दूर कर सकते हैं।

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

संपर्क वक्ता ओलेग चुरकिन : बहूस , फेसबुक और गीथूब ।

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

हमारे पेशेवर पायथन सम्मेलन में शामिल हों - अपनी रिपोर्ट यहां जमा करें , अपना टिकट यहां बुक करें । इस बीच, तैयारी चल रही है, मॉस्को पायथन कॉन्फ + ++ 2018 के लेख यहां दिखाई देंगे।