संदेश दलाल समजून घेणे. ActiveMQ आणि Kafka सह मेसेजिंगचे यांत्रिकी शिकणे. धडा 3. काफ्का

एका छोट्या पुस्तकाच्या अनुवादाचा सिलसिला:
संदेश दलाल समजून घेणे
लेखक: जाकुब कोराब, प्रकाशक: O'Reilly Media, Inc., प्रकाशनाची तारीख: जून 2017, ISBN: 9781492049296.

मागील अनुवादित भाग: संदेश दलाल समजून घेणे. ActiveMQ आणि Kafka सह मेसेजिंगचे यांत्रिकी शिकणे. धडा 1 परिचय

अध्याय 3

काफका

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

हे अंतिम ध्येय लक्षात घेता, इतर आवश्यकता स्वाभाविकपणे उद्भवल्या. काफ्काने हे केले पाहिजे:

• अत्यंत वेगवान व्हा
• संदेशांसह कार्य करताना अधिक बँडविड्थ प्रदान करा
• प्रकाशक-सदस्य आणि पॉइंट-टू-पॉइंट मॉडेलला समर्थन द्या
• ग्राहक जोडण्यात गती कमी करू नका. उदाहरणार्थ, गंतव्यस्थानावरील ग्राहकांची संख्या वाढत असताना ActiveMQ मधील रांग आणि विषय या दोहोंचे कार्यप्रदर्शन कमी होते.
• क्षैतिज स्केलेबल व्हा; जर संदेश कायम ठेवणारा एक दलाल जास्तीत जास्त डिस्क वेगाने असे करू शकतो, तर कार्यप्रदर्शन वाढवण्यासाठी एका ब्रोकरच्या उदाहरणापेक्षा पुढे जाण्यात अर्थ आहे.
• संदेश संचयित करण्यासाठी आणि पुन्हा पुनर्प्राप्त करण्यासाठी प्रवेश मर्यादित करा

हे सर्व साध्य करण्यासाठी, काफ्काने क्लायंट आणि मेसेजिंग ब्रोकर्सच्या भूमिका आणि जबाबदाऱ्या पुन्हा परिभाषित करणारी एक वास्तुरचना स्वीकारली. JMS मॉडेल अत्यंत ब्रोकर ओरिएंटेड आहे, जेथे ब्रोकर संदेश वितरणासाठी जबाबदार असतो आणि क्लायंटला फक्त संदेश पाठवणे आणि प्राप्त करणे याबद्दल काळजी करावी लागते. काफ्का, दुसरीकडे, क्लायंट-केंद्रित आहे, क्लायंट पारंपारिक ब्रोकरची अनेक वैशिष्ट्ये घेतो, जसे की ग्राहकांना संबंधित संदेशांचे न्याय्य वितरण, अत्यंत जलद आणि स्केलेबल ब्रोकरच्या बदल्यात. पारंपारिक मेसेजिंग सिस्टीमसह काम केलेल्या लोकांसाठी, काफ्कासोबत काम करण्यासाठी मानसिक बदल आवश्यक आहे.
या अभियांत्रिकी दिग्दर्शनामुळे पारंपारिक ब्रोकरच्या तुलनेत अनेक ऑर्डर्सद्वारे थ्रूपुट वाढविण्यास सक्षम मेसेजिंग इन्फ्रास्ट्रक्चरची निर्मिती झाली आहे. जसे आपण पाहणार आहोत, हा दृष्टिकोन ट्रेड-ऑफसह येतो, याचा अर्थ काफ्का विशिष्ट प्रकारच्या वर्कलोड्स आणि स्थापित सॉफ्टवेअरसाठी योग्य नाही.

युनिफाइड डेस्टिनेशन मॉडेल

वर वर्णन केलेल्या आवश्यकतांची पूर्तता करण्यासाठी, काफ्काने प्रकाशन-सदस्यता आणि पॉइंट-टू-पॉइंट मेसेजिंग एका प्रकारच्या गंतव्यस्थानांतर्गत एकत्रित केले आहे - विषय. मेसेजिंग सिस्टमसह काम केलेल्या लोकांसाठी हे गोंधळात टाकणारे आहे, जिथे "विषय" हा शब्द प्रसारण यंत्रणेचा संदर्भ देतो ज्यातून (विषयावरून) वाचन टिकाऊ आहे. या पुस्तकाच्या प्रस्तावनेत परिभाषित केल्याप्रमाणे काफ्का विषयांना संकरित गंतव्य प्रकार मानले जावे.

या प्रकरणाच्या उर्वरित भागासाठी, जोपर्यंत आम्ही स्पष्टपणे अन्यथा नमूद करत नाही तोपर्यंत, "विषय" हा शब्द काफ्का विषयाला संदर्भित करेल.

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

"लॉग" आणि "पॉइंटर" हे शब्द दिसत नाहीत काफ्का दस्तऐवजीकरण. या सुप्रसिद्ध संज्ञा समजण्यास मदत करण्यासाठी येथे वापरल्या आहेत.

