अजगर async के लिए एक विकास लक्ष्य के रूप में अमृत

किताब में “पायथन। उत्कृष्टता की ऊंचाइयों तक ”लूसियानो रामालो एक कहानी का वर्णन करता है। 2000 में, लुसियानो ने पाठ्यक्रम लिया, और एक बार गुइडो वैन रोसुम ने दर्शकों को देखा। एक बार ऐसी घटना सामने आने के बाद, हर कोई उनसे सवाल पूछने लगा। जब पूछा गया कि पायथन ने अन्य भाषाओं से क्या कार्य लिया है, तो गुइडो ने उत्तर दिया: "पायथन में जो कुछ अच्छा है वह अन्य भाषाओं से चुराया गया है।"

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


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

अन्य भाषाओं के विकास के इतिहास को समझने और यह समझने के लिए कि प्रगति कहाँ प्रगति कर रही है, हमने मैक्सिम लाप्शिन ( एर्लीविडियो ) को आमंत्रित किया, जो Erlyvideo.ru परियोजना के लेखक, मॉस्को पायथन कन्फ़ेक्ट ++ को ।

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


Erlyvideo.ru में एक वीडियो निगरानी प्रणाली है जिसमें कैमरों के लिए पहुंच नियंत्रण पायथन में लिखा गया है। यह इस भाषा के लिए एक क्लासिक कार्य है। उपयोगकर्ता और कैमरे हैं, जिसमें से वे वीडियो देख सकते हैं: कोई कुछ कैमरे देखता है, जबकि अन्य एक नियमित साइट देखते हैं।

अजगर को इसलिए चुना गया क्योंकि उस पर इस तरह की सेवा लिखना सुविधाजनक है: सभी के बाद फ्रेमवर्क, ओआरएम, प्रोग्रामर हैं। विकसित सॉफ्टवेयर को पैक किया जाता है और उपयोगकर्ताओं को बेचा जाता है। Erlyvideo.ru एक कंपनी है जो सॉफ्टवेयर बेचती है, और न केवल सेवा प्रदान करती है।

पायथन के साथ मैं क्या समस्याओं को हल करना चाहता हूं।

मल्टीकोर के साथ ऐसी समस्याएं क्यों हैं? हमने इंटेल के किए जाने से पहले ही स्टैडिया कंप्यूटरों पर फ्लॉसोनिक चलाया। लेकिन पाइथन को इससे दिक्कतें हैं: यह अभी भी हमारे सर्वर के सभी 80 कोर का उपयोग क्यों नहीं कर रहा है?

खुले सॉकेट से पीड़ित कैसे नहीं? खुले सॉकेट की संख्या की निगरानी एक बड़ी समस्या है। जब यह सीमा तक पहुँच जाता है, तो लीक को भी बंद और रोकें।

क्या वैश्विक चर का कोई समाधान है? जावा या C # जैसी किसी भी कचरा संग्रह भाषा के लिए लीकिंग ग्लोबल वैरिएबल नरक है।

संसाधनों को बर्बाद किए बिना लोहे का उपयोग कैसे करें? यदि हम कुशलता से सर्वर का उपयोग करना चाहते हैं और अनावश्यक हार्डवेयर पर सैकड़ों हजारों डॉलर नहीं फेंकते हैं, तो 40 जंग श्रमिकों और 64 जीबी रैम के बिना कैसे प्राप्त करें?

मल्टीकोर की आवश्यकता क्यों है

सभी कोर का पूरी तरह से उपयोग करने के लिए, कोर की तुलना में बहुत अधिक श्रमिकों की आवश्यकता होती है। उदाहरण के लिए, 40 प्रोसेसर कोर के लिए, 100 श्रमिकों की आवश्यकता होती है: एक कार्यकर्ता डेटाबेस में गया, दूसरा कुछ और के साथ व्यस्त है।

