HighLoad WEB सेवाओं की सरल समस्याओं का एक जटिल समाधान

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

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

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

तो क्या हासिल करने की योजना है:

1. बैकएंड अनुरोधों को अनुकूलित करें (उनकी संख्या कम करें);
2. अंतिम उपयोगकर्ता के लिए सामग्री वितरण की गति बढ़ाएँ;
3. यातायात का अनुकूलन करें।

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

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

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

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

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

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

moment: int32 //   min: float64 //   max: float64 //   open: float64 //   close: float64 //   volume: float64 //  average: float64 //   

इस प्रकार, हमारी संरचना 52 बाइट्स पर कब्जा कर लेगी। हम इसे क्वांटम के रूप में लेते हैं - न्यूनतम बाइनरी ब्लॉक।

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

Range: 5200-52000

हमें अपने क्वांटम के आयाम की व्याख्या इस प्रकार करनी चाहिए:

Range: 100-1000

संक्षेप में, यह हमारे डेटाबेस क्वेरी की ऑफसेट और सीमा होगी।

एक्सपोज़र की परिभाषा बहुत सरल है, हम इसे यूआरएल में रख सकते हैं। उदाहरण के लिए:

/api/v1/candles/7m

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

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

सामान्य तौर पर, यह क्लासिक पेजिनेशन समस्या की बहुत याद दिलाता है।

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

Content-Range: [ ] / [[ ] * [ ]]

बंद करो। लेकिन सामने वाला वांछित समय अंतराल और बाइट अंतराल में भी अनुरोध करने में सक्षम कैसे हो सकता है? वह किसी भी मोमबत्ती संख्या को कैसे जानता है? यहाँ भी, सब कुछ का आविष्कार किया गया था। रेंज सापेक्ष ऑफसेट का समर्थन करती है, उदा।

Range: -52

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

यदि आप अचानक एक सवाल पूछना चाहते थे - ऐसी कठिनाइयाँ क्यों? कृपया अपने लक्ष्यों की ओर लौटें। यह तकनीक सीडीएन और ब्राउज़र के लिए द्विआधारी फ़ाइलों में डेटाबेस के लिए विश्लेषणात्मक प्रश्नों को "नकाबपोश" करती है। यह आपको CDN और अंतिम क्लाइंट के लिए बार-बार अनुरोधों को स्थानांतरित करने की अनुमति देता है।

शायद एक और सवाल उठता है - जीईटी अनुरोधों के सरल कैशिंग का उपयोग क्यों नहीं किया जाता है? सब ठीक है। चलो ठीक है। यदि हम क्लासिक रिस्ट में इस तरह के अनुरोध को निष्पादित करते हैं:

GET /api/v1/candles/7m?from=01-03-2018&to=31-03-2018

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

GET /api/v1/candles/7m?from=15-03-2018&to=20-03-2018

हमें एक और अनोखा कैश मिलेगा ...। हालाँकि, ध्यान दें, दूसरा अनुरोध पहले की प्रतिक्रिया में शामिल डेटा का अनुरोध करता है।

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

क्या इस तकनीक में कोई कमी है? हां। वे स्पष्ट हैं:

1. यह तकनीक समय के साथ बदलते आंकड़ों के लिए उपयुक्त नहीं है कुल कैशिंग पर आधारित है।
2. CDN CloudFlare केवल पूरी तरह से फाइल कैश करता है। इसका मतलब यह है कि यदि अंतिम क्लाइंट 1 से 100 बाइट्स के अंतराल का अनुरोध करता है, तो CloudFlare वास्तव में सर्वर से पूरी फाइल का अनुरोध करेगा। यानी हमारे मामले में, यह एक निश्चित जोखिम के साथ सभी मोमबत्तियों को लोड करेगा। वह इसे अपने दम पर रख देगा और पहले से ही इसे स्वयं वितरित करेगा। यह भी एक प्लस माना जा सकता है, अगर जगह पर प्रतिबंध के लिए नहीं। और अगर आप "भारी" उत्तर, और बहुत सारे पैरामीटर बना सकते हैं, तो ... सामान्य तौर पर, यह स्पष्ट है कि जगह समाप्त हो जाएगी। शायद हम इसे सही ढंग से कॉन्फ़िगर करने में सक्षम नहीं थे। लेकिन अभी तक परिणाम इस प्रकार है।
3. बुद्धिमानी से कैश का प्रबंधन करना आवश्यक है। इसके लिए पर्याप्त तंत्र हैं, लेकिन उन्हें ट्यूनिंग की आवश्यकता होती है।
4. सीमावर्ती बाइनरी डेटा को पार्स करने में सक्षम होना चाहिए और सीमा अनुरोधों के साथ काम करने के लिए बोर्ड पर कुछ ala डाटासेट हैं।

मैं इस रणनीति को इस प्रकार लागू करने की व्यवहार्यता तैयार करूंगा - जब आपको इसकी आवश्यकता होगी, तो आप समझ जाएंगे। यदि अब संदेह है, तो उसके बारे में जानना उपयोगी है, लेकिन परेशान न करें।