हे मॉडेल ActiveMQ पेक्षा पूर्णपणे वेगळे आहे, जिथे सर्व रांगेतील संदेश एकाच लॉगमध्ये संग्रहित केले जातात आणि ब्रोकर संदेश वाचल्यानंतर ते हटवलेले म्हणून चिन्हांकित करतात.
चला आता थोडं खोलवर जाऊ आणि विषयाचा लॉग अधिक तपशीलवार पाहू.
काफ्का लॉगमध्ये अनेक विभाजने असतात (आकृती 3-1). काफ्का प्रत्येक विभाजनात कडक ऑर्डरची हमी देतो. याचा अर्थ असा की एका विशिष्ट क्रमाने विभाजनाला लिहिलेले संदेश त्याच क्रमाने वाचले जातील. प्रत्येक विभाजन रोलिंग लॉग फाइल म्हणून लागू केले जाते ज्यामध्ये समाविष्ट आहे एक उपसंच (सबसेट) त्याच्या निर्मात्यांनी विषयावर पाठवलेल्या सर्व संदेशांचा. तयार केलेल्या विषयामध्ये डीफॉल्टनुसार, एक विभाजन आहे. क्षैतिज स्केलिंगसाठी विभाजनांची कल्पना ही काफ्काची मध्यवर्ती कल्पना आहे.

आकृती 3-1. काफ्का विभाजने

जेव्हा निर्माता काफ्का विषयाला संदेश पाठवतो तेव्हा तो संदेश कोणत्या विभाजनाला पाठवायचा हे ठरवतो. हे आपण नंतर अधिक तपशीलवार पाहू.

संदेश वाचत आहे

संदेश वाचू इच्छिणारा क्लायंट नावाचा पॉइंटर व्यवस्थापित करतो ग्राहक गट, जे निर्देश करते ऑफसेट विभाजनातील संदेश. ऑफसेट ही वाढीव स्थिती आहे जी विभाजनाच्या सुरूवातीस 0 पासून सुरू होते. वापरकर्ता-परिभाषित group_id द्वारे API मध्ये संदर्भित केलेला हा ग्राहक गट, त्याच्याशी संबंधित आहे एक तार्किक ग्राहक किंवा प्रणाली.

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

वाचनाची समस्या खालीलप्रमाणे दर्शविली जाऊ शकते:

• विषयाला अनेक विभाजने आहेत
• ग्राहकांचे अनेक गट एकाच वेळी विषय वापरू शकतात
• ग्राहकांच्या गटामध्ये अनेक स्वतंत्र उदाहरणे असू शकतात

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

ग्राहक आणि ग्राहक गट

चला प्रारंभ बिंदू म्हणून एका विभाजनासह विषय घेऊया (आकृती 3-2).

आकृती 3-2. विभाजनातून ग्राहक वाचतो

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

जेव्हा दुसरा तार्किक ग्राहक भिन्न group_id वापरून कनेक्ट करतो, तेव्हा तो दुसरा पॉइंटर व्यवस्थापित करतो जो पहिल्यापासून स्वतंत्र असतो (आकृती 3-3). अशा प्रकारे, काफ्का विषय एका रांगेप्रमाणे कार्य करतो जेथे एक ग्राहक असतो आणि सामान्य प्रकाशन-सदस्यत्व (पब-सब) विषयाप्रमाणे, ज्याचे अनेक ग्राहक सदस्यत्व घेतात, सर्व संदेश संग्रहित केले जातात आणि त्यावर अनेक वेळा प्रक्रिया केली जाऊ शकते.

आकृती 3-3. वेगवेगळ्या ग्राहक गटातील दोन ग्राहक एकाच विभाजनातून वाचतात

ग्राहक गटातील ग्राहक

जेव्हा एखादा उपभोक्ता विभाजनातील डेटा वाचतो तेव्हा त्याच्याकडे पॉइंटरचे पूर्ण नियंत्रण असते आणि मागील विभागात वर्णन केल्याप्रमाणे संदेशांवर प्रक्रिया करते.
जर एकाच ग्रुप_आयडीने एकाच विभाजनासह एका विषयाशी ग्राहकांची अनेक उदाहरणे जोडली गेली असतील, तर शेवटच्या कनेक्ट केलेल्या उदाहरणाला पॉइंटरवर नियंत्रण दिले जाईल आणि त्या क्षणापासून ते सर्व संदेश प्राप्त होतील (आकृती 3-4).

आकृती 3-4. एकाच ग्राहक गटातील दोन ग्राहक एकाच विभाजनातून वाचतात

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

वर वर्णन केलेले हे संदेश वितरण वर्तन सामान्य JMS रांग कसे वागते याच्या तुलनेत आश्चर्यकारक असू शकते. या मॉडेलमध्ये, रांगेत पाठवलेले संदेश दोन ग्राहकांमध्ये समान रीतीने वितरित केले जातील.

