Django 3.0 अतुल्यकालिक होगा

एंड्रयू गॉडविन ने DEP 0009: Async- सक्षम Django को 9 मई को प्रकाशित किया, और 21 जुलाई को Django तकनीकी परिषद द्वारा अनुमोदित किया गया था, इसलिए यह आशा है कि Django 3.0 की रिहाई से उनके पास कुछ दिलचस्प करने का समय होगा। यह पहले ही हबर की टिप्पणियों में कहीं उल्लेख किया गया था, लेकिन मैंने इस खबर को एक व्यापक दर्शकों के लिए अनुवाद करके तय किया - मुख्य रूप से उन लोगों के लिए, जो मेरे जैसे, विशेष रूप से Django की खबर का पालन नहीं करते हैं।

एसिंक्रोनस पायथन को कई वर्षों के लिए विकसित किया गया है, और Django पारिस्थितिकी तंत्र में, हमने इसे वेब सॉकेट समर्थन पर प्राथमिक फोकस के साथ चैनल में प्रयोग किया है।

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

लाभ नीचे दिए गए प्रेरणा अनुभाग में वर्णित हैं, लेकिन सामान्य निष्कर्ष यह है कि हम अतुल्यकालिक Django से इतना अधिक प्राप्त करते हैं कि यह कड़ी मेहनत के लायक है। मेरा यह भी मानना ​​है कि एक पुनरावृत्त, समुदाय समर्थित तरीके में बदलाव करना बहुत महत्वपूर्ण है जो एक या दो पुराने योगदानकर्ताओं पर निर्भर नहीं करेगा जो बाहर जला सकते हैं।

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

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

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

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

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

संक्षिप्त विवरण

हम एसिंक्रोनस अभ्यावेदन, मिडलवेयर, ORM और अन्य महत्वपूर्ण तत्वों के लिए Django के लिए समर्थन जोड़ने जा रहे हैं।

यह थ्रेड्स में सिंक्रोनस कोड चलाकर किया जाएगा, धीरे-धीरे इसे एसिंक्रोनस कोड के साथ बदल दिया जाएगा। सिंक्रोनस API मौजूद रहेगा और पूरी तरह से समर्थित होगा, और समय के साथ शुरू में एसिंक्रोनस कोड के लिए सिंक्रोनस रैपर में बदल जाएगा।

ASGI मोड Django को एक मूल एसिंक्रोनस एप्लिकेशन के रूप में लॉन्च करेगा। WSGI मोड हर बार एक अलग ईवेंट लूप को ट्रिगर करेगा जब Django एक्सेस किया जाता है, ताकि एसिंक्रोनस लेयर सिंक्रोनस सर्वर के साथ संगत हो।

ORM के आस-पास गुणा करना जटिल है और सिंक्रोनस ORM कोड को चलाने के लिए कनेक्शन संदर्भों और स्टिकी थ्रेड्स की एक नई अवधारणा की आवश्यकता है।

Django के कई हिस्से सिंक में काम करना जारी रखेंगे, और हमारी प्राथमिकता दोनों शैलियों में विचारों को लिखने वाले उपयोगकर्ताओं का समर्थन करना होगा, जिससे वे उस प्रस्तुति के लिए सबसे अच्छी शैली का चयन कर सकें, जिस पर वे काम कर रहे हैं।

कुछ फ़ंक्शंस, जैसे कि टेम्प्लेट और कैशिंग, को अपने स्वयं के अलग-अलग डीईपी और अध्ययनों की आवश्यकता होगी कि उन्हें पूरी तरह से अतुल्यकालिक कैसे बनाया जाए। यह DEP मुख्य रूप से HTTP-मिडिलवेयर-व्यू फ्लो और ORM पर केंद्रित है।

पूरी पिछड़ी अनुकूलता रहेगी। एक मानक Django 2.2 परियोजना को अतुल्यकालिक Django (यह 3.0 या 3.1 होना चाहिए) में बिना बदलाव के चलना चाहिए।

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

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

विनिर्देश

समग्र लक्ष्य Django के हर एक हिस्से को बनाना है, जिसे अवरुद्ध किया जा सकता है - अर्थात्, केवल सीपीयू-बाउंड गणना नहीं है - अतुल्यकालिक बन जाते हैं (ताले के बिना एक अतुल्यकालिक घटना लूप में चलाते हैं)।