एक कार्यकर्ता 300-400 एमबी का उपभोग कर सकता है । हम अभी भी पायथन में इसे लिख रहे हैं, और रूबी ऑन रेल्स में नहीं, जो कई गुना अधिक उपभोग कर सकते हैं और 40 जीबी रैम आसानी से और आसानी से बेकार हो जाएंगे। यह बहुत महंगा नहीं है, लेकिन ऐसी मेमोरी क्यों खरीदें जहां आप खरीद नहीं सकते।

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

सॉकेट प्रबंधन

वेब सॉकेट पर, हम बैकएंड से कैमरों के रनटाइम डेटा को प्रदूषित करते हैं। पायथन सॉफ्टवेयर फ़्लुसोनिक से जुड़ता है और कैमरों के स्टेटस डेटा को प्रदूषित करता है: वे काम करते हैं या नहीं, क्या कोई नई घटना है।

दूसरी ओर, क्लाइंट कनेक्ट होता है, और वेब सॉकेट के माध्यम से हम इस डेटा को ब्राउज़र में भेजते हैं। हम ग्राहक डेटा को वास्तविक समय में स्थानांतरित करना चाहते हैं: कैमरा चालू और बंद हो गया, बिल्ली खा गई, सो गई, एक सोफे को फाड़ दिया, बटन दबाया और बिल्ली को दूर कर दिया।

लेकिन, उदाहरण के लिए, किसी तरह की समस्या हुई: डेटाबेस ने अनुरोध का जवाब नहीं दिया, सभी कोड गिर गए, दो खुले सॉकेट थे। हमने पुनः लोड करना शुरू किया, कुछ किया, फिर से यह समस्या - दो कुर्सियां ​​थीं। DB त्रुटि को गलत तरीके से संसाधित किया गया था और दो खुले कनेक्शन लटका दिए गए थे। समय के साथ, यह सॉकेट लीक की ओर जाता है।

भूल गए वैश्विक चर

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

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

हम हमेशा गलतियाँ करते हैं - हम लोग हैं और हम हर चीज पर नज़र नहीं रख सकते हैं।

सवाल यह है कि कुछ त्रुटियां होती हैं, यहां तक ​​कि वे भी जिन्हें हमें देखने की उम्मीद नहीं थी।

ऐतिहासिक भ्रमण

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

डॉस

सबसे पहले, डॉस की ओर मुड़ें, यह निकटतम है। उससे पहले पूरी तरह से अलग चीजें थीं और हर कोई जीवित नहीं है जो डॉस से पहले कंप्यूटर को याद करता है।

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

सहकारी मल्टीटास्किंग

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

डेटा को प्रक्रियाओं द्वारा अलग किया जाता है, और प्रत्येक प्रक्रिया को अलग-अलग किया जाता है: वे किसी तरह एक दूसरे से सुरक्षित होते हैं। एक प्रक्रिया में खराब कोड ब्राउज़र में कोड को खराब नहीं कर पाएगा (फिर पहले ब्राउज़र पहले दिखाई दिए थे)।

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

प्रीमेप्टिव मल्टीटास्किंग

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

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

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

धाराओं

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

थ्रेड्स हल्के प्रक्रियाएं हैं जो एक आम मेमोरी साझा करती हैं।

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

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

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

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

पायथन उदाहरण

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

यह पुराने Django, पायथन 2 में कोड है। आज यह बहुत लोकप्रिय नहीं है, कुछ लोग इस पर प्रोजेक्ट शुरू करते हैं।

@api_view(['GET']) def best_price(request): name = request.GET['name'] price1 = http_fetch_price('market.yandex.ru', name) price2 = http_fetch_price('ebay.com', name) price3 = http_fetch_price('taobao.com', name) return Response(min([price1,price2,price3])) 

