उच्च भार पर विश्वसनीय कोड

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

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

"उच्च भार" - यह क्या है?

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

PHP-FPM के लिए 40,000 से अधिक प्रति सेकंड अनुरोध वेबसाइट पर आते हैं, इसलिए हमारे लिए उच्च भार से संबंधित मुद्दे प्रासंगिक से अधिक हैं।

उच्च भार = उच्च विश्वसनीयता?

कल्पना करें कि हमारे पास प्रतिदिन 10,000 हिट्स के साथ एक "नियमित साइट" है। यदि ऐसी साइट के कोड में कोई त्रुटि है जो 0.05% अनुरोधों को प्रभावित करती है, तो यह दिन में 5 बार दिखाई देगा। सबसे अधिक संभावना है, एरर में 5 प्रविष्टियां। प्रति दिन बस छोड़ दी जाएगी और ध्यान नहीं दिया जाएगा।

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

"बुलेटप्रूफ" कोड लिखना

त्रुटियों की रिपोर्ट करना महत्वपूर्ण है

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

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

किसी भी ऑपरेशन के परिणाम की जांच करें

जावा जैसी भाषाएं हैं जिनमें किसी भी त्रुटि से निपटने को अपवाद के रूप में किया जाता है, इसलिए गलती से चूकना बेहद मुश्किल है। PHP भाषा में "डिज़ाइन द्वारा" कोई अपवाद नहीं थे, इसलिए मानक PHP फ़ंक्शन केवल एक त्रुटि के मामले में झूठे होते हैं। जैसा कि हो सकता है कि किसी भी कोड में त्रुटियां गंभीर हों, आपको सभी आदेशों के परिणाम की जांच करने की आवश्यकता है। सब के बाद, यहां तक ​​कि fclose या SQL COMMIT क्वेरी एक त्रुटि लौटा सकती है।

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

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

डेटा चेकसम की जांच करें

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

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

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

अंतिम स्थिरता मॉडल में डेटा रिकॉर्डिंग की विश्वसनीयता

यदि डेटाबेस प्रतिकृति मौजूद है, तो अक्सर तथाकथित "मजबूत स्थिरता" की आवश्यकता नहीं होती है जब सभी सर्वरों में बिल्कुल समान डेटा होता है। यदि आप खुश हैं कि विभिन्न सर्वरों में अलग-अलग डिग्री की ताजगी हो सकती है, तो ऐसे मामलों में विश्वसनीय कोड लिखना बहुत सरल है। आपको बस यह सुनिश्चित करने की आवश्यकता है कि आपने एन सर्वर को डेटा लिखा है, जिसके बाद कतार में पहुंचते ही अन्य सर्वर पर डेटा अपडेट हो जाएगा।

सबसे सरल मामले में, अंतिम स्थिरता में विश्वसनीय डेटा संग्रहण, प्रतिकृति कतार में प्राथमिक विश्वसनीय डेटा संग्रहण (उदाहरण के लिए, लेन-देन में) जैसा दिखता है। उसके बाद, अन्य स्क्रिप्ट इस डेटा को पढ़ने और इसे सफल होने तक अन्य सर्वर पर डालने के लिए असीमित संख्या में प्रयास कर सकते हैं।

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

"मृत्यु को याद रखो"

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

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

एक शब्द में, मृत्यु को याद रखें जब आप कोड लिखते हैं जो उच्च भार के तहत काम करेगा।

ये दिशानिर्देश क्यों काम करते हैं?

हमने उन अप्रिय परिणामों के बारे में बात की है जो ऊपर वर्णित युक्तियों का पालन नहीं करने पर हो सकते हैं। हमारी सिफारिशें सामान्य रूप से आसान डिबगिंग और विश्वसनीय कोड लिखने में कैसे मदद करती हैं?

आइए अंक देखते हैं।

त्रुटि संदेश

यहां सब कुछ स्पष्ट है: जैसे ही कोड में कोई त्रुटि होती है, आपको इसके बारे में बहुत जल्दी पता चल जाएगा और आप इसे ठीक कर सकते हैं - सभी त्रुटि संदेश प्रदर्शित होते हैं और लॉग में संग्रहीत होते हैं!

संचालन के परिणामों की जाँच करना

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

चेकसम सत्यापन

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

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

डेटा जांच पंक्तियों की संख्या की गिनती तक सीमित नहीं हो सकती है। उदाहरण के लिए, हमारी स्क्रिप्ट में जो कॉल करने से पहले मशीनों को लक्षित करने के लिए कोड तैनात करते हैं

system("rm -rf " . escapeshellarg($dir))

$ dir की लंबाई के लिए जाँच की जाती है। यदि रास्ता बहुत छोटा है, तो इसका मतलब है कि एक त्रुटि सामने आ गई है और किसी भी स्थिति में आप इसे हटा नहीं सकते हैं।

कुल मिलाकर

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

हमारी सिफारिशों को याद रखें, अत्यधिक लोड किए गए सिस्टम लिखते समय उनका पालन करें, और आपके बाल नरम और रेशमी होंगे :)।

छवि स्रोत: vbgcity.ru/sites/default/files/krepost-oreshek.jpg

यूरी नसरदीनोव, Badoo डेवलपर