केवळ प्रक्रियाच नाही: आम्ही काफ्का स्ट्रीममधून वितरित डेटाबेस कसा बनवला आणि त्यातून काय आले

अहो हाब्र!

आम्ही तुम्हाला आठवण करून देतो की बद्दल पुस्तक खालील काफका आम्ही वाचनालयाबद्दल तितकेच मनोरंजक कार्य प्रकाशित केले आहे काफ्का प्रवाह API.

आत्तासाठी, समुदाय फक्त या शक्तिशाली साधनाच्या मर्यादा शिकत आहे. तर, नुकताच एक लेख प्रकाशित झाला आहे, ज्याचा अनुवाद आम्ही तुमची ओळख करून देऊ इच्छितो. काफ्का स्ट्रीम्सला वितरित डेटा स्टोरेजमध्ये कसे बदलायचे हे लेखक स्वतःच्या अनुभवावरून सांगतात. वाचनाचा आनंद घ्या!

अपाचे लायब्ररी काफ्का प्रवाह Apache Kafka वर वितरित प्रवाह प्रक्रियेसाठी जगभरातील उपक्रमांमध्ये वापरले जाते. या फ्रेमवर्कचा एक कमी महत्त्वाचा पैलू असा आहे की ते तुम्हाला थ्रेड प्रक्रियेवर आधारित स्थानिक स्थिती संचयित करण्यास अनुमती देते.

या लेखात, मी तुम्हाला सांगेन की आमच्या कंपनीने क्लाउड ऍप्लिकेशन सुरक्षेसाठी उत्पादन विकसित करताना या संधीचा फायदेशीर वापर कसा केला. काफ्का प्रवाह वापरून, आम्ही सामायिक राज्य मायक्रो सर्व्हिसेस तयार केल्या आहेत, ज्यापैकी प्रत्येक दोष-सहिष्णु आणि सिस्टममधील वस्तूंच्या स्थितीबद्दल विश्वसनीय माहितीचा उच्च उपलब्ध स्रोत म्हणून काम करते. आमच्यासाठी, हे विश्वासार्हता आणि समर्थन सुलभतेच्या दृष्टीने एक पाऊल पुढे आहे.

तुम्हाला तुमच्या वस्तूंच्या औपचारिक स्थितीचे समर्थन करण्यासाठी एकच केंद्रीय डेटाबेस वापरण्याची परवानगी देणार्‍या पर्यायी दृष्टिकोनामध्ये स्वारस्य असल्यास, ते वाचा, ते मनोरंजक असेल...

आम्हाला का वाटले की आम्ही सामायिक राज्यासह कार्य करण्याची पद्धत बदलण्याची वेळ आली आहे

आम्हाला एजंटच्या अहवालांवर आधारित विविध वस्तूंची स्थिती राखण्याची गरज होती (उदाहरणार्थ: साइटवर हल्ला झाला होता का)? काफ्का स्ट्रीम्सवर स्थलांतरित होण्यापूर्वी, राज्य व्यवस्थापनासाठी आम्ही अनेकदा एकाच केंद्रीय डेटाबेसवर (+ सेवा API) अवलंबून होतो. या पद्धतीचे तोटे आहेत: तारीख गहन परिस्थिती सातत्य राखणे आणि सिंक्रोनाइझेशन हे खरे आव्हान बनते. डेटाबेस अडथळे बनू शकतो किंवा संपुष्टात येऊ शकतो शर्यतीची स्थिती आणि अप्रत्याशिततेने ग्रस्त.

आकृती 1: मध्ये संक्रमणापूर्वी दिसणारी एक सामान्य विभाजित-स्थिती परिस्थिती
काफ्का आणि काफ्का प्रवाह: एजंट API द्वारे त्यांचे विचार संप्रेषण करतात, अद्यतनित स्थितीची गणना केंद्रीय डेटाबेसद्वारे केली जाते

सामायिक राज्य मायक्रो सर्व्हिसेस तयार करणे सोपे करून, Kafka Streams ला भेटा