बर्‍याचदा, जेव्हा आम्ही उपभोक्त्यांची एकापेक्षा जास्त उदाहरणे तयार करतो, तेव्हा आम्ही संदेशांवर समांतर प्रक्रिया करण्यासाठी किंवा वाचनाचा वेग वाढवण्यासाठी किंवा वाचन प्रक्रियेची स्थिरता वाढवण्यासाठी असे करतो. एका वेळी फक्त एकच उपभोक्त्याचा प्रसंग विभाजनातून डेटा वाचू शकतो, काफ्कामध्ये हे कसे साध्य होते?

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

काफ्कामधील या समस्येचे निराकरण करण्याचा प्रामाणिक मार्ग म्हणजे बीОअधिक विभाजने.

विभाजन करणे

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

आकृती 3-5. एक ग्राहक अनेक विभाजनांमधून वाचतो

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

संदेशांची 20 थ्रेड्समध्ये समांतर प्रक्रिया केली जाते हे सुनिश्चित करण्यासाठी, तुम्हाला किमान 20 विभाजनांची आवश्यकता आहे. जर कमी विभाजने असतील, तर तुमच्याकडे असे ग्राहक राहतील ज्यांच्यावर काम करण्यासारखे काहीही नाही, जसे की अनन्य ग्राहकांच्या चर्चेत आधी वर्णन केले आहे.

आकृती 3-6. एकाच ग्राहक गटातील दोन ग्राहक वेगवेगळ्या विभाजनांमधून वाचतात

JMS रांग राखण्यासाठी आवश्यक असलेल्या संदेश वितरणाच्या तुलनेत ही योजना काफ्का ब्रोकरची जटिलता मोठ्या प्रमाणात कमी करते. येथे तुम्हाला खालील मुद्द्यांची काळजी करण्याची गरज नाही:

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

काफ्का ब्रोकरने ग्राहकांना विनंती केल्यावर त्यांना क्रमाने संदेश पाठवायचे असतात.

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

संदेश पाठवत आहे

कोणत्या विभाजनाला संदेश पाठवायचा हे ठरवण्याची जबाबदारी त्या संदेशाच्या निर्मात्याची असते. हे कोणत्या यंत्रणेद्वारे केले जाते हे समजून घेण्यासाठी, प्रथम आपण नेमके काय पाठवत आहोत याचा विचार करणे आवश्यक आहे.

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

धडा 2 मध्ये, आम्ही ऑनलाइन सट्टेबाजीच्या परिस्थितीवर चर्चा केली जेथे संबंधित इव्हेंट्सवर एकाच ग्राहकाद्वारे प्रक्रिया करणे आवश्यक आहे:

1. वापरकर्ता खाते कॉन्फिगर केले आहे.
2. खात्यात पैसे जमा होतात.
3. खात्यातून पैसे काढण्याची पैज लावली जाते.

जर प्रत्येक इव्हेंट एखाद्या विषयावर पोस्ट केलेला संदेश असेल, तर नैसर्गिक की खाते आयडी असेल.
जेव्हा काफ्का प्रोड्यूसर API वापरून संदेश पाठवला जातो, तेव्हा तो विभाजन फंक्शनला पाठवला जातो, जो संदेश आणि काफ्का क्लस्टरची सद्य स्थिती पाहता, ज्या विभाजनाला संदेश पाठवायचा आहे त्याचा आयडी देतो. हे वैशिष्ट्य जावामध्ये विभाजनकर्ता इंटरफेसद्वारे लागू केले जाते.

हा इंटरफेस यासारखा दिसतो:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

विभाजनकर्ता अंमलबजावणी विभाजन निश्चित करण्यासाठी की वर डीफॉल्ट सामान्य-उद्देश हॅशिंग अल्गोरिदम वापरते, किंवा कोणतीही की निर्दिष्ट केलेली नसल्यास राउंड-रॉबिन. हे डीफॉल्ट मूल्य बहुतेक प्रकरणांमध्ये चांगले कार्य करते. तथापि, भविष्यात तुम्हाला स्वतःचे लिहायचे असेल.

तुमची स्वतःची विभाजनाची रणनीती लिहित आहे

आपण मेसेज पेलोडसह मेटाडेटा पाठवू इच्छित असलेले उदाहरण पाहू. आमच्या उदाहरणातील पेलोड ही गेम खात्यात जमा करण्याची सूचना आहे. सूचना ही अशी एक गोष्ट आहे ज्याची आम्ही हमी देऊ इच्छितो की ट्रान्समिशनमध्ये सुधारणा केली जाणार नाही आणि खात्री करून घ्यायची आहे की केवळ एक विश्वासार्ह अपस्ट्रीम सिस्टम ही सूचना सुरू करू शकते. या प्रकरणात, पाठवणे आणि प्राप्त करणारी यंत्रणा संदेश प्रमाणित करण्यासाठी स्वाक्षरी वापरण्यास सहमत आहे.
सामान्य JMS मध्ये, आम्ही फक्त "संदेश स्वाक्षरी" गुणधर्म परिभाषित करतो आणि तो संदेशात जोडतो. तथापि, काफ्का आम्हाला मेटाडेटा पास करण्याची यंत्रणा देत नाही, फक्त एक कळ आणि मूल्य.

