सभी को नमस्कार। इस लेख में मैं आपको बताऊंगा कि हमने अवितो में नौ महीने पहले काफ्का को क्यों चुना और यह क्या है। मैं एक उपयोग के मामलों को साझा करूंगा - एक संदेश दलाल। और अंत में, आइए बात करते हैं कि काफ्का को सेवा के दृष्टिकोण के रूप में लागू करने से हमें क्या फायदे हुए।

समस्या

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

बड़ी संख्या में सेवाओं के साथ समस्याओं में से एक संचार है। सेवा A अक्सर उस सेवा की जानकारी जानना चाहता है जो B के पास है। इस मामले में, सेवा A समकालिक API के माध्यम से सेवा B तक पहुँचता है। सेवा बी जानना चाहती है कि सेवाओं जी और डी के साथ क्या होता है, और जो बदले में, ए और बी सेवाओं में रुचि रखते हैं। जब ऐसी कई "जिज्ञासु" सेवाएं होती हैं, तो उनके बीच के संबंध एक पेचीदा गेंद में बदल जाते हैं।

इसके अलावा, किसी भी समय, सेवा A अनुपलब्ध हो सकती है। और इस मामले में क्या करना है, सेवा बी और उससे जुड़ी अन्य सभी सेवाएं? और यदि आपको किसी व्यवसाय संचालन को पूरा करने के लिए लगातार सिंक्रोनस कॉल की एक श्रृंखला बनाने की आवश्यकता है, तो पूरे ऑपरेशन की विफलता की संभावना और भी अधिक हो जाती है (और यह अधिक है, यह श्रृंखला जितनी लंबी होगी)।

प्रौद्योगिकी चयन

ठीक है, समस्याएं स्पष्ट हैं। आप सेवाओं के बीच एक केंद्रीकृत संदेश प्रणाली बनाकर उन्हें समाप्त कर सकते हैं। अब, प्रत्येक सेवा केवल इस संदेश प्रणाली के बारे में जानने के लिए पर्याप्त है। इसके अलावा, सिस्टम में स्वयं दोषपूर्ण और क्षैतिज रूप से मापनीय होना चाहिए, साथ ही दुर्घटनाओं के मामले में, बाद के प्रसंस्करण के लिए कॉल बफर जमा करें।

आइए अब उस तकनीक का चयन करें जिस पर संदेश वितरण लागू किया जाएगा। ऐसा करने के लिए, पहले समझें कि हम उससे क्या उम्मीद करते हैं:

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

उच्च थ्रूपुट (प्रति सेकंड कुछ किलोबाइट पर कम से कम 100k संदेश) के साथ सबसे अधिक स्केलेबल और विश्वसनीय प्रणाली का चयन करना भी हमारे लिए महत्वपूर्ण था।

इस स्तर पर, हमने RabbitMQ को अलविदा कहा (यह उच्च स्तर पर स्थिर रखने के लिए कठिन है), SkyTools PGQ (तेजी से पर्याप्त और खराब स्केलेबल नहीं) और NSQ (लगातार नहीं)। हमारी कंपनी में इन सभी तकनीकों का उपयोग किया जाता है, लेकिन वे कार्य को हाथ में नहीं लेते थे।

फिर हमने हमारे लिए नई तकनीकों को देखना शुरू किया - अपाचे काफ्का, अपाचे पल्सर और एनएटीएस स्ट्रीमिंग।

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

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

हालाँकि, NATS स्ट्रीमिंग गो में लिखी और क्लाउड नेटिव कम्प्यूटिंग फाउंडेशन द्वारा समर्थित एक शांत तकनीक है। अपाचे काफ्का के विपरीत, इसे काम करने के लिए ज़ुकीपर की ज़रूरत नहीं है (यह जल्द ही कफ़्का के बारे में भी ऐसा ही कहना संभव हो सकता है ), क्योंकि यह RAFT को लागू करता है। उसी समय, NATS स्ट्रीमिंग को प्रशासित करना आसान है। हम इसे बाहर नहीं करते हैं कि भविष्य में हम इस तकनीक पर लौट आएंगे।

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