सुमारे एक वर्षापूर्वी, आम्ही या समस्यांचे निराकरण करण्यासाठी आमच्या सामायिक राज्य परिस्थितींवर कठोरपणे विचार करण्याचे ठरवले. आम्ही ताबडतोब काफ्का प्रवाह वापरण्याचा निर्णय घेतला - आम्हाला माहित आहे की ते किती स्केलेबल, अत्यंत उपलब्ध आणि दोष-सहिष्णु आहे, त्यात किती समृद्ध प्रवाह कार्यक्षमता आहे (परिवर्तन, स्टेटफुलसह). काफ्कामध्ये मेसेजिंग सिस्टीम किती परिपक्व आणि विश्वासार्ह झाली आहे हे सांगायला नको.

आम्ही तयार केलेली प्रत्येक स्टेटफुल मायक्रोसर्व्हिसेस अगदी सोप्या टोपोलॉजीसह काफ्का स्ट्रीम्सच्या शीर्षस्थानी तयार केली गेली होती. यात 1) स्त्रोत 2) पर्सिस्टंट की-व्हॅल्यू स्टोअरसह प्रोसेसर 3) एक सिंक:

आकृती 2: स्टेटफुल मायक्रो सर्व्हिसेससाठी आमच्या स्ट्रीमिंग उदाहरणांचे डीफॉल्ट टोपोलॉजी. लक्षात घ्या की येथे एक भांडार देखील आहे ज्यामध्ये नियोजन मेटाडेटा आहे.

या नवीन पद्धतीमध्ये, एजंट स्त्रोत विषयामध्ये दिलेले संदेश तयार करतात आणि ग्राहक-म्हणतात, एक मेल सूचना सेवा-सिंक (आउटपुट विषय) द्वारे गणना केलेली सामायिक स्थिती प्राप्त करतात.

आकृती 3: सामायिक केलेल्या मायक्रोसर्व्हिसेससह परिस्थितीसाठी नवीन उदाहरण कार्य प्रवाह: 1) एजंट एक संदेश व्युत्पन्न करतो जो काफ्का स्रोत विषयावर पोहोचतो; 2) सामायिक स्थितीसह मायक्रोसर्व्हिस (काफ्का प्रवाह वापरून) त्यावर प्रक्रिया करते आणि अंतिम काफ्का विषयावर गणना केलेली स्थिती लिहिते; ज्यानंतर 3) ग्राहक नवीन स्थिती स्वीकारतात

अहो, हे अंगभूत की-व्हॅल्यू स्टोअर खरोखर खूप उपयुक्त आहे!

वर नमूद केल्याप्रमाणे, आमच्या सामायिक राज्य टोपोलॉजीमध्ये की-व्हॅल्यू स्टोअर आहे. आम्हाला ते वापरण्यासाठी अनेक पर्याय सापडले आणि त्यापैकी दोन खाली वर्णन केले आहेत.

पर्याय #1: गणनेसाठी की-व्हॅल्यू स्टोअर वापरा

आमच्या पहिल्या की-व्हॅल्यू स्टोअरमध्ये आम्हाला गणनेसाठी आवश्यक असलेला सहायक डेटा आहे. उदाहरणार्थ, काही प्रकरणांमध्ये सामायिक राज्य "बहुसंख्य मते" च्या तत्त्वानुसार निर्धारित केले गेले. रेपॉजिटरीमध्ये काही ऑब्जेक्टच्या स्थितीवर सर्व नवीनतम एजंट अहवाल असू शकतात. त्यानंतर, जेव्हा आम्हाला एका एजंटकडून किंवा दुसर्‍या एजंटकडून नवीन अहवाल प्राप्त होतो, तेव्हा आम्ही ते जतन करू शकतो, इतर सर्व एजंट्सकडून स्टोरेजमधून त्याच ऑब्जेक्टच्या स्थितीबद्दल अहवाल पुनर्प्राप्त करू शकतो आणि गणना पुन्हा करू शकतो.
खालील आकृती 4 दर्शविते की आम्ही की/व्हॅल्यू स्टोअरला प्रोसेसरच्या प्रक्रिया पद्धतीमध्ये कसे उघड केले जेणेकरून नवीन संदेशावर प्रक्रिया करता येईल.