इसमें निम्नलिखित विशेषताएं शामिल हैं:

• मध्यवर्ती परतें (मिडलवेयर)
• प्रस्तुति (दृश्य)
• ORM
• टेम्पलेट्स
• परीक्षण
• कैशिंग
• प्रपत्र सत्यापन
• ईमेल

हालांकि, इसमें अंतर्राष्ट्रीयकरण जैसी चीजें शामिल नहीं हैं, जो किसी भी प्रदर्शन का लाभ नहीं लाएगा, क्योंकि यह एक सीपीयू-बाउंड कार्य है जो जल्दी से चलता है, या प्रबंधन कमांड के माध्यम से लॉन्च होने पर एकल-थ्रेडेड माइग्रेशन होते हैं।

प्रत्येक व्यक्तिगत फ़ंक्शन जो अंदर अतुल्यकालिक हो जाता है, वह एक तुल्यकालिक इंटरफ़ेस भी प्रदान करेगा जो कि वर्तमान एपीआई (2.2 में) के साथ निकट भविष्य के लिए संगत है - हम इसे बेहतर बनाने के लिए समय के साथ बदल सकते हैं, लेकिन तुल्यकालिक एपीआई कहीं भी नहीं जाएंगे।

यह कैसे तकनीकी रूप से हासिल किया गया है इसका अवलोकन नीचे दिया गया है, और फिर विशिष्ट क्षेत्रों के लिए विशिष्ट कार्यान्वयन विवरण दिए गए हैं। यह Django के सभी कार्यों के लिए संपूर्ण नहीं है, लेकिन यदि हम इस प्रारंभिक लक्ष्य को प्राप्त करते हैं, तो हम लगभग सभी उपयोग मामलों को शामिल करेंगे।

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

तकनीकी समीक्षा

वह सिद्धांत जो हमें समानांतर में समकालिक और अतुल्यकालिक कार्यान्वयन को बनाए रखने की अनुमति देता है, एक शैली को दूसरे के अंदर चलाने की क्षमता है।

प्रत्येक फ़ंक्शन कार्यान्वयन के तीन चरणों से गुजरेगा:

• केवल सिंक्रोनस (हम यहां हैं)
• अतुल्यकालिक आवरण के साथ तुल्यकालिक कार्यान्वयन
• तुल्यकालिक आवरण के साथ अतुल्यकालिक कार्यान्वयन

अतुल्यकालिक आवरण

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

इसके लिए टूलकिट पहले से ही asgiref में फ़ंक्शन sync_to_async to_async के रूप में उपलब्ध है, जो अपवाद हैंडलिंग या थ्रेडलोकल्स (इस पर नीचे) जैसी चीज़ों का समर्थन करता है।

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

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

ऐसी स्थितियों में, "स्टिकी थ्रेड" की आवश्यकता होती है, जिसमें एसिंक्रोनस सन्दर्भ क्रमिक रूप से एक ही धागे में सभी सिंक्रोनस कोड को ओआरएम और अन्य थ्रेड-सेंसिटिव भागों के सही व्यवहार को बनाए रखते हुए इसे थ्रेड पूल में धकेलने की बजाय कॉल करता है। Django के सभी हिस्सों पर हमें संदेह है कि पूरे ORM सहित इसे जरूरत है, sync_to_async संस्करण का उपयोग करेगा, जो इसे ध्यान में रखता है, इसलिए सब कुछ डिफ़ॉल्ट रूप से सुरक्षित है। उपयोगकर्ता प्रतिस्पर्धी क्वेरी निष्पादन के लिए इसे चुनिंदा रूप से अक्षम करने में सक्षम होंगे - अधिक जानकारी के लिए नीचे "ORM" देखें।

अतुल्यकालिक कार्यान्वयन

अगला कदम फ़ंक्शन के कार्यान्वयन को एसिंक्रोनस कोड में फिर से लिखना है और फिर एक रैपर के माध्यम से सिंक्रोनस इंटरफ़ेस प्रस्तुत करना है जो एक बार के ईवेंट लूप में एसिंक्रोनस कोड को निष्पादित करता है। यह पहले से ही async में उपलब्ध है async_to_sync फ़ंक्शन के रूप में।

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

