सभी को नमस्कार। मेरा नाम अलेक्जेंडर है, मैं कंपनियों के टिंकॉफ समूह में जावा डेवलपर हूं।

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

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

यह लेख एक परियोजना पर चर्चा करता है जिसका बैकएंड जावा में लिखा गया है। इसलिए, हम अस्थायी इन-मेमोरी कैशिंग के क्षेत्र में मानकों के बारे में भी बात करेंगे। हम JSR-107 विनिर्देश, असफल JSR-347 विनिर्देश और वसंत में कैशिंग सुविधाओं पर चर्चा करते हैं। बिल्ली के लिए आपका स्वागत है!

और एप्लिकेशन को सेवाओं में कटौती करते हैं ...

हम सेवा-उन्मुख वास्तुकला पर आगे बढ़ेंगे और कुबेरनेट्स में जाएंगे - जो हमने 6 महीने पहले तय किया था। एक लंबे समय के लिए, हमारी परियोजना एक अखंड थी, तकनीकी ऋण से जुड़ी कई समस्याएं थीं, और हमने अलग-अलग सेवाओं के रूप में सभी पर नए एप्लिकेशन मॉड्यूल लिखे। परिणामस्वरूप, एक सेवा-उन्मुख वास्तुकला और एक अखंड कटौती के लिए संक्रमण अपरिहार्य था।

हमारा आवेदन भरा हुआ है, औसतन 500 आरपीएस वेब सेवाओं के लिए आता है (पीक में यह 900 आरपीएस तक पहुंच जाता है)। प्रत्येक अनुरोध के जवाब में पूरे डेटा मॉडल को इकट्ठा करने के लिए, आपको कई बार विभिन्न कैश में जाना होगा।

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


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

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

नई सेवाओं के लिए लगातार आदेश देने और बुनियादी ढांचे की स्थापना की समस्या

हमें प्रत्येक सर्किट के लिए क्लस्टर में एक नाम स्थान दिया गया था, जिसमें हमारे पास तीन: देव - डेवलपर्स के लिए, क्यूए - परीक्षकों के लिए, ठेस - ग्राहकों के लिए।

नाम स्थान हाइलाइट होने के साथ, एक नई सेवा या एप्लिकेशन जोड़ने से चार मैनिफ़ेस्ट लिखने में कमी आती है: परिनियोजन, सेवा, इनग्रेड और कॉन्फ़िगमैप।

उच्च भार सहिष्णुता

व्यवसाय का विस्तार और लगातार बढ़ रहा है - एक साल पहले औसत लोड वर्तमान की तुलना में दो गुना कम था।

कुबेरनेट्स में क्षैतिज स्केलिंग आपको विकसित परियोजना के काम के बोझ के साथ पैमाने की अर्थव्यवस्थाओं को बाहर करने की अनुमति देता है।

रखरखाव, लॉग संग्रह और निगरानी

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

बेशक, यह सब Ansible या Terraform का उपयोग करके स्वचालित किया जा सकता है, लेकिन अंत में, प्रत्येक सेवा के लिए कई मैनिफ़ेस्ट लिखना बहुत आसान है।

उच्च विश्वसनीयता

निर्मित में L8- और रेडीनेस-सैंपल्स के k8s तंत्र आपको यह चिंता करने की अनुमति नहीं देता है कि एप्लिकेशन धीमा पड़ना शुरू हो गया है या पहले से ही जवाब देने लगा है।

कुबेरनेट्स अब चूल्हा फली के जीवन चक्र को नियंत्रित करता है जिसमें अनुप्रयोग कंटेनर और उनके लिए निर्देशित यातायात होता है।

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

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

स्केलेबल सिस्टम के आधुनिक विकास में, स्टेटलेस आर्किटेक्चर उपरोक्त समस्याओं का समाधान है। हमने सभी समस्याओं को S3 क्लाउड स्टोरेज में ले जाकर पहली समस्या से छुटकारा दिलाया।

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

हम अलग-अलग नोड्स पर कैश को सिंक्रनाइज़ करते हैं

प्रारंभिक डेटा के रूप में हमारे पास एन नोड्स से युक्त एक वितरित प्रणाली है। प्रत्येक नोड में लगभग 20 इन-मेमोरी कैश हैं, जिसमें डेटा प्रति घंटे कई बार अपडेट किया जाता है।

अधिकांश कैश में TTL (टाइम-टू-लाइव) डेटा रिफ्रेश पॉलिसी होती है, कुछ डेटा को उच्च भार के कारण हर 20 मिनट में CRON ऑपरेशन के साथ अपडेट किया जाता है। कैश पर काम का बोझ रात में कई हजार आरपीएस से दिन के दौरान कई दसियों हजार तक भिन्न होता है। पीक लोड, एक नियम के रूप में, 100,000 आरपीएस से अधिक नहीं है। अस्थायी भंडारण में रिकॉर्ड की संख्या कई सौ हजार से अधिक नहीं होती है और इसे एक नोड के ढेर में रखा जाता है।