उदाहरण 4: आम्ही प्रोसेसरच्या प्रक्रिया पद्धतीसाठी की-व्हॅल्यू स्टोअरमध्ये प्रवेश उघडतो (यानंतर, सामायिक स्थितीसह कार्य करणाऱ्या प्रत्येक स्क्रिप्टने पद्धत लागू करणे आवश्यक आहे. doProcess)

पर्याय #2: काफ्का स्ट्रीम्सच्या वर एक CRUD API तयार करणे

आमचा मूलभूत कार्य प्रवाह स्थापित केल्यानंतर, आम्ही आमच्या सामायिक राज्य मायक्रो सर्व्हिसेससाठी RESTful CRUD API लिहिण्याचा प्रयत्न करू लागलो. आम्हाला काही किंवा सर्व ऑब्जेक्ट्सची स्थिती पुनर्प्राप्त करण्यास तसेच ऑब्जेक्टची स्थिती सेट किंवा काढून टाकण्यास सक्षम व्हायचे होते (बॅकएंड समर्थनासाठी उपयुक्त).

सर्व Get State API चे समर्थन करण्यासाठी, जेव्हा जेव्हा आम्हाला प्रक्रियेदरम्यान स्थितीची पुनर्गणना करायची असते, तेव्हा आम्ही ते अंगभूत की-व्हॅल्यू स्टोअरमध्ये बर्याच काळासाठी संग्रहित केले. या प्रकरणात, खाली दिलेल्या सूचीमध्ये दर्शविल्याप्रमाणे, काफ्का स्ट्रीम्सचा एकच प्रसंग वापरून अशा एपीआयची अंमलबजावणी करणे अगदी सोपे आहे:

आकृती 5: ऑब्जेक्टची पूर्वगणना केलेली स्थिती प्राप्त करण्यासाठी अंगभूत की-व्हॅल्यू स्टोअर वापरणे

API द्वारे ऑब्जेक्टची स्थिती अद्यतनित करणे देखील कार्यान्वित करणे सोपे आहे. मुळात, तुम्हाला फक्त एक काफ्का निर्माता तयार करायचा आहे आणि नवीन राज्याचा समावेश असलेले रेकॉर्ड बनवण्यासाठी त्याचा वापर करायचा आहे. हे सुनिश्चित करते की API द्वारे व्युत्पन्न केलेल्या सर्व संदेशांवर इतर उत्पादकांकडून (उदा. एजंट) प्राप्त झालेल्या संदेशांप्रमाणेच प्रक्रिया केली जाईल.

आकृती 6: तुम्ही काफ्का निर्माता वापरून वस्तूची स्थिती सेट करू शकता

लहान गुंतागुंत: काफ्कामध्ये अनेक विभाजने आहेत

पुढे, आम्‍हाला प्रक्रिया भार वितरीत करायचा होता आणि प्रति परिस्थिती सामायिक-राज्य मायक्रो सर्व्हिसेसचा क्लस्टर प्रदान करून उपलब्धता सुधारायची होती. सेटअप एक ब्रीझ होता: एकदा आम्ही समान ऍप्लिकेशन आयडी (आणि समान बूटस्ट्रॅप सर्व्हर) अंतर्गत चालण्यासाठी सर्व उदाहरणे कॉन्फिगर केली की, जवळजवळ सर्व काही स्वयंचलितपणे केले जाते. आम्ही हे देखील निर्दिष्ट केले आहे की प्रत्येक स्त्रोत विषयामध्ये अनेक विभाजने असतील, जेणेकरून प्रत्येक उदाहरणास अशा विभाजनांचा उपसंच नियुक्त केला जाऊ शकतो.