एक अनुरोध आता है, हम एक बैकएंड पर जाते हैं, फिर दूसरे में। उन स्थानों पर जहां http_fetch_price , थ्रेड्स अवरुद्ध हैं। इस समय, पूरे कार्यकर्ता Yandex.Market की यात्रा पर निकलते हैं, फिर eBay पर, फिर Taobao पर एक टाइमआउट तक, और अंत में एक उत्तर देते हैं। इस समय पूरा कार्यकर्ता खड़ा है ।

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

हम पायथन में क्या देखते हैं? प्रति कार्य एक प्रक्रिया, पायथन में अभी भी कोई मल्टीकोर नहीं है। स्थिति स्पष्ट है: इस वर्ग की भाषाओं में एक सुरक्षित सरल मल्टीकोर बनाना मुश्किल है, क्योंकि यह प्रदर्शन को मार देगा ।

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

हमारे पास निष्पादन का केवल एक धागा है और केवल प्रक्रियाएं ही पैमाने पर हो सकती हैं । वास्तव में, हमने प्रक्रिया के अंदर डीओएस का आविष्कार किया - 2010 की स्क्रिप्टिंग भाषा। प्रक्रिया के अंदर एक ऐसी चीज है जो डॉस से मिलती जुलती है: जब हम कुछ कर रहे होते हैं, तो अन्य सभी प्रक्रियाएं काम नहीं करती हैं। किसी को भी भारी लागत और धीमी प्रतिक्रिया पसंद नहीं आई।

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

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

रिएक्टर का विचार यह है कि हम घटना-उन्मुख प्रोग्रामिंग पर चले गए।

इवेंट ओरिएंटेड प्रोग्रामिंग

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

मुड़

यह एक इवेंट-संचालित नेटवर्क फ्रेमवर्क है। यह 2002 में दिखाई दिया और इसे पायथन में लिखा गया है। मैंने ऊपर का उदाहरण लिया और इसे ट्विस्टेड पर लिखा।

 def render_GET(self, request): price1 = deferred_fetch_price('market.yandex.ru', name) price2 = deferred_fetch_price('ebay.com', name) price3 = deferred_fetch_price('taobao.com', name) dl = defer.DeferredList([price1,price2,price3]) def reply(prices): request.write('%d'.format(min(prices))) request.finish() dl.addCallback(reply) return server.NOT_DONE_YET 

त्रुटियां, त्रुटियां हो सकती हैं, और कुख्यात त्रुटि से निपटने के लिए पर्याप्त नहीं है। लेकिन अनुमानित योजना यह है: हम एक अनुरोध नहीं करते हैं, लेकिन कुछ समय बाद, इस अनुरोध के लिए जाने के लिए कहें। defer.DeferredList साथ लाइन में हम कई प्रश्नों की प्रतिक्रियाओं को एक साथ इकट्ठा करना चाहते हैं।

वास्तव में, कोड में दो भाग होते हैं। पहले भाग में, अनुरोध से पहले क्या हुआ और दूसरे में, उसके बाद क्या था।

घटना-उन्मुख प्रोग्रामिंग का पूरा इतिहास "अनुरोध के पहले" और "अनुरोध के बाद" पर रैखिक कोड को तोड़ने के दर्द से संतृप्त है।

यह दर्द होता है क्योंकि कोड के टुकड़े मिश्रित होते हैं: अंतिम लाइनें अभी भी मूल अनुरोध में निष्पादित होती हैं, और reply फ़ंक्शन को बाद में बुलाया जाएगा।

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

आइडिया घुमा दिया

सॉकेट तैयार होने पर ऑब्जेक्ट को सक्रिय किया जा सकता है।

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

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

यह सब एक क्लासिक कॉलबैक नरक की ओर जाता है। किस लिए, उदाहरण के लिए, वे Node.js से प्यार करते हैं - हाल ही में जब तक, कोई अन्य विधियां नहीं थीं, लेकिन यह अभी भी पायथन में दिखाई दिया। परेशानी यह है कि बाहरी आईओ के बिंदुओं पर कोड ब्रेक होते हैं जो कॉलबैक की ओर ले जाते हैं।

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