हमारा कार्य अलग-अलग नोड्स पर एक ही कैश के बीच डेटा संगति को प्राप्त करना है, साथ ही सबसे कम संभव प्रतिक्रिया समय भी। विचार करें कि इस समस्या को हल करने के आम तौर पर क्या तरीके हैं।

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


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

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

दूसरा विकल्प इन-मेमोरी डेटा ग्रिड (IMDG) का उपयोग करना है, जो एक वितरित इन-मेमोरी कैश है। इस तरह के एक समाधान की योजना इस प्रकार है:


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

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

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

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

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

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

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


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

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

वैसे, Redis में एक समान PUB / SUB तंत्र मौजूद है। लेकिन, मेरी राय में, कतार के साथ काम करने के लिए कतार प्रबंधक का उपयोग करना अभी भी बेहतर है, और RabbitMQ हमारे कार्य के लिए एकदम सही था।

JSR 107 मानक और इसका कार्यान्वयन

मेमोरी में डेटा के अस्थायी भंडारण के लिए मानक जावा कैश एपीआई (विनिर्देश JSR-107 ) का एक लंबा इतिहास है, इसे 12 वर्षों के लिए विकसित किया गया है।

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

बाजार पर लंबे 12 वर्षों में, अस्थायी डेटा स्टोरेज के लिए स्थान हैशपॉज से बदलकर Java 1.5 की रिलीज के साथ समवर्ती हाशपा में बदल गया है, और बाद में इन-मेमोरी कैशिंग के बहुत सारे तैयार खुले स्रोत कार्यान्वयन दिखाई दिए।

JSR-107 जारी होने के बाद, विक्रेता समाधानों ने धीरे-धीरे नए विनिर्देश को लागू करना शुरू कर दिया। JCache के लिए, वितरित कैशिंग में विशेषज्ञता वाले प्रदाता भी हैं - बहुत डेटा ग्रिड, जिसके लिए विनिर्देश कभी भी लागू नहीं किया गया है।

इस बात पर विचार करें कि javax.cache पैकेज में क्या है , और हमारे आवेदन के लिए कैशे उदाहरण कैसे प्राप्त करें:

CachingProvider provider = Caching.getCachingProvider("org.cache2k.jcache.provider.JCacheProvider"); CacheManager cacheManager = provider.getCacheManager(); CacheConfiguration<Integer, String> config = new MutableConfiguration<Integer, String>() .setTypes(Integer.class, String.class) .setReadThrough(true) . . .; Cache<Integer, String> cache = cacheManager.createCache(cacheName, config); 

यहाँ CachingProvider के लिए एक बूट लोडर है।

हमारे मामले में, JCacheProvider, जो JSR-107 प्रदाता SPI का कैश 2k कार्यान्वयन है, को ClassLoader से लोड किया जाएगा। लोडर के लिए, आपको प्रदाता कार्यान्वयन को निर्दिष्ट करने की आवश्यकता नहीं हो सकती है, लेकिन फिर यह उस कार्यान्वयन को लोड करने का प्रयास करेगा जो अंदर निहित है

मेटा-इन / सेवाओं / javax.cache.spi.CachingProvider

किसी भी स्थिति में, ClassLoader में CachingProvider का एकल कार्यान्वयन होना चाहिए।

यदि आप बिना किसी कार्यान्वयन के javax.cache लाइब्रेरी का उपयोग करते हैं, तो जब आप JCache बनाने का प्रयास करते हैं, तो एक अपवाद फेंक दिया जाएगा। प्रदाता का उद्देश्य कैचेमैनमैन के जीवन चक्र को बनाना और प्रबंधित करना है, जो बदले में, कैश को प्रबंधित और कॉन्फ़िगर करने के लिए जिम्मेदार है। इस प्रकार, कैश बनाने के लिए, आपको निम्नलिखित तरीके से जाना चाहिए:


CacheManager का उपयोग करके बनाए गए मानक कैश में कार्यान्वयन-संगत कॉन्फ़िगरेशन होना चाहिए। Javax.cache द्वारा प्रदान मानक कैशेकोनफिगरेशन को एक विशिष्ट CacheProvider कार्यान्वयन के लिए बढ़ाया जा सकता है।

आज, JSR-107 विनिर्देश के दर्जनों अलग-अलग कार्यान्वयन हैं: एहचे , अमरूद , कैफीन , कैश 2k । कई कार्यान्वयन वितरित सिस्टम में इन-मेमोरी डेटा ग्रिड हैं - हेज़ेलकास्ट , ओरेकल कोहरेंस ।

कई अस्थायी भंडारण कार्यान्वयन भी हैं जो मानक एपीआई का समर्थन नहीं करते हैं। हमारे प्रोजेक्ट में लंबे समय तक हमने Ehcache 2 का उपयोग किया, जो Jache (Ehcache 3 के साथ प्रदर्शित विनिर्देश का कार्यान्वयन) के साथ संगत नहीं है। जे-कैश-संगत कार्यान्वयन के लिए संक्रमण की आवश्यकता इन-मेमोरी कैश की स्थिति की निगरानी करने की आवश्यकता के साथ दिखाई दी। मानक मीट्रिकगैजिस्ट्री का उपयोग करते हुए, केवल JCacheGaugeSet कार्यान्वयन की सहायता से निगरानी को तेज करना संभव था, जो मानक JCache से मैट्रिक्स एकत्र करता है।