मूल्य हे बँक ट्रान्सफर पेलोड असल्याने ज्याची अखंडता आम्ही जतन करू इच्छितो, आमच्याकडे की वापरण्यासाठी डेटा संरचना परिभाषित करण्याशिवाय पर्याय नाही. असे गृहीत धरून की आम्हाला विभाजनासाठी खाते आयडीची आवश्यकता आहे, कारण खात्याशी संबंधित सर्व संदेशांवर क्रमाने प्रक्रिया करणे आवश्यक आहे, आम्ही खालील JSON रचना घेऊन येऊ:

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

पेलोडच्या आधारावर स्वाक्षरीचे मूल्य बदलत असल्याने, विभाजनकर्ता इंटरफेसची डिफॉल्ट हॅशिंग स्ट्रॅटेजी संबंधित संदेशांना विश्वासार्हपणे गटबद्ध करणार नाही. म्हणून, आम्हाला आमची स्वतःची रणनीती लिहावी लागेल जी ही की पार्स करेल आणि accountId मूल्याचे विभाजन करेल.

काफ्कामध्ये स्टोअरमधील संदेशांचे भ्रष्टाचार शोधण्यासाठी चेकसम समाविष्ट आहे आणि त्यात सुरक्षा वैशिष्ट्यांचा संपूर्ण संच आहे. तरीही, उद्योग-विशिष्ट आवश्यकता, जसे की वरीलप्रमाणे, कधीकधी दिसून येते.

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

एखाद्या विषयातील विभाजनांची संख्या कालांतराने बदलू शकते, कारण जर वाहतूक सुरुवातीच्या अपेक्षेपेक्षा जास्त असेल तर ते जोडले जाऊ शकतात. अशाप्रकारे, मेसेज की त्या विभाजनाशी निगडीत असू शकतात ज्याला ते मूलतः पाठवले गेले होते, जे निर्मात्याच्या उदाहरणांमध्ये सामायिक करण्यासाठी राज्याचा भाग सूचित करते.

विचार करण्याजोगा दुसरा घटक म्हणजे विभाजनांमध्ये संदेशांचे समान वितरण. सामान्यतः, की संदेशांमध्ये समान रीतीने वितरित केल्या जात नाहीत आणि हॅश फंक्शन्स कीच्या छोट्या संचासाठी संदेशांच्या योग्य वितरणाची हमी देत ​​​​नाही.
हे लक्षात घेणे महत्त्वाचे आहे की आपण संदेश विभाजित करणे निवडले असले तरी, विभाजक स्वतःच पुन्हा वापरण्याची आवश्यकता असू शकते.

वेगवेगळ्या भौगोलिक ठिकाणी काफ्का क्लस्टर्समधील डेटाची प्रतिकृती तयार करण्याची आवश्यकता विचारात घ्या. या उद्देशासाठी, काफ्का मिररमेकर नावाच्या कमांड लाइन टूलसह येतो, ज्याचा वापर एका क्लस्टरमधील संदेश वाचण्यासाठी आणि दुसर्‍या क्लस्टरमध्ये हस्तांतरित करण्यासाठी केला जातो.

क्लस्टर्समध्ये प्रतिकृती बनवताना संदेशांमधील सापेक्ष क्रम राखण्यासाठी मिररमेकरने प्रतिकृती केलेल्या विषयाच्या कळा समजून घेतल्या पाहिजेत, कारण त्या विषयासाठी विभाजनांची संख्या दोन क्लस्टरमध्ये समान असू शकत नाही.

सानुकूल विभाजन धोरणे तुलनेने दुर्मिळ आहेत, कारण डीफॉल्ट हॅशिंग किंवा राउंड रॉबिन बहुतेक परिस्थितींमध्ये चांगले कार्य करते. तथापि, जर तुम्हाला मजबूत ऑर्डरिंग गॅरंटी हवी असेल किंवा पेलोड्समधून मेटाडेटा काढण्याची आवश्यकता असेल, तर विभाजन करणे ही अशी गोष्ट आहे ज्याकडे तुम्ही बारकाईने पाहिले पाहिजे.

पारंपारिक ब्रोकरच्या काही जबाबदाऱ्या क्लायंटकडे हलवल्यामुळे काफ्काचे स्केलेबिलिटी आणि कामगिरीचे फायदे मिळतात. या प्रकरणात, समांतर काम करणाऱ्या अनेक ग्राहकांमध्ये संभाव्य संबंधित संदेश वितरीत करण्याचा निर्णय घेतला जातो.

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

उत्पादक करार

मेसेज पाठवताना केवळ विभाजनाचा विचार केला जात नाही. Java API मधील प्रोड्युसर क्लासच्या send() पद्धतींवर एक नजर टाकूया:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