Async io

इन सवालों का एक अच्छा जवाब Async IO है। यह एक आसान कदम है, हालांकि यह आसान नहीं है। Async IO एक जटिल चीज़ है, जिसके हुड के नीचे कई दर्दनाक बारीकियाँ हैं।

 async def best_price(request): name = request.GET['name'] price1 = async_http_fetch_price('market.yandex.ru', name) price2 = async_http_fetch_price('ebay.com', name) price3 = async_http_fetch_price('taobao.com', name) prices = await asyncio.wait([price1,price2,price3]) return min(prices) 

कोड अंतर सिंटैक्स async/await तहत छिपा हुआ है। हमने वह सब कुछ लिया जो पहले था, लेकिन इस कोड में नेटवर्क पर नहीं गया। हमने Callback(reply) हटा दिया, जो पिछले उदाहरण में था, और इसे await पीछे छिपा दिया - वह स्थान जहां कोड को कैंची से काटा जाएगा। इसे दो भागों में विभाजित किया जाएगा: कॉलिंग भाग और कॉलबैक भाग, जो परिणामों को संसाधित करता है।

यह एक बेहतरीन सिन्थेटिक शुगर है । एक में कई उम्मीदों को नज़र अंदाज़ करने के तरीके हैं। यह शांत है, लेकिन एक अति सूक्ष्म अंतर है: सब कुछ "क्लासिक" सॉकेट द्वारा तोड़ा जा सकता है । पायथन में, अभी भी बड़ी संख्या में पुस्तकालय हैं जो सॉकेट में समान रूप से जाते हैं, एक timer library बनाते हैं और आपके लिए सब कुछ बर्बाद कर देते हैं। यह कैसे डीबग करें, मुझे नहीं पता।

लेकिन asyncio लीक और मल्टीकोर के साथ मदद नहीं करता है । इसलिए, कोई मौलिक परिवर्तन नहीं हैं, हालांकि यह बेहतर हो गया है।

हमारे पास अभी भी सभी समस्याएं हैं जिनके बारे में हमने शुरुआत में बात की थी:

• सॉकेट्स के साथ रिसाव करना आसान;
• वैश्विक चर में लिंक छोड़ने के लिए आसान;
• बहुत श्रमसाध्य त्रुटि से निपटने;
• मल्टी-कोर करना अभी भी कठिन है।

क्या करें?

क्या यह सब विकसित होगा, मुझे नहीं पता, लेकिन मैं अन्य भाषाओं और प्लेटफार्मों में कार्यान्वयन दिखाऊंगा।

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

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

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

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

प्रक्रिया और संदर्भ के भीतर सभी संसाधन निष्पादन का एक धागा बन जाते हैं । हम एक साथ चिपके हुए हैं:

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

बधाई - हमने एक प्रोग्रामिंग भाषा के अंदर UNIX का आविष्कार किया! इस विचार का आविष्कार 1969 के आसपास हुआ था। अब तक, यह पायथन में नहीं है, लेकिन पायथन के इसके आने की संभावना है। और शायद वह नहीं आई - मुझे नहीं पता।

यह क्या देता है

सबसे पहले, संसाधनों पर स्वत: नियंत्रण । मॉस्को पायथन कॉन्फ + ++ 2019 में उन्होंने कहा कि आप गो पर एक कार्यक्रम लिख सकते हैं और सभी त्रुटियों को संसाधित कर सकते हैं। कार्यक्रम एक दस्ताने की तरह खड़ा होगा और महीनों तक काम करेगा। यह सच है, लेकिन हम सभी त्रुटियों को नहीं संभालते हैं।

हम जीवित लोग हैं, हमारे पास हमेशा समय सीमा है, कुछ उपयोगी करने की इच्छा है, और आज के लिए 535 वीं त्रुटि को संभालना नहीं है। कोड जो त्रुटि से निपटने के साथ बिखरा हुआ है, कभी किसी में गर्म भावनाओं का कारण नहीं बनता है।

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

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