यह सामान्य अवलोकन लगभग सभी Django फ़ंक्शंस के साथ काम करता है जो अतुल्यकालिक हो जाना चाहिए, सिवाय उन जगहों के लिए जिनके लिए पायथन एसिंक्रोनस फ़ंक्शन समकक्ष प्रदान नहीं करता है जो हम पहले से ही उपयोग करते हैं। परिणाम या तो यह परिवर्तन होगा कि कैसे Django अतुल्यकालिक मोड में अपना एपीआई प्रस्तुत करता है, या पायथन कोर डेवलपर्स के साथ काम करके पायथन एसिंक्रोनस सुविधाओं को विकसित करने में मदद करता है।

Threadlocals

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

थ्रेडलोकल का उपयोग करके दो विकल्पों में विभाजित किया जा सकता है:

• "संदर्भ स्थानीय", जहां कुछ स्टैक-आधारित संदर्भ के भीतर एक मूल्य की आवश्यकता होती है, जैसे कि अनुरोध। वर्तमान भाषा सेट करने के लिए यह आवश्यक है।
• "ट्रू थ्रेडोकॉल्स", जहां संरक्षित कोड वास्तव में दूसरे थ्रेड से कॉल करने के लिए असुरक्षित है। यह डेटाबेस से कनेक्ट करने के लिए है।

पहली नज़र में, ऐसा लग सकता है कि पायथन में नए संदर्भ मॉड्यूल का उपयोग करके "संदर्भ स्थानीय लोगों" को हल किया जा सकता है, लेकिन Django 3.0 को अभी भी पायथन 3.6 का समर्थन करना होगा, जबकि यह मॉड्यूल 3.7 में दिखाई दिया था। इसके अलावा, contextvars विशेष रूप से संदर्भ से छुटकारा पाने के लिए डिज़ाइन किया गया है, उदाहरण के लिए, एक नई धारा में, जबकि हमें इन मानों को सहेजने की जरूरत है ताकि वे sync_to_async रूप में कार्य करने के लिए sync_to_async और async_to_sync फ़ंक्शन को अनुमति दे sync_to_async । जब Django केवल 3.7 और बाद में समर्थन करेगा, तो हम contextvars का उपयोग करने पर विचार कर contextvars , लेकिन इसके लिए Django में काफी काम करने की आवश्यकता होगी।

यह पहले से ही asgiref Local साथ हल हो चुका है, जो कि coroutines और धागे के साथ संगत है। अब यह contextvars उपयोग नहीं करता है, लेकिन हम इसे कुछ परीक्षण के बाद 3.6 के लिए बैकपोर्ट के साथ काम कर सकते हैं।

दूसरी ओर, सही थ्रेडोकोल, वर्तमान थ्रेड में काम करना जारी रख सकते हैं। हालाँकि, हमें ऐसी वस्तुओं को किसी अन्य स्ट्रीम में लीक होने से रोकने के लिए अधिक सावधान रहना चाहिए; जब प्रस्तुति को एक ही थ्रेड में निष्पादित नहीं किया जाता है, लेकिन प्रत्येक ORM कॉल ("सिंक्रोनस कार्यान्वयन, एसिंक्रोनस आवरण" चरण के दौरान) के लिए एक थ्रेड को जन्म देता है, कुछ चीजें जो सिंक्रोनस मोड में संभव थीं, अतुल्यकालिक मोड में असंभव होगी।

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

तुल्यकालिक और अतुल्यकालिक इंटरफेस के लिए एक साथ समर्थन

Django को पोर्ट करने का प्रयास करते समय हम जो बड़ी समस्याएं हैं, उनमें से एक यह है कि पायथन आपको एक ही नाम के साथ फ़ंक्शन के तुल्यकालिक और अतुल्यकालिक संस्करण बनाने की अनुमति नहीं देता है।

इसका मतलब यह है कि आप केवल ऐसा एपीआई नहीं बना सकते हैं और कुछ ऐसा काम कर सके:

 #   value = cache.get("foo") #   value = await cache.get("bar") 

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

(नोट: इसका कारण यह है कि पायथन अतुल्यकालिक कार्यों को "एक तुल्यकालिक __acall__ रूप में लागू करता है, जो एक coroutine को लौटाता है", जैसे कि "ऑब्जेक्ट पर __acall__ विधि को कॉल करना"। अतुल्यकालिक संदर्भ प्रबंधकों और __acall__ में यह समस्या नहीं है, क्योंकि। उनके पास अलग तरीके हैं __aiter__ और __aenter__ ।)

