प्रशोधन मात्र होइन: हामीले काफ्का स्ट्रिमहरूबाट कसरी वितरित डाटाबेस बनायौं, र यसको के आयो

हे हाबर!

हामी तपाईंलाई सम्झना गराउँछौं कि पुस्तक पछ्याउँदै काफका हामीले पुस्तकालयको बारेमा उत्तिकै रोचक कार्य प्रकाशित गरेका छौं काफ्का स्ट्रिम्स API.

अहिलेको लागि, समुदायले यो शक्तिशाली उपकरणको सीमाहरू मात्र सिकिरहेको छ। त्यसोभए, भर्खरै एउटा लेख प्रकाशित भएको थियो, जसको अनुवाद हामी तपाईंलाई परिचय गराउन चाहन्छौं। आफ्नै अनुभवबाट, लेखकले काफ्का स्ट्रिमहरूलाई कसरी वितरित डाटा भण्डारणमा परिणत गर्ने भनेर बताउँछन्। पढेर आनन्द लिनुहोस्!

Apache पुस्तकालय काफ्का स्ट्रिम्स Apache Kafka को शीर्ष मा वितरित स्ट्रिम प्रशोधन को लागी उद्यमहरु मा विश्वव्यापी प्रयोग। यस ढाँचाको अप्रत्याशित पक्षहरू मध्ये एक यो हो कि यसले तपाईंलाई थ्रेड प्रशोधनमा आधारित स्थानीय राज्य भण्डारण गर्न अनुमति दिन्छ।

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

यदि तपाइँ वैकल्पिक दृष्टिकोणमा रुचि राख्नुहुन्छ जसले तपाइँलाई तपाइँको वस्तुहरूको औपचारिक अवस्था समर्थन गर्न एकल केन्द्रीय डाटाबेस प्रयोग गर्न अनुमति दिन्छ, यसलाई पढ्नुहोस्, यो रोचक हुनेछ ...

किन हामीले साझा राज्यको साथ काम गर्ने तरिका परिवर्तन गर्ने समय हो जस्तो लाग्यो

हामीले एजेन्ट रिपोर्टहरूमा आधारित विभिन्न वस्तुहरूको अवस्था कायम राख्न आवश्यक छ (उदाहरणका लागि: साइट आक्रमणमा थियो)? काफ्का स्ट्रिमहरूमा माइग्रेट गर्नु अघि, हामी प्रायः राज्य व्यवस्थापनको लागि एकल केन्द्रीय डाटाबेस (+ सेवा API) मा भर पर्यौं। यो दृष्टिकोण यसको कमजोरी छ: मिति गहन परिस्थितिहरू स्थिरता र सिंक्रोनाइजेसन कायम राख्नु एक वास्तविक चुनौती बन्छ। डाटाबेस एक बाधा हुन सक्छ वा समाप्त हुन सक्छ दौड अवस्था र अप्रत्याशितताबाट ग्रस्त छन्।

चित्र १: ट्रान्जिसन अघि देखिने एउटा सामान्य विभाजन-राज्य परिदृश्य
काफ्का र काफ्का स्ट्रिमहरू: एजेन्टहरूले API मार्फत आफ्ना विचारहरू सञ्चार गर्छन्, अद्यावधिक स्थिति केन्द्रीय डाटाबेस मार्फत गणना गरिन्छ।

साझा राज्य माइक्रो सेवाहरू सिर्जना गर्न सजिलो बनाउँदै, Kafka Streams लाई भेट्नुहोस्

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

हामीले सिर्जना गरेका प्रत्येक स्टेटफुल माइक्रोसर्भिसहरू काफ्का स्ट्रिम्स उदाहरणको शीर्षमा एकदम सरल टोपोलोजीको साथ बनाइएको थियो। यसमा १) स्रोत २) निरन्तर कुञ्जी-मान भण्डार भएको प्रोसेसर ३) सिङ्क:

चित्र २: स्टेटफुल माइक्रोसेवाहरूका लागि हाम्रो स्ट्रिमिङ उदाहरणहरूको पूर्वनिर्धारित टोपोलोजी। ध्यान दिनुहोस् कि यहाँ एउटा भण्डार पनि छ जसमा योजना मेटाडेटा समावेश छ।