नेहमीप्रमाणे, कामगिरीच्या खर्चावर पाठवा ऑपरेशन अधिक विश्वासार्ह बनविण्याचा एक मार्ग आहे. या बफरचा आकार 0 वर सेट केला जाऊ शकतो, आणि पाठवणाऱ्या ऍप्लिकेशन थ्रेडला ब्रोकरला मेसेज ट्रान्सफर पूर्ण होईपर्यंत प्रतीक्षा करण्यास भाग पाडले जाईल, खालीलप्रमाणे:

RecordMetadata metadata = producer.send(record).get();

संदेश वाचण्याबद्दल अधिक

संदेश वाचण्यात अतिरिक्त गुंतागुंत आहेत ज्यांचा अंदाज लावला जाणे आवश्यक आहे. JMS API च्या विपरीत, जे संदेशाच्या प्रतिसादात संदेश श्रोता चालवू शकते, द ग्राहक काफ्का फक्त मतदान करतो. चला पद्धत जवळून पाहू मतदान()या उद्देशासाठी वापरले:

ConsumerRecords < K, V > poll(long timeout);

पद्धतीचे रिटर्न व्हॅल्यू एक कंटेनर स्ट्रक्चर आहे ज्यामध्ये एकाधिक ऑब्जेक्ट्स आहेत ग्राहक रेकॉर्ड संभाव्य अनेक विभाजनांमधून. ग्राहक रेकॉर्ड संबंधित मेटाडेटासह की-व्हॅल्यू जोडीसाठी स्वतः एक धारक ऑब्जेक्ट आहे, जसे की विभाजन ज्यापासून ते प्राप्त केले जाते.

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

आम्ही म्हटल्याप्रमाणे, ग्राहक गट लॉगमधील ऑफसेटशी संबंधित आहे. या ऑफसेटशी संबंधित लॉग पोझिशन पुढील संदेशाच्या प्रतिसादात जारी केल्या जाणार्‍या संदेशाशी संबंधित आहे मतदान(). जेव्हा हा ऑफसेट वाढतो तेव्हाचा मुद्दा वाचण्यासाठी निर्णायक असतो.

आधी चर्चा केलेल्या वाचन मॉडेलकडे परत आल्यावर, संदेश प्रक्रियेत तीन टप्पे असतात:

1. वाचण्यासाठी संदेश पुनर्प्राप्त करा.
2. संदेशावर प्रक्रिया करा.
3. संदेशाची पुष्टी करा.

काफ्का ग्राहक कॉन्फिगरेशन पर्यायासह येतो enable.auto.commit. हे वारंवार वापरले जाणारे डीफॉल्ट सेटिंग आहे, जसे की "ऑटो" शब्द असलेल्या सेटिंग्जमध्ये सामान्य आहे.

काफ्का 0.10 च्या आधी, हा पर्याय वापरणारा क्लायंट पुढील कॉलवर वाचलेल्या शेवटच्या संदेशाचा ऑफसेट पाठवेल. मतदान() प्रक्रिया केल्यानंतर. याचा अर्थ असा होतो की क्लायंटने आधीच प्राप्त केलेले कोणतेही संदेश पुन्हा प्रक्रिया केले जाऊ शकतात परंतु कॉल करण्यापूर्वी ते अनपेक्षितपणे नष्ट झाले आहेत. मतदान(). ब्रोकर संदेश किती वेळा वाचला आहे याची कोणतीही स्थिती ठेवत नसल्यामुळे, तो संदेश पुनर्प्राप्त करणार्‍या पुढील ग्राहकाला काहीतरी वाईट झाले आहे हे कळणार नाही. हे वर्तन छद्म-व्यवहार होते. ऑफसेट केवळ संदेशावर यशस्वीरित्या प्रक्रिया केली गेली असेल तरच वचनबद्ध होते, परंतु क्लायंटने निरस्त केल्यास, ब्रोकर तोच संदेश दुसर्‍या क्लायंटला पुन्हा पाठवेल. हे वर्तन संदेश वितरण हमीशी सुसंगत होते "एकदा तरी".

काफ्का 0.10 मध्ये, क्लायंट कोड बदलला आहे जेणेकरून कॉन्फिगर केल्याप्रमाणे क्लायंट लायब्ररीद्वारे कमिट वेळोवेळी ट्रिगर केले जाईल. auto.commit.interval.ms. हे वर्तन JMS AUTO_ACKNOWLEDGE आणि DUPS_OK_ACKNOWLEDGE मोड दरम्यान कुठेतरी आहे. ऑटोकमिट वापरताना, संदेशांवर प्रत्यक्षात प्रक्रिया केली गेली आहे की नाही याची पर्वा न करता वचनबद्ध केले जाऊ शकते - हे धीमे ग्राहकांच्या बाबतीत होऊ शकते. जर एखाद्या ग्राहकाने निरस्त केले तर, वचनबद्ध स्थितीपासून सुरू होणारे संदेश पुढील ग्राहकाद्वारे प्राप्त केले जातील, ज्यामुळे संदेश मिस होऊ शकतो. या प्रकरणात, काफ्काने संदेश गमावले नाहीत, वाचन कोडने त्यांच्यावर प्रक्रिया केली नाही.

