जिस दिन डोडो आईएस रुका। समकालिक लिपि

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

लेकिन अब हम बेहतर सोते हैं। हमने प्रणालीगत सर्वनाश परिदृश्यों को पहचानना और उन्हें संसाधित करना सीखा। नीचे मैं आपको बताऊंगा कि हम सिस्टम स्थिरता कैसे प्रदान करते हैं।

डोडो आईएस * प्रणाली के पतन के बारे में लेखों की एक श्रृंखला :
1. जिस दिन डोडो आईएस रुका। समकालिक लिपि।
2. जिस दिन डोडो आईएस रुका। अतुल्यकालिक स्क्रिप्ट।

* मास्को में डॉटनेक्स्ट 2018 में मेरे प्रदर्शन के आधार पर सामग्री लिखी गई ।

डोडो है

प्रणाली हमारे मताधिकार का एक बड़ा प्रतिस्पर्धी लाभ है, क्योंकि फ्रेंचाइजी को एक तैयार-निर्मित व्यवसाय मॉडल मिलता है। ये सभी एक में ERP, HRM और CRM हैं।

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

सिस्टम प्रदर्शन

सिस्टम प्रदर्शन डोडो आईएस = विश्वसनीयता = दोष सहिष्णुता / रिकवरी। आइए हम प्रत्येक बिंदु पर ध्यान दें।

विश्वसनीयता (विश्वसनीयता)

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

दोष सहिष्णुता

एक घटक दूसरे घटक पर निर्भर हो सकता है। यदि एक सिस्टम में कोई त्रुटि होती है, तो अन्य सबसिस्टम को गिरना नहीं चाहिए।

वसूली (लचीलापन)

व्यक्तिगत घटकों की विफलता हर दिन होती है। यह सामान्य है। यह महत्वपूर्ण है कि हम कितनी जल्दी असफलता से उबर सकते हैं।

सिंक्रोनस सिस्टम विफलता परिदृश्य

यह क्या है

एक बड़े व्यवसाय की वृत्ति एक ही समय में कई ग्राहकों की सेवा करना है। जिस तरह घर में रसोई में एक गृहिणी की तरह ही प्रसव के लिए काम करने वाली किचन पिज़्ज़ेरिया के लिए काम करना असंभव है, ठीक उसी तरह सिंक्रोनाइज़्ड एक्ज़ीक्यूशन के लिए बनाया गया कोड सर्वर पर मास कस्टमर सर्विस के लिए सफलतापूर्वक काम नहीं कर सकता।

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

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

कई आदेशों की सेवा के लिए हमें सही विकल्प की आवश्यकता है:



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

सरलीकृत, प्रीमेप्टिव मल्टीटास्किंग को निम्नानुसार चित्रित किया जा सकता है:



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

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

एक सिंथेटिक परीक्षण के परिणामों पर विचार करें:



यदि सिंक्रनाइज़ेशन के बीच प्रवाह अंतराल लगभग 1000 नैनोसेकंड है, तो दक्षता काफी कम है, भले ही थ्रेड्स की संख्या कोर की संख्या के बराबर हो। इस मामले में, दक्षता लगभग 25% है। यदि थ्रेड्स की संख्या 4 गुना अधिक है, तो दक्षता नाटकीय रूप से 0.5% तक गिर जाती है।

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

यदि कम कार्य हैं, लेकिन उनकी अवधि लंबी है, तो दक्षता बढ़ जाती है। हम देखते हैं कि प्रति सेकंड 5,000 ऑपरेशन पर, दोनों मामलों में दक्षता 80-90% है। मल्टीप्रोसेसर सिस्टम के लिए, यह बहुत अच्छा है।



हमारे वास्तविक अनुप्रयोगों में, सिंक्रोनाइज़ेशन के बीच एक ऑपरेशन की अवधि कहीं बीच में होती है, इसलिए समस्या अत्यावश्यक है।