यस नयाँ दृष्टिकोणमा, एजेन्टहरूले सन्देशहरू लेख्छन् जुन स्रोत विषयमा फिड गरिन्छ, र उपभोक्ताहरू - भन्नुहोस्, मेल सूचना सेवा - सिङ्क (आउटपुट विषय) मार्फत गणना गरिएको साझा अवस्था प्राप्त गर्नुहोस्।

चित्र 3: साझा माइक्रोसर्भिसेसको साथ परिदृश्यको लागि नयाँ उदाहरण कार्य प्रवाह: 1) एजेन्टले सन्देश उत्पन्न गर्दछ जुन काफ्का स्रोत विषयमा पुग्छ; 2) साझा राज्य (काफ्का स्ट्रिमहरू प्रयोग गरेर) भएको माइक्रोसर्भिसले यसलाई प्रशोधन गर्छ र गणना गरिएको अवस्थालाई अन्तिम काफ्का विषयमा लेख्छ; जस पछि 3) उपभोक्ताहरूले नयाँ राज्य स्वीकार्छन्

हे, यो निर्मित कुञ्जी-मान स्टोर वास्तवमा धेरै उपयोगी छ!

माथि उल्लेख गरिए अनुसार, हाम्रो साझा राज्य टोपोलोजीले एक प्रमुख-मूल्य भण्डार समावेश गर्दछ। हामीले यसलाई प्रयोग गर्नका लागि धेरै विकल्पहरू फेला पार्‍यौं, र ती मध्ये दुई तल वर्णन गरिएका छन्।

विकल्प #1: गणनाको लागि कुञ्जी-मान भण्डार प्रयोग गर्नुहोस्

हाम्रो पहिलो कुञ्जी-मान भण्डारमा हामीलाई गणनाको लागि आवश्यक सहायक डेटा समावेश थियो। उदाहरणका लागि, केही अवस्थामा साझा राज्य "बहुमत भोट" को सिद्धान्त द्वारा निर्धारण गरिएको थियो। भण्डारले केहि वस्तुको स्थितिमा सबै नवीनतम एजेन्ट रिपोर्टहरू समात्न सक्छ। त्यसपछि, जब हामीले एक एजेन्ट वा अर्कोबाट नयाँ रिपोर्ट प्राप्त गर्यौं, हामी यसलाई बचत गर्न सक्छौं, भण्डारबाट एउटै वस्तुको अवस्था बारे अन्य सबै एजेन्टहरूबाट रिपोर्टहरू पुन: प्राप्त गर्न सक्छौं, र गणना दोहोर्याउन सक्छौं।
तलको चित्र ४ ले देखाउँछ कि हामीले कसरी प्रोसेसरको प्रशोधन विधिमा कुञ्जी/मान भण्डारलाई उजागर गर्यौं ताकि नयाँ सन्देश प्रशोधन गर्न सकियोस्।

दृष्टान्त 4: हामीले प्रोसेसरको प्रशोधन विधिको लागि कुञ्जी-मान भण्डारमा पहुँच खोल्छौं (यसपछि, साझा राज्यसँग काम गर्ने प्रत्येक स्क्रिप्टले विधि लागू गर्नुपर्छ। doProcess)

विकल्प #2: काफ्का स्ट्रिमहरूको शीर्षमा CRUD API सिर्जना गर्दै

हाम्रो आधारभूत कार्य प्रवाह स्थापित गरिसकेपछि, हामीले हाम्रो साझा राज्य माइक्रो सेवाहरूको लागि RESTful CRUD API लेख्ने प्रयास गर्न थाल्यौं। हामी केहि वा सबै वस्तुहरूको स्थिति पुन: प्राप्त गर्न सक्षम हुन चाहन्थ्यौं, साथै वस्तुको स्थिति (ब्याकएन्ड समर्थनको लागि उपयोगी) सेट वा हटाउन।

सबै Get State API लाई समर्थन गर्न, जब पनि हामीलाई प्रशोधनको क्रममा राज्य पुन: गणना गर्न आवश्यक हुन्छ, हामीले यसलाई लामो समयको लागि निर्मित कुञ्जी-मान भण्डारमा भण्डारण गर्यौं। यस अवस्थामा, काफ्का स्ट्रिमहरूको एकल उदाहरण प्रयोग गरेर यस्तो API लागू गर्न एकदम सरल हुन्छ, तलको सूचीमा देखाइए अनुसार:

चित्र 5: वस्तुको पूर्व-कम्प्युटेड अवस्था प्राप्त गर्न बिल्ट-इन कुञ्जी-मान भण्डार प्रयोग गर्दै

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

चित्र 6: तपाईंले काफ्का निर्माता प्रयोग गरेर वस्तुको अवस्था सेट गर्न सक्नुहुन्छ

सानो जटिलता: काफ्कासँग धेरै विभाजनहरू छन्

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

म यो पनि उल्लेख गर्नेछु कि राज्य स्टोरको ब्याकअप प्रतिलिपि बनाउनु सामान्य अभ्यास हो ताकि, उदाहरणका लागि, असफलता पछि रिकभरीको अवस्थामा, यो प्रतिलिपि अर्को उदाहरणमा स्थानान्तरण गर्नुहोस्। काफ्का स्ट्रिमहरूमा प्रत्येक राज्य स्टोरको लागि, परिवर्तन लग (जसले स्थानीय अद्यावधिकहरू ट्र्याक गर्दछ) संग प्रतिकृति गरिएको विषय सिर्जना गरिन्छ। यसरी, काफ्काले निरन्तर राज्य स्टोरलाई ब्याकअप गर्छ। तसर्थ, एक वा अर्को काफ्का स्ट्रिम्स उदाहरणको विफलताको घटनामा, राज्य स्टोरलाई अर्को उदाहरणमा छिटो पुनर्स्थापित गर्न सकिन्छ, जहाँ सम्बन्धित विभाजनहरू जानेछन्। हाम्रो परीक्षणहरूले देखाएको छ कि स्टोरमा लाखौं रेकर्डहरू भए तापनि यो सेकेन्डको कुरामा गरिन्छ।

साझा अवस्था भएको एकल माइक्रोसर्भिसबाट माइक्रोसर्भिसेसको क्लस्टरमा सर्दै, गेट स्टेट एपीआई लागू गर्न यो कम मामूली हुन्छ। नयाँ अवस्थामा, प्रत्येक माइक्रोसर्भिसको स्टेट स्टोरले समग्र तस्वीरको मात्र अंश समावेश गर्दछ (ती वस्तुहरू जसको कुञ्जीहरू विशेष विभाजनमा म्याप गरिएका थिए)। हामीले कुन दृष्टान्तले हामीलाई चाहिने वस्तुको अवस्था समावेश गरेको निर्धारण गर्नुपर्‍यो, र हामीले यो थ्रेड मेटाडेटाको आधारमा गर्यौं, जस्तै तल देखाइएको छ:

चित्र 7: स्ट्रिम मेटाडेटा प्रयोग गरेर, हामीले कुन दृष्टान्तबाट इच्छित वस्तुको अवस्था सोध्ने भनेर निर्धारण गर्छौं; GET ALL API सँग समान दृष्टिकोण प्रयोग गरिएको थियो

कुञ्जी खोजीहरू

काफ्का स्ट्रिमहरूमा राज्य स्टोरहरूले वास्तविक रूपमा वितरित डाटाबेसको रूपमा सेवा गर्न सक्छ,

• काफ्कामा लगातार प्रतिकृति
• CRUD API सजिलैसँग यस्तो प्रणालीको शीर्षमा निर्माण गर्न सकिन्छ
• धेरै विभाजनहरू ह्यान्डल गर्न अलि बढी जटिल छ
• सहायक डाटा भण्डारण गर्न स्ट्रिमिङ टोपोलोजीमा एक वा बढी राज्य स्टोरहरू थप्न पनि सम्भव छ। यो विकल्प को लागी प्रयोग गर्न सकिन्छ:
• स्ट्रिम प्रशोधन गर्दा गणनाको लागि आवश्यक डेटाको लामो-समय भण्डारण
• डेटाको लामो-समय भण्डारण जुन अर्को पटक स्ट्रिमिङ उदाहरण प्रावधान गरिएको छ उपयोगी हुन सक्छ
• अझै धेरै...

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

स्रोत: www.habr.com