गो सेवा के लिए रेडिस कैश सिंक

परिचय

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

सब कुछ कैसा था?

प्रारंभ में, अनुरोधित वस्तु के पहचानकर्ता वाले प्रत्येक प्रश्न के लिए, PostgreSQL डेटाबेस (DB) में एक क्वेरी निष्पादित की गई थी। अधिक सटीक रूप से, कई प्रश्न, क्योंकि एक पूर्ण उत्तर बनाने के लिए, कई डेटाबेस तालिकाओं पर लागू होना आवश्यक था। प्रसंस्करण अनुरोधों के परिणामस्वरूप, एक जटिल परिसर का गठन किया गया था, जिनमें से कुछ क्षेत्रों को इंटरफेस द्वारा दर्शाया गया है। स्मृति में, यह वस्तु लगभग 250 kB होती है।

इस कार्यान्वयन के साथ प्रदर्शन महान नहीं था, 1000 प्रतिस्पर्धा वाले थ्रेड्स के साथ समान डेटा का अनुरोध करते समय 3500 आरपीएस (प्रति सेकंड अनुरोध) से अधिक नहीं।

प्रश्न तुरंत उठा, लेकिन आरपीएस कैसे बढ़ाया जाए: राउटर को बदलें, डेटाबेस, कैश डेटा का अनुकूलन करें? राउटर का उपयोग काफी अच्छी तरह से किया गया था ( github.com/julienschmidt/httprouter ), और राउटर को एक बड़े प्रोजेक्ट में बदलने के लिए बहुत समय की आवश्यकता होगी और इसके टूटने का एक उच्च जोखिम है। डेटाबेस के साथ काम का अनुकूलन करने के लिए, आपको कोड का एक बड़ा हिस्सा फिर से लिखना होगा (अब github.com/jmoiron/sqlx का उपयोग किया जाता है)। जाहिर है, आरपीएस बढ़ाने के लिए कैशिंग सबसे इष्टतम तरीका है।

सरल उपाय

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

इन-मेमोरी कैश के साथ प्राप्त प्रदर्शन को समाधान के लिए आगे की खोज में एक मानक के रूप में लिया गया था।

विचार, बुरा विचार

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

हाइब्रिड "सांप और हाथी"

आप इसे पूर्ण विकसित हाइब्रिड नहीं कह सकते (देखें। अंजीर।), वास्तव में, यह एक इन-मेमोरी कैश निकला, लेकिन रेडिस के माध्यम से सिंक्रनाइज़ेशन के साथ (पुस्तकालय github.com/go-redis/redis का उपयोग किया गया था )। डेटाबेस (ID ऑब्जेक्ट) से अनुरोधित ऑब्जेक्ट का केवल अनन्य पहचानकर्ता Redis में संग्रहीत किया जाएगा। यह ऑब्जेक्ट बनाने के अनुरोध के प्रसंस्करण के दौरान या डेटाबेस से एक मौजूदा ऑब्जेक्ट प्राप्त करने के अनुरोध के दौरान रेडिस में जोड़ा जाएगा। ऑब्जेक्ट आईडी रेडिस में मूल्य के लिए कुंजी के रूप में काम करेगा, और मूल्य उत्पन्न यूयूआईडी (सार्वभौमिक रूप से अद्वितीय पहचानकर्ता, सार्वभौमिक अद्वितीय पहचानकर्ता) होगा। यूयूआईडी तभी उत्पन्न होगा जब ऑब्जेक्ट को रेडिस में जोड़ा जाएगा। इस UUID की आवश्यकता क्यों है, इसका वर्णन बाद में किया जाएगा।

Redis के माध्यम से कैश सिंक्रनाइज़ेशन के लिए घटक इंटरैक्शन के ब्लॉक आरेख