काफ्का की समीक्षा करें

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

तो, आइए एक नजर डालते हैं कि काफ्का एक पक्षी की आंखों का दृश्य कैसे है। बुनियादी कफ़्का टोपोलॉजी में निर्माता, उपभोक्ता, दलाल और ज़ुकीपर शामिल हैं।

दलाल

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

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

• संग्रहीत डेटा और / या उनकी आयु की मात्रा (अवधारण), रिटेंशन.एमएस);
• डेटा अतिरेक कारक (प्रतिकृति कारक);
• एक संदेश का अधिकतम आकार (max.message.bytes);
• संगत प्रतिकृतियों की न्यूनतम संख्या जिस पर विषय (min.insync.replicas) को डेटा लिखा जा सकता है;
• संभावित डेटा हानि के साथ एक गैर-तुल्यकालिक लैगिंग प्रतिकृति के लिए विफलता की क्षमता (अशुद्ध। कर्नल। चयन)।
• और भी बहुत कुछ ( https://kafka.apache.org/documentation/#topicconfigs )।

बदले में, प्रत्येक विषय को एक या अधिक विभाजन (विभाजन) में विभाजित किया जाता है। यह विभाजन में है कि घटनाएं अंततः गिर जाती हैं। यदि क्लस्टर में एक से अधिक ब्रोकर हैं, तो विभाजन सभी ब्रोकरों (जहां तक ​​संभव हो) के बीच समान रूप से वितरित किया जाएगा, जो आपको एक ही बार में कई ब्रोकरों को एक विषय में लिखने और पढ़ने पर लोड को स्केल करने की अनुमति देगा।

डिस्क पर, प्रत्येक विभाजन के लिए डेटा खंड फ़ाइलों के रूप में संग्रहीत होता है, डिफ़ॉल्ट रूप से एक गीगाबाइट के बराबर (log.segment.ntes के माध्यम से नियंत्रित)। एक महत्वपूर्ण विशेषता विभाजन से डेटा का विलोपन है (जब अवधारण को ट्रिगर किया जाता है) सिर्फ खंडों से (आप विभाजन से एक घटना को नहीं हटा सकते हैं, आप केवल पूरे खंड को हटा सकते हैं, और केवल निष्क्रिय है)।

चिड़ियाघर संचालक

ज़ुकीपर मेटाडेटा रिपॉजिटरी और समन्वयक के रूप में कार्य करता है। यह वह है जो यह कहने में सक्षम है कि क्या दलाल जीवित हैं (आप इसे ज़ूकीपर की आंखों से ज़ुकीपर-शेल कमांड ls /brokers/ids माध्यम से देख सकते हैं), कौन से ब्रोकर नियंत्रक हैं ( get /controller ), क्या विभाजन उनके प्रतिकृतियों के साथ समकालिक स्थिति में हैं ( get /brokers/topics/topic_name/partitions/partition_number/state )। साथ ही, निर्माता और उपभोक्ता सबसे पहले ज़ूकीपर के पास जाएंगे, यह पता लगाने के लिए कि कौन सा दलाल किस विषय और विभाजन को संग्रहीत करता है। ऐसे मामलों में जब विषय के लिए 1 से अधिक प्रतिकृति कारक निर्दिष्ट किया जाता है, तो ज़ूकीपर इंगित करेगा कि कौन से विभाजन नेता हैं (वे से लिखे और पढ़े जाएंगे)। एक दलाल दुर्घटना की स्थिति में, यह ज़ुकीपर में है कि नए नेता विभाजन के बारे में जानकारी दर्ज की जाएगी (संस्करण 1.1.0 asynchronously के रूप में, और यह महत्वपूर्ण है )।

काफ्का के पुराने संस्करणों में, ज़ूकीटर भी ऑफ़सेट स्टोर करने के लिए ज़िम्मेदार था, लेकिन अब वे ब्रोकर पर एक विशेष विषय __consumer_offsets में संग्रहीत हैं (हालांकि आप अभी भी इन उद्देश्यों के लिए __consumer_offsets उपयोग कर सकते हैं)।

अपने डेटा को कद्दू में बदलने का सबसे आसान तरीका ज़ुकाइपर के साथ जानकारी का नुकसान है। ऐसे परिदृश्य में, यह समझना बहुत मुश्किल होगा कि क्या और कहाँ से पढ़ना है।

उत्पादक

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

डिफ़ॉल्ट रूप से, सभी घटनाओं को राउंड-रॉबिन के साथ विभाजन के विभाजन द्वारा वितरित किया जाता है यदि कुंजी सेट नहीं है (ऑर्डर खो रहा है), और मुरमुरैश (कुंजी) के माध्यम से यदि कुंजी मौजूद है (उसी विभाजन के भीतर आदेश)।

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

उपभोक्ता

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

अपाचे काफ्का को याद है कि उपभोक्ता को हाल ही में कौन सी घटनाओं ( __consumer__offsets सेवा विषय का उपयोग किया जाता है) के लिए याद किया जाता है, जिससे यह सुनिश्चित होता है कि सफल पढ़ने पर, उपभोक्ता को एक ही संदेश दो बार नहीं मिलेगा। फिर भी, यदि आप विकल्प का उपयोग करते हैं enable.auto.commit = true और पूरी तरह से कफका विषय में उपभोक्ता की स्थिति को ट्रैक करने का काम दे, तो आप डेटा खो सकते हैं। उत्पादन कोड में, उपभोक्ता की स्थिति को अक्सर मैन्युअल रूप से नियंत्रित किया जाता है (डेवलपर उस पल को नियंत्रित करता है जब रीड इवेंट की प्रतिबद्धता होनी चाहिए)।

ऐसे मामलों में जहां एक उपभोक्ता पर्याप्त नहीं है (उदाहरण के लिए, नई घटनाओं का प्रवाह बहुत बड़ा है), आप उपभोक्ता समूह में एक साथ जोड़कर कुछ और उपभोक्ताओं को जोड़ सकते हैं। उपभोक्ता समूह तार्किक रूप से एक ही उपभोक्ता है, लेकिन समूह के सदस्यों के बीच डेटा के वितरण के साथ। यह प्रत्येक प्रतिभागी को अपने संदेशों को साझा करने की अनुमति देता है, जिससे पढ़ने की गति बढ़ जाती है।

परीक्षण के परिणाम

यहां मैं बहुत सारे व्याख्यात्मक पाठ नहीं लिखूंगा, बस परिणाम साझा करें। 3 भौतिक मशीनों (12 सीपीयू, 384 जीबी रैम, 15k एसएएस डीआईएसके, 10 जीबीआईटी / एस नेट) पर परीक्षण किया गया था, दलालों और ज़ुकीपर को lxc में तैनात किया गया था।

प्रदर्शन परीक्षण

परीक्षण के दौरान, निम्नलिखित परिणाम प्राप्त किए गए थे।

• 9 निर्माताओं द्वारा एक साथ आकार में 1KB के संदेश रिकॉर्ड करने की गति - प्रति सेकंड 1300000 घटनाएं।
• 9 उपभोक्ताओं द्वारा एक ही समय में 1KB संदेशों की पढ़ने की गति - प्रति सेकंड 1,500,000 ईवेंट।

दोष सहिष्णुता परीक्षण

परीक्षण के दौरान, निम्नलिखित परिणाम प्राप्त किए गए (3 दलाल, 3 ज़ुकीपर)।

• दलालों में से एक की असामान्य समाप्ति क्लस्टर के निलंबन या दुर्गमता की ओर नहीं ले जाती है। काम हमेशा की तरह जारी है, लेकिन शेष दलालों का बड़ा बोझ है।
• तीन दलालों के एक क्लस्टर के मामले में दो दलालों की असामान्य समाप्ति और min.isr = 2 लिखने के लिए क्लस्टर की अयोग्यता की ओर जाता है, लेकिन पठनीयता के लिए। Min.isr = 1 के मामले में, क्लस्टर पढ़ने और लिखने के लिए उपलब्ध है। हालांकि, यह मोड उच्च डेटा सुरक्षा के लिए आवश्यकता के विपरीत है।
• ज़ुकाइपर सर्वरों में से एक की असामान्य समाप्ति क्लस्टर शटडाउन या दुर्गमता की ओर नहीं ले जाती है। काम सामान्य रूप से जारी है।
• दो ज़ुकीपर सर्वरों की असामान्य समाप्ति एक क्लस्टर दुर्गमता की ओर ले जाती है जब तक कि ज़ुकीपर सर्वरों में से कम से कम एक को बहाल नहीं किया जाता है। यह कथन 3 सर्वर के ज़ूकीपर क्लस्टर के लिए सही है। परिणामस्वरूप, अनुसंधान के बाद, गलती सहनशीलता को बढ़ाने के लिए ज़ुकीपर क्लस्टर को 5 सर्वर तक बढ़ाने का निर्णय लिया गया।
  

एक सेवा के रूप में काफ्का

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

• डेटा-बस ने काफ्का (उपभोक्ताओं और उत्पादकों के कार्यान्वयन और विन्यास, निगरानी, ​​सतर्कता, लॉगिंग, स्केलिंग, आदि) के साथ एकीकरण से संबंधित सभी कार्यों को संभाला। इस प्रकार, संदेश दलाल के साथ एकीकरण यथासंभव सरल है।

  
  

• डेटा-बस ने काफ्का के साथ काम करने के लिए एक विशिष्ट भाषा या पुस्तकालय से अमूर्त करने की अनुमति दी।

  
  

• डेटा बस ने अन्य सेवाओं को भंडारण परत से अमूर्त करने की अनुमति दी। हो सकता है कि किसी समय हम काफ्का को पल्सर में बदल देंगे, और किसी को कुछ भी नोटिस नहीं होगा (सभी सेवाओं को केवल डेटा-बस एपीआई के बारे में पता है)।

  
  

• डेटा बस ने ईवेंट स्कीमाओं के सत्यापन को संभाला।

  
  

• डेटा-बस प्रमाणीकरण का उपयोग करके कार्यान्वित किया जाता है।

  
  

• डेटा-बस के कवर के तहत, हम डाउनटाइम के बिना, काफ्का संस्करणों को सावधानीपूर्वक अपडेट कर सकते हैं, उत्पादकों, उपभोक्ताओं, दलालों, आदि के केंद्रीय आचरण कर सकते हैं।

  
  

• डेटा-बस ने हमें उन सुविधाओं को जोड़ने की अनुमति दी जिनकी हमें आवश्यकता है जो काफ्का में नहीं हैं (जैसे विषय ऑडिट, क्लस्टर में विसंगतियों की निगरानी करना, डीएलक्यू बनाना, आदि)।

  
  

• डेटा-बस सभी सेवाओं के लिए विफलता को केंद्रीय रूप से लागू करने की अनुमति देता है।

  
  

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

बेशक, कोई चांदी की गोली नहीं है, और इस दृष्टिकोण की अपनी सीमाएं हैं।

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

हमारे मामले में, पेशेवरों ने विपक्ष को छोड़ दिया, और एक अलग सेवा के साथ संदेश दलाल को कवर करने का निर्णय उचित था। ऑपरेशन के वर्ष के दौरान, हमारे पास कोई गंभीर दुर्घटनाएं और समस्याएं नहीं थीं।

इस लेख के लिए शांत चित्रों के लिए, मेरी प्रेमिका, एकातेरिना ओबलीलेवा के लिए धन्यवाद। यदि आप उन्हें पसंद करते हैं, तो और भी अधिक चित्रण हैं।