या मोडमध्ये आवृत्ती 0.9 प्रमाणेच वचन आहे: संदेशांवर प्रक्रिया केली जाऊ शकते, परंतु जर ते अयशस्वी झाले, तर ऑफसेट वचनबद्ध होऊ शकत नाही, ज्यामुळे वितरण दुप्पट होण्याची शक्यता आहे. कार्यान्वित करताना तुम्ही जितके अधिक संदेश आणता मतदान(), ही समस्या अधिक.

पृष्ठ 21 वर “रीडिंग मेसेजेस फ्रॉम अ क्यू” मध्ये चर्चा केल्याप्रमाणे, जेव्हा अपयश मोड विचारात घेतले जातात तेव्हा मेसेजिंग सिस्टममध्ये संदेशाचे एक-वेळ वितरण करण्यासारखे काहीही नाही.

काफ्कामध्ये, ऑफसेट (ऑफसेट) कमिट (कमिट) करण्याचे दोन मार्ग आहेत: आपोआप आणि स्वहस्ते. दोन्ही प्रकरणांमध्ये, संदेशावर प्रक्रिया केली गेली असेल परंतु कमिट करण्यापूर्वी अयशस्वी झाल्यास संदेशांवर अनेक वेळा प्रक्रिया केली जाऊ शकते. जर कमिट पार्श्वभूमीत घडले असेल आणि तुमचा कोड त्यावर प्रक्रिया होण्यापूर्वी पूर्ण झाला असेल (कदाचित काफ्का ०.९ आणि त्यापूर्वी) तुम्ही संदेशावर प्रक्रिया न करणे देखील निवडू शकता.

तुम्ही पॅरामीटर सेट करून काफ्का ग्राहक API मध्ये मॅन्युअल ऑफसेट कमिट प्रक्रिया नियंत्रित करू शकता enable.auto.commit खालीलपैकी एक पद्धत खोटे आणि स्पष्टपणे कॉल करणे:

void commitSync();
void commitAsync();

जर तुम्हाला "किमान एकदा" मेसेजवर प्रक्रिया करायची असेल, तर तुम्ही मॅन्युअली ऑफसेट कमिट केले पाहिजे कमिट सिंक()संदेशांवर प्रक्रिया केल्यानंतर लगेच ही आज्ञा कार्यान्वित करून.

या पद्धती संदेशांवर प्रक्रिया होण्यापूर्वी ते स्वीकारण्याची परवानगी देत ​​​​नाहीत, परंतु ते व्यवहारी असल्याचा देखावा देत संभाव्य प्रक्रिया विलंब दूर करण्यासाठी काहीही करत नाहीत. काफ्कामध्ये कोणतेही व्यवहार नाहीत. क्लायंटकडे खालील गोष्टी करण्याची क्षमता नाही:

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

जर आम्ही व्यवहारांवर विसंबून राहू शकत नाही, तर पारंपारिक मेसेजिंग सिस्टीमद्वारे प्रदान केलेल्या शब्दांच्या जवळ शब्दार्थ कसे प्रदान करू शकतो?

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

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

पद्धत शोधा() पद्धतीने वापरता येते
offsetsForTimes(नकाशा टाइमस्टँपशोध) भूतकाळातील काही विशिष्ट टप्प्यावर एखाद्या स्थितीकडे परत जाण्यासाठी.

स्पष्टपणे, हा दृष्टिकोन वापरण्याचा अर्थ असा आहे की पूर्वी प्रक्रिया केलेले काही संदेश वाचले जातील आणि पुन्हा प्रक्रिया केली जाण्याची शक्यता आहे. हे टाळण्यासाठी, आम्ही आधी पाहिलेल्या संदेशांचा मागोवा ठेवण्यासाठी आणि डुप्लिकेट काढून टाकण्यासाठी, धडा 4 मध्ये वर्णन केल्याप्रमाणे, अदम्य वाचन वापरू शकतो.

वैकल्पिकरित्या, जोपर्यंत संदेश गमावणे किंवा डुप्लिकेशन स्वीकार्य आहे तोपर्यंत तुमचा ग्राहक कोड साधा ठेवला जाऊ शकतो. लॉग इव्हेंट, मेट्रिक्स, क्लिक ट्रॅकिंग इ. हाताळणे यासारख्या काफ्का सामान्यतः वापरल्या जाणार्‍या प्रकरणांचा आम्ही विचार करतो तेव्हा, आम्हाला समजते की वैयक्तिक संदेश गमावल्याने आसपासच्या अनुप्रयोगांवर लक्षणीय परिणाम होण्याची शक्यता नाही. अशा प्रकरणांमध्ये, डीफॉल्ट मूल्ये पूर्णपणे स्वीकार्य आहेत. दुसरीकडे, तुमच्या अर्जाला देयके पाठवायची असल्यास, तुम्ही प्रत्येक वैयक्तिक संदेशाची काळजीपूर्वक काळजी घेतली पाहिजे. हे सर्व संदर्भानुसार येते.