क्या चल रहा है?

तनाव परीक्षण के परिणाम पर ध्यान दें। इस मामले में, यह तथाकथित "एक्सट्रूज़न परीक्षण था।"



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

दूसरे ग्राफ़ में, अनुरोध को संसाधित करने का समय बढ़ता है, इस अंतराल के दौरान कम अनुरोधों को परोसा जाता है। पहले आए अनुरोधों को बहुत बाद में परोसा जाता है।



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

समस्या खोजने के तरीके

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

प्रक्रिया में ताले

यहाँ एक अवरुद्ध आवेदन में एक विशिष्ट अनुरोध है।

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

आइए देखें कि यह कैसे तराजू है।

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

हम इस तरह से लड़ेंगे।

var fallback = FallbackPolicy<OptionalData> .Handle<OperationCancelledException>() .FallbackAsync<OptionalData>(OptionalData.Default); var optionalDataTask = fallback .ExecuteAsync(async () => await CalculateOptionalDataAsync()); //… var required = await CalculateRequiredData(); var optional = await optionalDataTask; var price = CalculatePriceAsync(optional, required); 

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

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

DB ताले

जब हम async पर फिर से लिखते हैं और संगति मॉडल को बदलते हैं तो हमें लगभग एक ही लेआउट मिलता है।

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


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

सिंक io

कभी-कभी हमें फ़ाइल लॉग की आवश्यकता होती है। आश्चर्यजनक रूप से, लॉगिंग सिस्टम ऐसी अप्रिय विफलताएं दे सकता है। Azure में डिस्क पर लेटेंसी - 5 मिलीसेकंड। यदि हम एक पंक्ति में एक फ़ाइल लिखते हैं, तो यह प्रति सेकंड केवल 200 अनुरोध है। यही है, अनुप्रयोग बंद हो गया है।


यह सिर्फ इतना है कि जब आप इसे देखते हैं तो आपके बाल खड़े हो जाते हैं - 2000 से अधिक थ्रेड्स एप्लिकेशन में प्रतिबंधित हो गए हैं। सभी थ्रेड्स का 78% समान कॉल स्टैक हैं। वे उसी जगह पर रुक गए और मॉनिटर में घुसने की कोशिश कर रहे थे। यह मॉनीटर उस फ़ाइल तक पहुँच को रद्द कर देता है जहाँ हम सभी लॉग करते हैं। बेशक, यह कटौती की जानी चाहिए।

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

सब कुछ बहुत बुरा है

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

मुझे async पर कॉल को अवरुद्ध करने से बहुत सारी विरासत को फिर से लिखना पड़ा, मैंने खुद अक्सर इस तरह के उन्नयन की शुरुआत की। बहुत बार, कोई व्यक्ति आता है और पूछता है: "सुनो, हम अब दो सप्ताह के लिए फिर से लिख रहे हैं, लगभग सभी async। और यह कितनी तेजी से काम करेगा? ” दोस्तों, मैं आपको परेशान करूँगा - यह तेजी से काम नहीं करेगा। यह और भी धीमा हो जाएगा। आखिरकार, टीपीएल एक अन्य के शीर्ष पर एक प्रतिस्पर्धी मॉडल है - प्रीमेप्टिव मल्टीटास्किंग पर सहकारी मल्टीटास्किंग, और यह ओवरहेड है। हमारी एक परियोजना में - जीपी पर सीपीयू के उपयोग और भार का लगभग + 5%।

एक और बुरी खबर है - प्रतिस्पर्धात्मक मॉडल की सुविधाओं को साकार किए बिना, केवल एसिंक्स पर पुनर्लेखन के बाद एप्लिकेशन बहुत खराब काम कर सकता है। मैं अगले लेख में इन विशेषताओं के बारे में बहुत विस्तार से बात करूंगा।

यह सवाल उठाता है - क्या फिर से लिखना आवश्यक है?

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

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