इसे ध्यान में रखते हुए, हमें तुल्यकालिक और अतुल्यकालिक कार्यान्वयन के नामस्थानों को एक दूसरे से अलग रखना चाहिए ताकि वे संघर्ष न करें। हम नामित तर्क sync=True साथ ऐसा कर सकते हैं, लेकिन इससे फ़ंक्शंस / विधियों के भ्रमित करने वाले निकाय हो जाते हैं और async def के उपयोग को रोकता है, और आपको गलती से इस तर्क को लिखने की अनुमति भी देता है। जब आप इसे अतुल्यकालिक रूप से कॉल करना चाहते थे तो एक सिंक्रोनस विधि के लिए एक यादृच्छिक कॉल खतरनाक है।

Django कोड बेस में अधिकांश स्थानों के लिए प्रस्तावित समाधान कार्यों के अतुल्यकालिक कार्यान्वयन के नामों के लिए एक प्रत्यय प्रदान करना है - उदाहरण के लिए, cache.get_async के अलावा सिंक्रोनस cache.get । यद्यपि यह एक बदसूरत समाधान है, यह कोड को देखते समय त्रुटियों का पता लगाना बहुत आसान बनाता है (आपको _async विधि के साथ await उपयोग करना चाहिए)।

दृश्य और HTTP हैंडलिंग

दृश्य शायद अतुल्यकालिक की उपयोगिता की आधारशिला हैं, और हम अधिकांश उपयोगकर्ताओं से अतुल्यकालिक और तुल्यकालिक कोड के बीच चयन करने की अपेक्षा करते हैं।

Django दो तरह के विचारों का समर्थन करेगा:

• तुल्यकालिक प्रतिनिधित्व, परिभाषित, अब, तुल्यकालिक फ़ंक्शन या वर्ग के साथ तुल्यकालिक __call__
• एक एसिंक्रोनस फ़ंक्शन (एक __call__ वापस करके) या एसिंक्रोनस __call__ साथ एक वर्ग द्वारा परिभाषित अतुल्यकालिक प्रतिनिधित्व।

उन्हें BaseHandler द्वारा संभाला जाएगा, जो URL रिज़ॉल्वर से प्राप्त दृश्य की जांच करेगा और तदनुसार कॉल करेगा। बेस हैंडलर को अतुल्यकालिक बनने के लिए Django का पहला हिस्सा होना चाहिए, और हमें async_to_sync का उपयोग करके WSGI हैंडलर को अपने स्वयं के इवेंट लूप में कॉल करने के लिए संशोधित करना होगा।

इंटरमीडिएट लेयर (मिडलवेयर) या ATOMIC_REQUESTS जैसी सेटिंग्स, जो गैर-अतुल्यकालिक सुरक्षित कोड (उदाहरण के लिए, atomic() ब्लॉक) में विचारों को ATOMIC_REQUESTS , काम करना जारी रखेंगी, लेकिन उनकी गति प्रभावित होगी (उदाहरण के लिए, atomic() साथ दृश्य के अंदर समानांतर ORM कॉल का निषेध atomic() )।

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

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

सभी अतुल्यकालिक HTTP फ़ंक्शंस WSGI के अंदर काम करेंगे, जिसमें लंबे समय तक मतदान और धीमी प्रतिक्रियाएं शामिल हैं, लेकिन वे प्रत्येक कनेक्शन के लिए एक थ्रेड / प्रक्रिया को ले कर अब उतने ही अक्षम होंगे। ASGI सर्वर केवल वही होंगे जो कई समवर्ती अनुरोधों का कुशलतापूर्वक समर्थन कर सकते हैं, साथ ही चैनल जैसे एक्सटेंशन के उपयोग के लिए गैर-HTTP प्रोटोकॉल जैसे कि WebSocket को भी संभाल सकते हैं।

मध्यवर्ती परतें

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

Django बिचौलियों को अब एक स्टैक के रूप में व्यवस्थित किया जाता है, जिसमें प्रत्येक मिडलवेयर को ऑर्डर मिडलवेयर (या स्टैक पर सबसे कम मिडलवेयर के लिए दृश्य) चलाने के लिए get_response मिलता है। हालाँकि, हमें पिछड़ी अनुकूलता के लिए सिंक्रोनस और एसिंक्रोनस मिडलवेयर के मिश्रण को बनाए रखने की आवश्यकता है, और ये दोनों प्रकार एक दूसरे को मूल रूप से एक्सेस नहीं कर पाएंगे।

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

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

