कैशिंग निर्देशिकाओं के कई चरण

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

पहला कदम

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

दूसरा कदम

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

तीसरा कदम

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

चौथा चरण

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

यह बहुत अच्छा होगा अगर हेब्रोसोसिटी अनुकूलन के लिए अगले चरणों का संकेत देती है।