वैयक्तिक निरीक्षणे दर्शवितात की संदेशांची तीव्रता जसजशी वाढते तसतसे प्रत्येक वैयक्तिक संदेशाचे मूल्य कमी होते. जेव्हा एकत्रित स्वरूपात पाहिले जाते तेव्हा मोठे संदेश मौल्यवान असतात.

उच्च उपलब्धता

उच्च उपलब्धतेसाठी काफ्काचा दृष्टिकोन ActiveMQ च्या दृष्टिकोनापेक्षा खूप वेगळा आहे. काफ्का स्केल-आउट क्लस्टर्सच्या आसपास डिझाइन केलेले आहे जेथे सर्व ब्रोकर उदाहरणे एकाच वेळी संदेश प्राप्त करतात आणि वितरित करतात.

काफ्का क्लस्टरमध्ये वेगवेगळ्या सर्व्हरवर चालणाऱ्या अनेक ब्रोकर घटनांचा समावेश असतो. काफ्का सामान्य स्टँडअलोन हार्डवेअरवर चालण्यासाठी डिझाइन केले होते, जेथे प्रत्येक नोडचे स्वतःचे समर्पित स्टोरेज असते. नेटवर्क संलग्न स्टोरेज (SAN) वापरण्याची शिफारस केलेली नाही कारण एकाधिक संगणक नोड्स वेळेसाठी स्पर्धा करू शकतात.Ыe स्टोरेज अंतराल आणि संघर्ष निर्माण.

काफ्का आहे नेहमी सुरू प्रणाली बरेच मोठे काफ्का वापरकर्ते त्यांचे क्लस्टर कधीही बंद करत नाहीत आणि सॉफ्टवेअर नेहमी अनुक्रमिक रीस्टार्टसह अद्यतनित होते. ब्रोकर्समधील संदेश आणि परस्परसंवादासाठी मागील आवृत्तीशी सुसंगततेची हमी देऊन हे साध्य केले जाते.

सर्व्हर क्लस्टरशी जोडलेले दलाल झूकीपर, जे कॉन्फिगरेशन डेटा रेजिस्ट्री म्हणून कार्य करते आणि प्रत्येक ब्रोकरच्या भूमिका समन्वयित करण्यासाठी वापरले जाते. ZooKeeper स्वतः एक वितरित प्रणाली आहे जी स्थापन करून माहितीच्या प्रतिकृतीद्वारे उच्च उपलब्धता प्रदान करते कोरम.

बेस केसमध्ये, खालील गुणधर्मांसह काफ्का क्लस्टरमध्ये एक विषय तयार केला जातो:

• विभाजनांची संख्या. आधी चर्चा केल्याप्रमाणे, येथे वापरलेले अचूक मूल्य समांतर वाचनाच्या इच्छित स्तरावर अवलंबून असते.
• प्रतिकृती घटक (घटक) क्लस्टरमधील किती ब्रोकर उदाहरणांमध्ये या विभाजनासाठी लॉग असावेत हे निर्धारित करते.

समन्वयासाठी ZooKeepers चा वापर करून, काफ्का क्लस्टरमधील ब्रोकर्समध्ये नवीन विभाजने योग्यरित्या वितरित करण्याचा प्रयत्न करतो. हे एका उदाहरणाद्वारे केले जाते जे नियंत्रक म्हणून कार्य करते.

धावण्याच्या वेळी प्रत्येक विषय विभाजनासाठी नियंत्रक ब्रोकरला भूमिका नियुक्त करा नेता (नेता, मास्टर, प्रस्तुतकर्ता) आणि अनुयायी (अनुयायी, गुलाम, अधीनस्थ). ब्रोकर, या विभाजनासाठी नेता म्हणून काम करत आहे, निर्मात्यांनी त्याला पाठवलेले सर्व संदेश प्राप्त करणे आणि ग्राहकांना संदेश वितरित करणे यासाठी जबाबदार आहे. जेव्हा विषय विभाजनाला संदेश पाठवले जातात, तेव्हा ते त्या विभाजनाचे अनुयायी म्हणून काम करणाऱ्या सर्व ब्रोकर नोड्सवर प्रतिरूपित केले जातात. विभाजनासाठी लॉग असलेल्या प्रत्येक नोडला म्हणतात प्रतिकृती. ब्रोकर काही विभाजनांसाठी नेता म्हणून आणि इतरांसाठी अनुयायी म्हणून काम करू शकतो.

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

उत्पादक कॉन्फिगरेशनचा भाग पॅरामीटर आहे acks, जे ऍप्लिकेशन थ्रेड पाठवणे सुरू ठेवण्यापूर्वी किती प्रतिकृतींनी संदेशाची पावती (पोच पावती) दिली पाहिजे हे निर्धारित करते: 0, 1, किंवा सर्व. वर सेट केल्यास सर्व, नंतर संदेश प्राप्त झाल्यावर, विषय सेटिंगद्वारे परिभाषित केलेल्या अनेक संकेतांमधून (स्वतःसह) रेकॉर्डची पुष्टी (पोचती) प्राप्त होताच नेता निर्मात्याला पुष्टीकरण पाठवेल. min.insync.replicas (डिफॉल्ट 1). जर संदेशाची प्रतिकृती यशस्वीरित्या तयार केली जाऊ शकत नसेल, तर निर्माता अनुप्रयोग अपवाद टाकेल (NotEnoughReplicas किंवा NotEnoughReplicasAfterAppend).