ORM

ORM कोड आकार के मामले में Django का सबसे बड़ा हिस्सा है और एसिंक्रोनस में परिवर्तित करने के लिए सबसे मुश्किल है।

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

ओआरएम की समस्या दो मुख्य श्रेणियों में आती है - थ्रेड्स और इंप्लांट ब्लॉकिंग।

धाराओं

ORM के साथ मुख्य समस्या यह है कि Django को एक ही वैश्विक connections ऑब्जेक्ट के आसपास डिज़ाइन किया गया है, जो जादुई रूप से आपको आपके वर्तमान थ्रेड के लिए सही कनेक्शन देता है।

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

सौभाग्य से, कनेक्शन ऑब्जेक्ट थ्रेड्स के बीच कम से कम पोर्टेबल हैं, हालांकि उन्हें एक ही समय में दो थ्रेड्स से नहीं बुलाया जा सकता है। Django पहले से ही ORM कोड में डेटाबेस ड्राइवरों के लिए थ्रेड-सेफ्टी की परवाह करता है, और इसलिए हमारे पास ठीक से काम करने के लिए इसके व्यवहार को बदलने के लिए एक जगह है।

हम connections ऑब्जेक्ट को संशोधित करेंगे ताकि यह asgiref.local और थ्रेड्स दोनों को समझता है - asgiref.local से कुछ कोड का पुन: उपयोग कर रहा है, लेकिन अतिरिक्त तर्क के अतिरिक्त के साथ। कनेक्शंस को एसिंक्रोनस और सिंक्रोनस कोड में साझा किया जाएगा जो एक दूसरे को कहते हैं - sync_to_async और async_to_sync माध्यम से गुजरने के संदर्भ में - और सिंक्रोनस कोड को एक async_to_sync थ्रेड में क्रमिक रूप से निष्पादित करने के लिए मजबूर किया जाएगा, इसलिए यह काम नहीं करेगा एक ही समय में धागा-सुरक्षा को तोड़ने।

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

फिलहाल, Django के पास कनेक्शन जीवन चक्र प्रबंधन नहीं है जो हैंडलर वर्ग से संकेतों से स्वतंत्र है, और इसलिए हम इन "कनेक्शन संदर्भों" को बनाने और साफ़ करने के लिए उनका उपयोग करेंगे। प्रलेखन को यह स्पष्ट करने के लिए भी अपडेट किया जाएगा कि अनुरोध / प्रतिक्रिया चक्र के बाहर कनेक्शन को ठीक से कैसे संभालना है; वर्तमान कोड में भी, कई उपयोगकर्ता नहीं जानते हैं कि किसी भी लंबे समय से चल रही प्रबंधन टीम को समय-समय पर सही काम करने के लिए close_old_connections को कॉल करना होगा।

पिछड़ी संगतता का अर्थ है कि हमें उपयोगकर्ताओं को किसी भी समय किसी भी यादृच्छिक कोड से connections तक पहुंचने की अनुमति देनी चाहिए, लेकिन हम केवल समकालिक कोड के लिए ही इसकी अनुमति देंगे; हम यह सुनिश्चित करेंगे कि कोड एक "कनेक्शन संदर्भ" में लिपटे हुए है, अगर यह एक दिन से, अतुल्यकालिक है।

ऐसा प्रतीत हो सकता है कि transaction.atomic() के अलावा transaction.atomic() को जोड़ना अच्छा होगा और उपयोगकर्ता को उनमें से एक के अंदर सभी कोड चलाने की आवश्यकता होगी, लेकिन इससे भ्रम होता है कि आप क्या करते हैं उनमें से एक दूसरे के अंदर है।

इसके बजाय, मैं एक नया संदर्भ प्रबंधक बनाने का सुझाव देता हूं db.new_connections() जो इस व्यवहार को सक्षम बनाता है, और जब भी इसे बुलाया जाता है, तो इसे एक नया कनेक्शन बनाते हैं, और इसके भीतर मनमाने atomic() घोंसले के शिकार की अनुमति देते हैं।