इन-मेमोरी कैश को Sync.ap के आधार पर कार्यान्वित किया जाता है। हाइब्रिड कैश आइटम के लिए, टीटीएल (जीवनयापन करने का समय) निर्धारित किया जाता है, और यदि रेडिस "बेईमानी" आइटम को साफ करता है, तो इन-मेमोरी कैश को टाइमर (time.AfterFunc) द्वारा साफ किया जाता है। यह कैश के सभी तत्वों से गुजरता है और जांचता है कि क्या तत्व "सड़ा हुआ" है। यदि कोई कैश तत्व एक्सेस किया जाता है, तो उसका जीवनकाल बढ़ाया जाता है; Redis में कुंजियों के साथ एक समान ऑपरेशन किया जाता है।

तो, अब एल्गोरिथ्म के अनुसार। यदि कोई अनुरोध आता है और हमें ऑब्जेक्ट को पुनः प्राप्त करने की आवश्यकता होती है, तो क्रियाओं का निम्नलिखित अनुक्रम किया जाता है:

1. हम देखते हैं कि क्या Redis में किसी आईडी-ऑब्जेक्ट के साथ कोई ऑब्जेक्ट है, यदि ऐसा है, तो हम इन-मेमोरी से सर्विस इंस्टेंस कैश ले सकते हैं:
   
   1. यदि ऑब्जेक्ट इन-मेमोरी कैश में नहीं है, तो हम इसे डेटाबेस से लेते हैं और कैश को UUID से Redis से इन-मेमोरी कैश में जोड़ते हैं और Redis में कुंजी का TTL अपडेट करते हैं।
   2. यदि ऑब्जेक्ट इन-मेमोरी कैश में है, तो हम इसे कैश से लेते हैं, जांचें कि क्या कैश में और UUID रेडिस मैच में है, और यदि ऐसा है, तो TTL को कैश में और रेडिस में अपडेट करें। यदि यूयूआईडी मेल नहीं खाता है, तो इन-मेमोरी कैश से ऑब्जेक्ट को हटा दें, इसे डेटाबेस से लें, यूआईआईडी के साथ कैश को रेडिस से इन-मेमोरी में जोड़ें।
2. यदि ऑब्जेक्ट Redis में नहीं है, तो यदि ऑब्जेक्ट कैश में है, तो इसे कैश से हटा दें। डेटाबेस से एक ऑब्जेक्ट लें और इसे कैश और रेडिस में जोड़ें। किसी प्रविष्टि को अपडेट / डिलीट करते समय स्थिति को खत्म करने के लिए कैश ( andververbin टिप्पणी ) को जोड़ने से अधिक तेज़ होता है, कैश में शून्य UUID के साथ कोई ऑब्जेक्ट जोड़ें। फिर, कैश तक पहली पहुंच में, रेडिस के साथ यूयूआईडी में अंतर सामने आएगा, और डेटाबेस से डेटा फिर से अनुरोध किया जाएगा।

यदि किसी ऑब्जेक्ट को हटाने का अनुरोध आता है, तो उसे तुरंत डेटाबेस से हटा दिया जाता है, और फिर कैश ऑपरेशन:

1. Redis में ऑब्जेक्ट हटाएं।
2. इन-मेमोरी कैश में ऑब्जेक्ट हटाएं।

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

डेटाबेस में अद्यतन करने के बाद वस्तु अद्यतन,

1. Redis में ऑब्जेक्ट हटाएं।
2. इन-मेमोरी कैश में ऑब्जेक्ट हटाएं।

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

यानी वास्तव में, किसी भी समझ से बाहर की स्थिति में, हम मानते हैं कि हमारा कैश गलत है, और हमें डेटाबेस से डेटा लेने की आवश्यकता है।

निष्कर्ष

विकसित समाधान में पेशेवरों और विपक्ष दोनों हैं।

आकर्षण आते हैं

• विकसित कैशिंग योजना ने लगभग 19000 आरपीएस प्राप्त करना संभव बनाया, जो इन-मेमोरी कैश के साथ परीक्षण के लगभग बराबर है।
• मूल प्रोजेक्ट कोड में न्यूनतम संख्या में परिवर्तन होते हैं।

विपक्ष

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

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