ठराविक कॉन्फिगरेशन 3 च्या प्रतिकृती घटकासह एक विषय तयार करते (1 नेता, 2 अनुयायी प्रत्येक विभाजन) आणि पॅरामीटर min.insync.replicas 2 वर सेट केले आहे. या प्रकरणात, क्लस्टर विषय विभाजन व्यवस्थापित करणार्‍या ब्रोकरपैकी एकास क्लायंट ऍप्लिकेशन्सवर परिणाम न करता खाली जाण्याची परवानगी देईल.

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

या प्रतिकृती योजनेचा वापर करून, काफ्का चतुराईने ऑपरेशनसह डिस्कवर प्रत्येक संदेश भौतिकरित्या लिहिण्याची गरज टाळतो. सिंक(). निर्मात्याने पाठवलेला प्रत्येक संदेश विभाजन लॉगवर लिहिला जाईल, परंतु धडा 2 मध्ये चर्चा केल्याप्रमाणे, फाइलवर लिहिणे सुरुवातीला ऑपरेटिंग सिस्टमच्या बफरमध्ये केले जाते. जर हा संदेश दुसर्‍या काफ्का उदाहरणावर प्रतिरूपित केला गेला असेल आणि त्याच्या स्मरणात असेल, तर नेत्याच्या नुकसानाचा अर्थ असा नाही की संदेश स्वतःच हरवला आहे - तो सिंक्रोनाइझ केलेल्या प्रतिकृतीद्वारे ताब्यात घेतला जाऊ शकतो.
ऑपरेशन करण्यास नकार सिंक() म्हणजे काफ्का मेमरीमध्ये जितक्या वेगाने संदेश लिहू शकतो तितक्या वेगाने तो प्राप्त करू शकतो. याउलट, डिस्कवर मेमरी फ्लश करणे तुम्ही जितके जास्त वेळ टाळू शकता तितके चांगले. या कारणास्तव, काफ्का ब्रोकर्सना 64 GB किंवा त्याहून अधिक मेमरी वाटप करणे असामान्य नाही. या मेमरी वापराचा अर्थ असा आहे की एकच काफ्का उदाहरण पारंपारिक संदेश ब्रोकरपेक्षा हजारो पट वेगाने सहज धावू शकते.

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

एकाच काफ्का ब्रोकरच्या तुलनेत काफ्का क्लस्टरमध्ये अधिक चांगली कामगिरी शक्य आहे, कारण विषय विभाजने अनेक स्वतंत्र मशीनवर मोजली जाऊ शकतात.

परिणाम

या प्रकरणात, आम्ही काफ्का आर्किटेक्चर क्लायंट आणि ब्रोकर यांच्यातील नातेसंबंधाची पुनर्कल्पना कशी करते हे पाहिले, एक अविश्वसनीयपणे मजबूत मेसेजिंग पाइपलाइन प्रदान करण्यासाठी, पारंपरिक संदेश ब्रोकरच्या थ्रूपुटपेक्षा कितीतरी पटीने जास्त. आम्ही हे साध्य करण्यासाठी वापरल्या जाणार्‍या कार्यक्षमतेची चर्चा केली आहे आणि ही कार्यक्षमता प्रदान करणार्‍या अनुप्रयोगांच्या आर्किटेक्चरकडे थोडक्यात पाहिले आहे. पुढील प्रकरणामध्ये, आम्ही संदेशन-आधारित ऍप्लिकेशन्सना सोडवण्यासाठी आवश्यक असलेल्या सामान्य समस्या पाहू आणि त्यांना हाताळण्यासाठी धोरणांवर चर्चा करू. सर्वसाधारणपणे मेसेजिंग तंत्रज्ञानाबद्दल कसे बोलावे ते सांगून आम्ही धडा संपवू जेणेकरुन तुम्ही तुमच्या वापराच्या प्रकरणांसाठी त्यांच्या योग्यतेचे मूल्यांकन करू शकाल.

मागील अनुवादित भाग: संदेश दलाल समजून घेणे. ActiveMQ आणि Kafka सह मेसेजिंगचे यांत्रिकी शिकणे. धडा १

भाषांतर पूर्ण झाले: tele.gg/middle_java

पुढे चालू…

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

काफ्का तुमच्या संस्थेत वापरला जातो का?

• होय

• कोणत्याही

• पूर्वी वापरले होते, आता नाही

• आम्ही वापरण्याची योजना आखत आहोत

38 वापरकर्त्यांनी मतदान केले. 8 वापरकर्ते दूर राहिले.

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