आप एक अलग संदर्भ में भारी कंप्यूटिंग ले सकते हैं , लेकिन यह पहले से ही दूसरे कोर में जा सकता है। हमने डेटा साझा किया, हमें म्यूटेक्स की आवश्यकता नहीं है। आप एक अलग संदर्भ में डेटा भेज सकते हैं, कह सकते हैं: "आप इसे कहीं और करेंगे, और फिर मुझे बताएंगे कि आपने काम पूरा कर लिया है और कुछ किया है।"

"Async / प्रतीक्षा" शब्दों के बिना एक एसिंसीओ कार्यान्वयन । वर्चुअल मशीन से रनटाइम से थोड़ी मदद। यह हमने async/await बारे में बात की है: आप संदेशों को रूपांतरित भी कर सकते हैं, async/await हटा सकते हैं async/await और इसे वर्चुअल मशीन स्तर पर प्राप्त कर सकते हैं।

एरलंग प्रक्रियाएँ

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

हमें एर्लांग (अमृत) मिला - सक्रिय संदर्भ जो खुद को निष्पादित करते हैं । इसके अलावा Erlang पर मेरा उदाहरण। अमृत ​​पर, यह उसी के बारे में दिखता है, कुछ बदलावों के साथ।

 best_price(Name) -> Price1 = spawn_price_fetcher('market.yandex.ru', Name), Price2 = spawn_price_fetcher('ebay.com', Name), Price3 = spawn_price_fetcher('taobao.com', Name), lists:min(wait4([Price1,Price2,Price3])). 

हम कई सारे भ्रूण लाते हैं - ये कई अलग-अलग नए संदर्भ हैं जिनका हम इंतजार कर रहे हैं। उन्होंने इंतजार किया, डेटा एकत्र किया और न्यूनतम मूल्य के रूप में परिणाम लौटाया। यह सब async/await समान है, लेकिन "async / इंतजार" शब्दों के बिना।

अमृत ​​की विशेषताएं

एलिक्जिर एरलैंग के बेस पर स्थित है, और सभी भाषा अवधारणाएं चुपचाप एलिक्सिर में रखी गई हैं। इसकी विशेषताएं क्या हैं?

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

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

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

यदि हम संकलन के लिए ढेर के अंदर डेटा को किसी अन्य स्थान पर स्थानांतरित करते हैं, तो हमें पूरे सिस्टम से गुजरना होगा। यह गीगाबाइट के दसियों पर कब्जा कर सकता है और सभी बिंदुओं को अपडेट कर सकता है - यह पागल है।

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

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

विधि कॉल। हमारे पास ऐसी वस्तुएँ हैं जिन्हें हम प्रक्रिया कहते हैं। संदेशों पर प्रक्रियाओं के तरीकों को कहा जाता है।

कॉल करने के तरीके भी एक संदेश भेज रहा है। यह बहुत अच्छा है कि अब इसे टाइमआउट के साथ किया जा सकता है। यदि कोई चीज हमें धीरे-धीरे जवाब देती है, तो हम किसी अन्य ऑब्जेक्ट पर विधि कहते हैं। लेकिन एक ही समय में हम कहते हैं कि हम 60 एस से अधिक प्रतीक्षा करने के लिए तैयार हैं, क्योंकि मेरे पास 70 एस के टाइमआउट के साथ एक ग्राहक है। मुझे उसे "503" बताने और बताने की आवश्यकता होगी - कल आओ, अब वे तुम्हारा इंतजार नहीं कर रहे हैं।

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

नेटवर्क के साथ कैसे काम करें?