अपनी परियोजना के लिए उपयुक्त इन-मेमोरी कैश कार्यान्वयन कैसे चुनें? शायद आपको निम्नलिखित पर ध्यान देना चाहिए:

1. क्या आपको JSR-107 विनिर्देश के लिए समर्थन की आवश्यकता है।
2. यह चयनित कार्यान्वयन की गति पर ध्यान देने योग्य भी है। भारी भार के तहत, आंतरिक कैश का प्रदर्शन आपके सिस्टम के प्रतिक्रिया समय पर महत्वपूर्ण प्रभाव डाल सकता है।
3. वसंत में समर्थन। यदि आप अपनी परियोजना में अच्छी तरह से ज्ञात ढांचे का उपयोग करते हैं, तो यह इस तथ्य पर विचार करने योग्य है कि वसंत में हर जेवीएम कैश कार्यान्वयन के पास संगत कैशमैनेजर नहीं है।

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

 @Bean public org.springframework.cache.CacheManager cacheManager() { CachingProvider provider = Caching.getCachingProvider(); CacheManager cacheManager = provider.getCacheManager(); return new JCacheCacheManager(cacheManager); } 

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

ऊपर दिया गया उदाहरण कैश स्पेसिफिकेशन मैनेजर के लिए JCacheCacheManager रैपर के उपयोग को दर्शाता है। इसका मतलब यह है कि किसी भी JSR-107 कार्यान्वयन में स्प्रिंग कैशेमैनगर के साथ संगतता है। यह आपकी परियोजना के लिए JSR विनिर्देश के समर्थन के साथ इन-मेमोरी कैश चुनने का एक और कारण है। लेकिन अगर आपको अभी भी इस समर्थन की आवश्यकता नहीं है, लेकिन मैं वास्तव में @ उपयोग योग्य होना चाहता हूं, तो आपके पास दो और आंतरिक कैश समाधानों के लिए समर्थन है: EhCacheCacheManager और CaffeineCacheManager।

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

एक वितरण प्रणाली में समाशोधन कैश

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

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

इस तरह के समाधान को लागू करते समय, दिमाग में आने वाला पहला विचार कुछ EventListener का उपयोग करना है, Jache में कैश से एक प्रविष्टि को हटाने की घटना के लिए CacheEntryRemovedListener है। ऐसा लगता है कि यह अपने स्वयं के श्रोता कार्यान्वयन को जोड़ने के लिए पर्याप्त है, जो रिकॉर्ड को हटाते समय विषय को संदेश भेजेगा, और सभी नोड्स पर यूटैक्टिक कैश तैयार है - बशर्ते कि प्रत्येक नोड सामान्य विषय से जुड़े कतार से घटनाओं के लिए सुनता है, जैसा कि आरेख में दिखाया गया है इसके बाद के संस्करण।

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


विचार करें कि स्थानीय कैश से हटाए जा रहे मूल्य की घटना को पकड़ने के अन्य तरीके क्या हैं।

EventListeners के बगल में javax.cache.event पैकेज में, एक CacheEntryEventFilter भी है, जो कि JavaDoc के अनुसार, इस ईवेंट को CacheEntryListener में भेजने से पहले किसी भी CacheEntryEventor के लिए जाँच करने के लिए उपयोग किया जाता है, चाहे वह एक रिकॉर्ड, विलोपन या कोई ईवेंट या कोई ईवेंट है। कैश में। फ़िल्टर का उपयोग करते समय, हमारी समस्या बनी रहेगी, क्योंकि CacheEntryEvent इवेंट लॉग होने के बाद और कैश में CRUD ऑपरेशन करने के बाद तर्क निष्पादित किया जाएगा।

फिर भी, कैश से रिकॉर्ड को हटाने के लिए किसी घटना की दीक्षा को पकड़ना संभव है। ऐसा करने के लिए, JCache में अंतर्निहित टूल का उपयोग करें जो आपको बाहरी स्रोत से डेटा लिखने और लोड करने के लिए एपीआई विनिर्देशों का उपयोग करने की अनुमति देता है, अगर वे कैश में नहीं हैं। Javax.cache.integration पैकेज में इसके लिए दो इंटरफेस हैं:

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

स्थिरता सुनिश्चित करने के लिए, कैश कैश विधि संबंधित कैश ऑपरेशन के संबंध में परमाणु हैं। हमें लगता है कि हमारी समस्या का हल मिल गया है।

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

निष्कर्ष

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

किसी भी विकसित प्रणाली के लिए एक सार्वभौमिक कार्यान्वयन लागू करना बहुत मुश्किल है। ऐसे प्रत्येक कार्यान्वयन के लिए, उपयोग के लिए इष्टतम स्थितियां हैं। हमारे मामले में, परियोजना की बारीकियों ने इस लेख में वर्णित समाधान का नेतृत्व किया। अगर किसी को भी इसी तरह की समस्या है, तो हमें अपने समाधान को साझा करने और GitHub पर प्रकाशित करने में खुशी होगी।