मी हे देखील नमूद करेन की स्टेट स्टोअरची बॅकअप प्रत बनवणे ही एक सामान्य प्रथा आहे जेणेकरून, उदाहरणार्थ, अयशस्वी झाल्यानंतर पुनर्प्राप्तीच्या बाबतीत, ही प्रत दुसर्‍या उदाहरणावर हस्तांतरित करा. काफ्का स्ट्रीम्समधील प्रत्येक स्टेट स्टोअरसाठी, बदल लॉगसह एक प्रतिरूपित विषय तयार केला जातो (जे स्थानिक अद्यतनांचा मागोवा घेते). अशा प्रकारे, काफ्का सतत स्टेट स्टोअरचा बॅकअप घेतो. म्हणून, एक किंवा दुसर्या काफ्का स्ट्रीम्सच्या उदाहरणामध्ये अपयशी झाल्यास, राज्य स्टोअर दुसर्या प्रसंगावर त्वरीत पुनर्संचयित केले जाऊ शकते, जेथे संबंधित विभाजने जातील. आमच्या चाचण्यांनी दाखवले आहे की स्टोअरमध्ये लाखो रेकॉर्ड असले तरीही हे काही सेकंदात केले जाते.

शेअर्ड स्टेटसह एका मायक्रोसर्व्हिसमधून मायक्रोसर्व्हिसेसच्या क्लस्टरमध्ये जाणे, गेट स्टेट API लागू करणे कमी क्षुल्लक होते. नवीन परिस्थितीत, प्रत्येक मायक्रोसर्व्हिसच्या स्टेट स्टोअरमध्ये एकूण चित्राचा फक्त काही भाग असतो (ज्यांच्या की विशिष्ट विभाजनावर मॅप केल्या होत्या त्या वस्तू). आम्‍हाला आवश्‍यक असलेल्‍या ऑब्‍जेक्‍टची स्थिती कोणत्‍या उदाहरणात आहे हे आम्‍हाला ठरवायचे होते आणि खाली दाखविल्‍याप्रमाणे आम्‍ही हे थ्रेड मेटाडेटावर आधारित केले:

आकृती 7: स्ट्रीम मेटाडेटा वापरून, आम्ही कोणत्या उदाहरणावरून इच्छित ऑब्जेक्टची स्थिती शोधायची हे निर्धारित करतो; GET ALL API सोबत समान दृष्टिकोन वापरला गेला

की निष्कर्ष

काफ्का स्ट्रीम्समधील स्टेट स्टोअर्स वास्तविक वितरित डेटाबेस म्हणून काम करू शकतात,

• काफ्कामध्ये सतत प्रतिकृती
• अशा प्रणालीच्या शीर्षस्थानी CRUD API सहजपणे तयार केले जाऊ शकते
• एकाधिक विभाजने हाताळणे थोडे अधिक क्लिष्ट आहे
• सहाय्यक डेटा संचयित करण्यासाठी स्ट्रीमिंग टोपोलॉजीमध्ये एक किंवा अधिक राज्य स्टोअर जोडणे देखील शक्य आहे. हा पर्याय यासाठी वापरला जाऊ शकतो:
• प्रवाह प्रक्रियेदरम्यान गणनेसाठी आवश्यक असलेल्या डेटाचे दीर्घकालीन संचयन
• डेटाचे दीर्घकालीन संचयन जे पुढील वेळी स्ट्रीमिंग उदाहरणाची तरतूद केल्यावर उपयुक्त ठरू शकते
• जास्त...

हे आणि इतर फायदे काफ्का प्रवाहांना आपल्यासारख्या वितरित प्रणालीमध्ये जागतिक स्थिती राखण्यासाठी योग्य बनवतात. काफ्का स्ट्रीम्स उत्पादनात खूप विश्वासार्ह असल्याचे सिद्ध झाले आहे (ते उपयोजित केल्यापासून आम्हाला अक्षरशः कोणत्याही संदेशाचे नुकसान झाले नाही), आणि आम्हाला खात्री आहे की तिची क्षमता तिथेच थांबणार नाही!

स्त्रोत: www.habr.com