हर बार जब आप new_connections() ब्लॉक new_connections() , तो Django नए डेटाबेस कनेक्शन के साथ एक नया संदर्भ सेट करता है। ब्लॉक के बाहर किए गए सभी लेनदेन जारी हैं; कोई भी ORM डेटाबेस के नए कनेक्शन के साथ ब्लॉक के अंदर काम करता है और इस दृष्टिकोण से डेटाबेस को देखेगा। यदि डेटाबेस में लेन-देन अलगाव को सक्षम किया जाता है, जैसा कि आमतौर पर डिफ़ॉल्ट रूप से किया जाता है, तो इसका मतलब है कि ब्लॉक के अंदर नए कनेक्शनों में इसके बाहर किसी भी गैर-लेनदेन द्वारा किए गए परिवर्तनों को नहीं देखा जा सकता है।

इसके अलावा, इस new_connections ब्लॉक के अंदर के कनेक्शन स्वयं इन नए कनेक्शनों पर अतिरिक्त लेनदेन को ट्रिगर करने के लिए atomic() का उपयोग कर सकते हैं। इन दो संदर्भ प्रबंधकों के किसी भी घोंसले के शिकार की अनुमति है, लेकिन हर बार new_connections उपयोग किया जाता है, पहले से खोले गए लेन-देन "निलंबित" होते हैं और एक नए new_connections ब्लॉक new_connections होने तक ORM कॉल को प्रभावित नहीं करते हैं।

यह API कैसे दिख सकता है, इसका एक उदाहरण:

 async def get_authors(pattern): # Create a new context to call concurrently async with db.new_connections(): return [ author.name async for author in Authors.objects.filter(name__icontains=pattern) ] async def get_books(pattern): # Create a new context to call concurrently async with db.new_connections(): return [ book.title async for book in Book.objects.filter(name__icontains=pattern) ] async def my_view(request): # Query authors and books concurrently task_authors = asyncio.create_task(get_authors("an")) task_books = asyncio.create_task(get_books("di")) return render( request, "template.html", { "books": await task_books, "authors": await task_authors, }, ) 

यह कुछ हद तक वाचाल है, लेकिन इस व्यवहार को सक्षम करने के लिए उच्च-स्तरीय शॉर्टकट जोड़ना भी लक्ष्य है (और पायथन 3.6 में asyncio.create_task में 3.7 में asyncio.create_task से संक्रमण को कवर करना)।

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

तात्पर्य ताले

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

यदि आप एक मॉडल उदाहरण लेते हैं और फिर model_instance.related_field उपयोग model_instance.related_field , तो Django पारदर्शी रूप से संबंधित मॉडल की सामग्री को लोड करेगा और आपको इसे लौटाएगा। हालांकि, अतुल्यकालिक कोड में यह संभव नहीं है - ब्लॉकिंग कोड को मुख्य धागे में निष्पादित नहीं किया जाना चाहिए, और विशेषताओं के लिए अतुल्यकालिक पहुंच नहीं है।

सौभाग्य से, Django के पास पहले से ही इसका एक तरीका है - select_related , जो संबंधित फ़ील्ड को पहले से लोड करता है, और कई-से-कई रिश्तों के लिए prefetch_related । यदि आप ORM का उपयोग अतुल्यकालिक रूप से करते हैं, तो हम किसी भी अवरोधक संचालन को प्रतिबंधित करेंगे, जैसे कि विशेषताओं के लिए पृष्ठभूमि का उपयोग, और इसके बजाय यह इंगित करने में त्रुटि लौटाती है कि आपको पहले फ़ील्ड पुनर्प्राप्त करना होगा।

इसमें धीमे कोड को रोकने का अतिरिक्त लाभ है जो लूप के for N अनुरोधों को निष्पादित करता है, जो कि कई नए Django प्रोग्रामर की एक सामान्य गलती है। यह प्रवेश अवरोध को बढ़ाता है, लेकिन याद रखें कि अतुल्यकालिक Django वैकल्पिक होगा - उपयोगकर्ता अभी भी तुल्यकालिक कोड लिख सकेंगे यदि वे चाहते हैं (और यह ट्यूटोरियल में प्रोत्साहित किया जाएगा, क्योंकि यह तुल्यकालिक कोड में गलतियाँ करना अधिक कठिन है)।