आप रैखिक कोड, कॉलबैक या asyncio.gather की शैली में asyncio.gather । यह कैसा दिखेगा इसका एक उदाहरण।

 wait4([ ]) -> [ ]; wait4(List) -> receive {reply, Pid, Price} -> [Price] ++ wait4(List -- [Pid]) after 60000 -> [] end. 

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

कोई कह सकता है, "सोचिए, libcurl में भी यही बात है।" लेकिन यहां यह महत्वपूर्ण है कि दूसरी तरफ न केवल एक HTTP यात्रा हो सकती है, बल्कि एक डीबी ट्रिप भी हो सकती है, साथ ही कुछ गणनाएं भी हो सकती हैं, उदाहरण के लिए, क्लाइंट के लिए किसी प्रकार की इष्टतम संख्या की गणना करना।

हैंडलिंग में त्रुटि

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

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

उत्पादन में आत्मनिरीक्षण या डिबगिंग

ठेस और बहस में जाने से बेहतर क्या हो सकता है, खासकर अगर त्रुटि केवल पीक आवर्स के दौरान लोड के तहत होती है। जल्दी घंटे में हम कहते हैं:

- चलो, मैं अब पुनः आरंभ करता हूँ!
- दरवाजा बाहर जाओ और किसी और पर फिर से शुरू है!

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

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

बोनस

कोड सुपर विश्वसनीय है। उदाहरण के लिए, पायथन में old vs async साथ नाजुकता है, और यह पांच साल तक रहेगा, कम नहीं। जिस गति के साथ पायथन 3 को लागू किया गया था, उसे देखते हुए, आपको यह उम्मीद नहीं करनी चाहिए कि यह तेजी से होगा।

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

एक लाइव उत्पादन प्रणाली के अंदर भव्य मल्टी-कोर , स्मृति प्रबंधन और आत्मनिरीक्षण ।

समस्याओं

स्वाभाविक रूप से, एरलांग में भी समस्याएं हैं।

इस तथ्य के कारण अधिकतम प्रदर्शन का नुकसान कि अब हम किसी अन्य प्रक्रिया या ऑब्जेक्ट में डेटा का उल्लेख नहीं कर सकते हैं। हमें उन्हें स्थानांतरित करना होगा, लेकिन यह स्वतंत्र नहीं है।

प्रक्रियाओं के बीच डेटा की प्रतिलिपि बनाने का ओवरहेड। हम C में एक प्रोग्राम लिख सकते हैं जो सभी 80 कोर पर चलेगा और एक डेटा ऐरे को प्रोसेस करेगा, और हम मान लेंगे कि यह इसे सही और सही तरीके से करता है। एर्लैंग में, आप ऐसा नहीं कर सकते हैं: आपको डेटा को सावधानीपूर्वक काटने की जरूरत है, इसे प्रक्रियाओं के एक समूह में वितरित करें, हर चीज का ट्रैक रखें। इस संचार में संसाधनों का खर्च होता है - प्रोसेसर चक्र।

यह कितना तेज या धीमा है? हम 10 साल से Erlang कोड लिख रहे हैं। इन 10 वर्षों में जीवित रहने वाला एकमात्र प्रतियोगी जावा में लिखा गया है। उसके साथ, हमारे पास लगभग पूर्ण प्रदर्शन समता है: कोई कहता है कि हम बदतर हैं, कोई है जो वे हैं। लेकिन उनके पास अपनी सभी परेशानियों के साथ जावा है, जो कि JIT से शुरू होती है।

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

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

संदेश आवंटन का ओवरहेड। कभी-कभी दर्द होता है। उदाहरण के लिए, हमारे पास कोड में C के कुछ टुकड़े हैं, और इन स्थानों पर यह Erlang के साथ बिल्कुल काम नहीं करता है। , , .

Erlang , , . , , receive send receive . — , . , , .

Python

. . , Python - .

, . - Python, , 20 , 40.

, . - , , Elixir, , .

Moscow Python Conf++ . , 6 4 . , , ) ) . Call for Papers 13 , 27 .