त्वरण instagram.com। भाग 3

आज हम एक्सेलेरेशन instagram.com के बारे में सामग्री की एक श्रृंखला के तीसरे भाग का अनुवाद प्रकाशित करते हैं। पहले भाग में, हमने डेटा को प्रीलोड करने के बारे में बात की, दूसरे में , सर्वर की पहल पर क्लाइंट को डेटा भेजने के बारे में। यह कैशिंग के बारे में है।

कैश से काम शुरू होता है

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

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

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


रेस स्टेट जो तब होता है जब कोई उपयोगकर्ता कैश्ड डेटा के साथ इंटरैक्ट करता है (Redux कार्यों को हरे रंग में हाइलाइट किया जाता है, स्थिति ग्रे है)

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

यह विचार हमें निम्नलिखित सिस्टम आर्किटेक्चर की ओर ले जाता है:

• जब पृष्ठ लोड होता है, तो हम सर्वर को नया डेटा डाउनलोड करने के लिए अनुरोध भेजते हैं (या सर्वर की पहल पर इसे भेजे जाने की प्रतीक्षा करते हैं)।
• Redux राज्य का एक मध्यवर्ती (मंचन) सबसेट बनाएं।
• सर्वर से डेटा की प्रतीक्षा करने की प्रक्रिया में, हम सबमिट किए गए कार्यों को सहेजते हैं।
• सर्वर से डेटा प्राप्त करने के बाद, हम नए डेटा के साथ कार्य करते हैं और नए डेटा पर संग्रहीत कार्यों को वापस करते हैं, उन्हें मध्यवर्ती स्थिति पर लागू करते हैं।
• उसके बाद, हम बदलाव करते हैं और वर्तमान स्थिति को एक मध्यवर्ती के साथ बदलते हैं।

एक मध्यवर्ती स्थिति का उपयोग करते हुए एक दौड़ की स्थिति के कारण समस्या का समाधान (Redux कार्यों को हरे रंग में हाइलाइट किया गया है, स्थिति ग्रे है)

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

एपीआई

मध्यवर्ती राज्य एपीआई में दो मुख्य कार्य होते हैं। यह stagingAction और stagingCommit :

 function stagingAction(    key: string,    promise: Promise<Action>, ): AsyncAction<State, Action> function stagingCommit(key: string): AsyncAction<State, Action> 

उदाहरण के लिए, परिवर्तन रद्द करने और सीमा मामलों को संभालने के लिए, वहाँ कई अन्य कार्य हैं, लेकिन हम उन्हें यहां नहीं मानेंगे।

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

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

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

 function fetchAndStageFeed() {    return stagingAction(        'feed',        (async () => {            const {data} = await fetchFeedTimeline();            return {                type: FEED_LOADED,                ...data,            };        })(),    ); } //          store.dispatch(fetchAndStageFeed()); //   ,    stagingCommit, //      'feed' //      store.dispatch(stagingCommit('feed')); 

फ़ीड और कहानियों के लिए एक प्रतिपादन दृष्टिकोण का उपयोग, जिसमें कैश सामने आता है, ने क्रमशः सामग्री के उत्पादन में 2.5% और 11% की तेजी ला दी है। इसके अलावा, इस तथ्य में योगदान दिया कि, उपयोगकर्ताओं की धारणा में, सिस्टम का वेब संस्करण आईओएस और एंड्रॉइड के लिए Instagram क्लाइंट के करीब आया।

प्रिय पाठकों! क्या आप अपनी परियोजनाओं पर काम करते समय कैशिंग का अनुकूलन करने के लिए किसी भी दृष्टिकोण का उपयोग करते हैं?