QuerySet , सौभाग्य से, अतुल्यकालिक जनरेटर को आसानी से लागू कर सकता है और पारदर्शी रूप से तुल्यकालन और अतुल्यकालिक दोनों का समर्थन कर सकता है:

 async def view(request): data = [] async for user in User.objects.all(): data.append(await extract_important_info(user)) return await render("template.html", data) 

अन्य

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

टेम्पलेट्स

टेम्प्लेट अब पूरी तरह से सिंक्रोनस हैं, और योजना उन्हें पहले चरण में इस तरह छोड़ने की है। , , DEP.

, Jinja2 , .

, Django , . Jinja2 , , , .

, render_async , render ; , , .

Django — _async - (, get_async , set_async ).

, API sync_to_async , BaseCache .

, thread-safety API , Django, , . , ORM, , .

, , , ModelForm ORM .

, - clean save , , . , , , DEP.

Email

Django, . send_mail_async send_mail , async - (, mail_admins ).

Django , - SMTP, . , , , , .

परीक्षण

, Django .

ASGI- asgiref.testing.ApplicationCommunicator . assert' .

Django , , . , — , , HTTP event loop, WSGI.

. , , .

, , . async def @async_to_sync , , , Django test runner.

asyncio ( loop' , ) , , , DEBUG=True . — , , .

WebSockets

Django; , Channels , ASGI, .

, Channels, , ASGI.

, , . , .

, . , — .

, , . , ORM, , , .

:

• ( 3.0)

  
  
  • HTTP, ( )
  • async ORM
  
  

• ( 3.1)

  
  
  • ORM ( )
  • ( )
  • ( )
  
  

• 
  
  • ORM ( )
  • ( )
  • Email
  
  

; , . , , , , .

, - ; , , . , , Django, Django async-only .

, , DEP , , , email . DBAPI — , core Python , , PEP, .

, , , . Django , - , -; .

, - . , — , , .

Python — . - Python , , .

Python asyncio , , . , , , , Django-size .

Django, «»; , , — , Django — .

, . , API , Django - .

, , Django . , Django ORM , , , -.

, , — . - long-poll server-sent events. Django , - .

Django; . , , , .

Django , . ; Django- , , , , , .

, -- Django .

, . « Django», ; , , .

, , , , API Django, , , Python 3, API, Django Python.

Python

Python . Python, , , .

, Django — - Python — , Python, Python . , , , .

, Django, . , Django , .

— , , , , .

, — , , — Django ( , Python ).

Django?

, Django. , Lawrence Journal-World — , , SPA — , , . , , , , .

, Django , - , — — . , , ; , Django , .

, Django . , . , , , — , , .

Django django-developers , , , , DEP.

, , , :

• : master- Django .
• : Django , , , , Django .
• : , , Django, , Django. , , , , .

Channels DEP ; Django , .

, , . DEP , , — Django .

. Django, , , WSGI , event loop , . 10% — , . , .

, , (- , Python ). , Django ; , , , Django master- .

, ( ORM, ..), ; Python.

, , Django, «» . , , , , .

विकल्प

, , , .

_async

, , (, django.core.cache.cache.get_async ), :

 from django.core.cache_async import cache cache.get("foo") 

, ; , , .

, , ; .

Django

- , ; , , , — .

, , , — , .

Channels

, Channels , «» Django. , - , , Django; ORM, HTTP/middleware flow .

asyncio

event loop' Python, asyncio , Django. await async Python event loop .

, asyncio , ; Django , , . Django ; , , async runtime, , .

Greenlets/Gevent

Gevent, , Python.

, . yield await , API, Django, , . , .

, , , . greenlet-safe Django ORM - new-connection-context, .

, . Django « » gevent, , , , .

DEP.

, — , — , ( ).

, , - . Django Fellows ; — , ( ), , , - .

— , Kickstarter migrations contrib.postgres , MOSS (Mozilla) Channels . , Django, , .

, . — Python, Django — — . , Django/async, .

HTTP/middleware/view flow, , , , « », .

, , , ( , Fellows, / , Channels, , ), , .

, , , , Django, .

, , , , API.

, , , , HTTP/middleware flow. , API, APM, .

, , Django , , . , ORM , , — , ORM .

DEP , ; Django .

, asgiref , , . Django Django.

Channels , Django, Django.

( ) CC0 1.0 Universal .