सन्देश दलालहरू बुझ्दै। ActiveMQ र Kafka को साथ सन्देश को मेकानिक्स सिक्दै। अध्याय 3. काफ्का

एउटा सानो पुस्तकको अनुवादको निरन्तरता:
सन्देश ब्रोकरहरू बुझ्दै
लेखक: Jakub Korab, प्रकाशक: O'Reilly Media, Inc., प्रकाशन मिति: जुन 2017, ISBN: 9781492049296।

अघिल्लो अनुवादित भाग: सन्देश दलालहरू बुझ्दै। ActiveMQ र Kafka को साथ सन्देश को मेकानिक्स सिक्दै। अध्याय १ परिचय

अध्याय ३

काफका

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

यो अन्तिम लक्ष्यलाई ध्यानमा राख्दै, अन्य आवश्यकताहरू स्वाभाविक रूपमा देखा पर्‍यो। काफ्काले गर्नुपर्छ:

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

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

एकीकृत गन्तव्य मोडेल

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

यस अध्यायको बाँकीको लागि, जबसम्म हामीले स्पष्ट रूपमा अन्यथा उल्लेख गर्दैनौं, "विषय" शब्दले काफ्का विषयलाई जनाउनेछ।

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

सर्तहरू "लग" र "सूचक" देखा पर्दैन काफ्का दस्तावेज। यी ज्ञात शब्दहरू यहाँ बुझ्न मद्दत गर्न प्रयोग गरिन्छ।

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

चित्र ३-१। काफ्का विभाजनहरू

जब निर्माताले काफ्का विषयलाई सन्देश पठाउँछन्, यसले कुन विभाजनलाई सन्देश पठाउने निर्णय गर्दछ। हामी यसलाई पछि थप विस्तारमा हेर्नेछौं।

सन्देशहरू पढ्दै

सन्देशहरू पढ्न चाहने ग्राहकले नाम दिइएको सूचक व्यवस्थापन गर्दछ उपभोक्ता समूह, जसले इंगित गर्दछ अफसेट विभाजनमा सन्देशहरू। अफसेट एक वृद्धिशील स्थिति हो जुन विभाजनको सुरुमा ० मा सुरु हुन्छ। प्रयोगकर्ता-परिभाषित group_id मार्फत API मा सन्दर्भ गरिएको यो उपभोक्ता समूह, सँग मेल खान्छ एक तार्किक उपभोक्ता वा प्रणाली.

धेरै जसो सन्देश प्रणालीहरूले समानान्तरमा सन्देशहरू प्रशोधन गर्न धेरै उदाहरणहरू र थ्रेडहरू प्रयोग गरेर गन्तव्यबाट डाटा पढ्छन्। यसरी, त्यहाँ सामान्यतया धेरै उपभोक्ता उदाहरणहरू समान उपभोक्ता समूह साझा हुनेछन्।

पढाइको समस्या निम्न रूपमा प्रतिनिधित्व गर्न सकिन्छ:

• विषयको धेरै विभाजनहरू छन्
• उपभोक्ताहरूको बहु समूहहरूले एकै समयमा विषय प्रयोग गर्न सक्छन्
• उपभोक्ताहरूको समूहसँग धेरै अलग-अलग उदाहरणहरू हुन सक्छन्

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

उपभोक्ता र उपभोक्ता समूह

एक विभाजनको साथ एक विषयलाई सुरूवात बिन्दुको रूपमा लिनुहोस् (चित्र १.3-।).

चित्र ३-२। उपभोक्ता विभाजनबाट पढ्छन्

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

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

चित्र ३-३। विभिन्न उपभोक्ता समूहका दुई उपभोक्ताहरू एउटै विभाजनबाट पढ्छन्

उपभोक्ता समूहमा उपभोक्ताहरू

जब एक उपभोक्ता उदाहरणले विभाजनबाट डाटा पढ्छ, यसमा पोइन्टरको पूर्ण नियन्त्रण हुन्छ र अघिल्लो खण्डमा वर्णन गरिए अनुसार सन्देशहरू प्रशोधन गर्दछ।
यदि उपभोक्ताहरूको धेरै उदाहरणहरू एउटै समूह_आईडीसँग एउटै विभाजनको साथ एक शीर्षकमा जडान गरिएको थियो भने, अन्तिममा जडान भएको उदाहरणलाई पोइन्टरमा नियन्त्रण दिइनेछ र त्यस क्षणबाट यसले सबै सन्देशहरू प्राप्त गर्नेछ (चित्र १.3-।).

चित्र ३-४। एउटै उपभोक्ता समूहका दुई उपभोक्ताहरू एउटै विभाजनबाट पढ्छन्

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

माथि वर्णन गरिएको यो सन्देश वितरण व्यवहार सामान्य JMS लामले व्यवहार गर्ने तरिकाको तुलनामा आश्चर्यजनक हुन सक्छ। यस मोडेलमा, लाममा पठाइएका सन्देशहरू दुई उपभोक्ताहरू बीच समान रूपमा वितरण गरिनेछ।

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

यो गर्ने एउटा तरिका भनेको सबै सन्देशहरू पढ्न र थ्रेड पूलमा पास गर्न एकल उपभोक्ता उदाहरण प्रयोग गर्नु हो। जबकि यो दृष्टिकोणले प्रशोधन थ्रुपुट बढाउँछ, यसले उपभोक्ता तर्कको जटिलता बढाउँछ र पठन प्रणालीको बलियोता बढाउन केही गर्दैन। यदि उपभोक्ताको एक प्रतिलिपि पावर विफलता वा समान घटनाको कारणले घट्यो भने, घटाउ रोकिन्छ।

काफ्कामा यस समस्याको समाधान गर्ने क्यानोनिकल तरिका बी प्रयोग गर्नु होОथप विभाजनहरू।

विभाजन

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

चित्र ३-५। एक उपभोक्ताले धेरै विभाजनबाट पढ्छ

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

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

चित्र ३-६। एउटै उपभोक्ता समूहका दुई उपभोक्ताहरू फरक-फरक विभाजनबाट पढ्छन्

JMS लाम कायम राख्न आवश्यक सन्देश वितरणको तुलनामा यो योजनाले काफ्का ब्रोकरको जटिलतालाई धेरै कम गर्छ। यहाँ तपाईंले निम्न बिन्दुहरूको बारेमा चिन्ता गर्नुपर्दैन:

• कुन उपभोक्ताले अर्को सन्देश प्राप्त गर्नुपर्छ, राउन्ड-रोबिन विनियोजन, प्रिफेच बफरहरूको हालको क्षमता, वा अघिल्लो सन्देशहरू (JMS सन्देश समूहहरूको लागि)।
• कुन सन्देशहरू कुन उपभोक्ताहरूलाई पठाइन्छ र तिनीहरू असफल भएमा पुन: डेलिभर गरिनुपर्छ।

सबै काफ्का ब्रोकरले उपभोक्तालाई अनुरोध गर्दा सन्देशहरू क्रमशः पठाउनु पर्छ।

यद्यपि, प्रूफरीडिङलाई समानान्तर बनाउन र असफल सन्देशहरू पुन: पठाउने आवश्यकताहरू हट्दैनन् - तिनीहरूको लागि जिम्मेवारी केवल ब्रोकरबाट ग्राहकमा जान्छ। यसको मतलब यो हो कि तिनीहरू तपाईंको कोडमा खातामा लिनु पर्छ।

सन्देशहरू पठाउँदै

कुन विभाजनलाई सन्देश पठाउने निर्णय गर्ने त्यो सन्देशको निर्माताको जिम्मेवारी हो। यो गर्ने मेकानिजम बुझ्नको लागि, हामीले वास्तवमा वास्तवमा के पठाउँदैछौं भनेर विचार गर्न आवश्यक छ।

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

अध्याय 2 मा, हामीले अनलाइन सट्टेबाजी परिदृश्यको बारेमा छलफल गर्यौं जहाँ सम्बन्धित घटनाहरू एकल उपभोक्ताद्वारा प्रशोधन गर्न आवश्यक छ:

1. प्रयोगकर्ता खाता कन्फिगर गरिएको छ।
2. खातामा पैसा जम्मा हुन्छ।
3. एक शर्त बनाइन्छ कि खाताबाट पैसा निकाल्छ।

यदि प्रत्येक घटना एक शीर्षकमा पोस्ट गरिएको सन्देश हो भने, प्राकृतिक कुञ्जी खाता ID हुनेछ।
जब सन्देश Kafka Producer API को प्रयोग गरेर पठाइन्छ, यसलाई विभाजन प्रकार्यमा पठाइन्छ जसले सन्देश र काफ्का क्लस्टरको हालको अवस्थालाई दिएर, सन्देश पठाउनु पर्ने विभाजनको ID फर्काउँछ। यो सुविधा जाभामा विभाजनकर्ता इन्टरफेस मार्फत लागू गरिएको छ।

यो इन्टरफेस यस्तो देखिन्छ:

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

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

तपाईंको आफ्नै विभाजन रणनीति लेख्दै

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

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

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

किनभने हस्ताक्षरको मान पेलोडको आधारमा भिन्न हुनेछ, विभाजनकर्ता इन्टरफेसको पूर्वनिर्धारित ह्यासिङ रणनीतिले सम्बन्धित सन्देशहरूलाई विश्वसनीय रूपमा समूहबद्ध गर्दैन। त्यसकारण, हामीले हाम्रो आफ्नै रणनीति लेख्न आवश्यक छ जसले यो कुञ्जीलाई पार्स गर्नेछ र accountId मान विभाजन गर्नेछ।

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

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

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

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

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

मिररमेकरले क्लस्टरहरू बीचको प्रतिलिपि बनाउँदा सन्देशहरू बीचको सापेक्षिक क्रम कायम राख्नको लागि प्रतिलिपि गरिएको विषयको कुञ्जीहरू बुझ्नुपर्छ, किनभने त्यो विषयको विभाजनहरूको संख्या दुई क्लस्टरहरूमा समान नहुन सक्छ।

अनुकूलन विभाजन रणनीतिहरू अपेक्षाकृत दुर्लभ छन्, पूर्वनिर्धारित ह्यासिङ वा राउन्ड रोबिनले धेरै परिदृश्यहरूमा राम्रोसँग काम गर्दछ। यद्यपि, यदि तपाईंलाई बलियो अर्डर ग्यारेन्टीहरू चाहिन्छ वा पेलोडहरूबाट मेटाडेटा निकाल्न आवश्यक छ भने, विभाजन भनेको तपाईंले नजिकबाट हेर्नु पर्ने कुरा हो।

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

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

निर्माता सम्झौताहरू

सन्देशहरू पठाउँदा विचार गर्नुपर्ने कुरा विभाजन मात्र होइन। जाभा एपीआईमा निर्माता वर्गको send() विधिहरू हेरौं:

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

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

सधैंको रूपमा, प्रदर्शनको लागतमा पठाउने अपरेशनलाई थप विश्वसनीय बनाउने तरिका छ। यस बफरको साइज ० मा सेट गर्न सकिन्छ, र पठाउने एप्लिकेसन थ्रेडलाई ब्रोकरमा सन्देश स्थानान्तरण पूरा नभएसम्म पर्खन बाध्य गरिनेछ, निम्नानुसार:

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

सन्देशहरू पढ्ने बारे थप

पठन सन्देशहरूमा थप जटिलताहरू छन् जसको बारेमा अनुमान गर्न आवश्यक छ। JMS API को विपरीत, जसले सन्देशको प्रतिक्रियामा सन्देश श्रोता चलाउन सक्छ, उपभोक्ता काफ्काले मात्र मतदान गरे। विधिलाई नजिकबाट हेरौं मतदान()यस उद्देश्यको लागि प्रयोग गरिन्छ:

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

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

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

हामीले भनेझैं, उपभोक्ता समूह लगमा अफसेटसँग सम्बन्धित छ। यस अफसेटसँग सम्बन्धित लग स्थिति प्रतिक्रियामा जारी गरिने अर्को सन्देशसँग मेल खान्छ मतदान()। यो अफसेट बढ्दा समयको बिन्दु पढ्नको लागि निर्णायक हुन्छ।

पहिले छलफल गरिएको पठन मोडेलमा फर्केर, सन्देश प्रशोधनमा तीन चरणहरू हुन्छन्:

1. पढ्नको लागि सन्देश पुन: प्राप्त गर्नुहोस्।
2. सन्देश प्रशोधन गर्नुहोस्।
3. सन्देश पुष्टि गर्नुहोस्।

काफ्का उपभोक्ता कन्फिगरेसन विकल्पको साथ आउँछ enable.auto.commit। यो प्रायः प्रयोग गरिने पूर्वनिर्धारित सेटिङ हो, जस्तै "स्वतः" शब्द भएको सेटिङहरूमा सामान्य हुन्छ।

काफ्का ०.१० भन्दा पहिले, यो विकल्प प्रयोग गर्ने ग्राहकले अर्को कलमा पढेको अन्तिम सन्देशको अफसेट पठाउनेछ। मतदान() प्रशोधन पछि। यसको मतलब पहिले नै ल्याइएका कुनै पनि सन्देशहरू पुन: प्रशोधन गर्न सकिन्छ यदि ग्राहकले तिनीहरूलाई पहिले नै प्रशोधन गरेको थियो तर कल गर्नु अघि अप्रत्याशित रूपमा नष्ट भएको थियो। मतदान()। किनकी ब्रोकरले सन्देश कति पटक पढियो भन्ने बारे कुनै अवस्था राख्दैन, अर्को उपभोक्ता जसले त्यो सन्देश पुन: प्राप्त गर्छ उसलाई थाहा हुँदैन केहि खराब भयो। यो व्यवहार छद्म लेनदेन थियो। अफसेट मात्र प्रतिबद्ध थियो यदि सन्देश सफलतापूर्वक प्रशोधन गरिएको थियो, तर यदि ग्राहकले रद्द गर्यो भने, ब्रोकरले अर्को ग्राहकलाई उही सन्देश फेरि पठाउनेछ। यो व्यवहार सन्देश वितरण ग्यारेन्टी संग संगत थियो "कम्तिमा एक पटक"।

Kafka 0.10 मा, क्लाइन्ट कोड परिवर्तन गरिएको छ ताकि कमिट ग्राहक पुस्तकालय द्वारा आवधिक रूपमा ट्रिगर हुन्छ, कन्फिगर गरिएको रूपमा। auto.commit.interval.ms। यो व्यवहार JMS AUTO_ACKNOWLEDGE र DUPS_OK_ACKNOWLEDGE मोडहरू बीच कतै छ। स्वत: कमिट प्रयोग गर्दा, सन्देशहरू वास्तवमा प्रशोधन गरिएको भए तापनि प्रतिबद्ध हुन सक्छ - यो ढिलो उपभोक्ताको मामलामा हुन सक्छ। यदि एक उपभोक्ताले परित्याग गर्यो भने, सन्देशहरू अर्को उपभोक्ताद्वारा ल्याइनेछ, प्रतिबद्ध स्थितिबाट सुरु हुन्छ, जसले सन्देश छुटेको हुन सक्छ। यस अवस्थामा, काफ्काले सन्देशहरू गुमाएनन्, पढ्ने कोडले मात्र तिनीहरूलाई प्रशोधन गरेन।

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

पृष्ठ २१ मा "रीडिङ मेसेज फ्रॉम ए क्यु" मा छलफल गरिएझैं, विफलता मोडहरूलाई ध्यानमा राख्दा सन्देश प्रणालीमा सन्देशको एक पटकको डेलिभरी जस्तो कुनै चीज छैन।

काफ्कामा, अफसेट (अफसेट) कमिट (कमिट) गर्ने दुई तरिकाहरू छन्: स्वचालित र म्यानुअल रूपमा। दुबै अवस्थामा, सन्देशहरू धेरै पटक प्रशोधन गर्न सकिन्छ यदि सन्देश प्रशोधन गरिएको थियो तर प्रतिबद्ध हुनु अघि असफल भयो। यदि कमिट पृष्ठभूमिमा भएको हो र तपाइँको कोडलाई प्रशोधन गर्न सक्नु अघि नै (सायद काफ्का ०.९ र पहिलेमा) पूरा भयो भने तपाइँ सन्देशलाई प्रक्रिया नगर्ने छनौट गर्न सक्नुहुन्छ।

तपाईं प्यारामिटर सेट गरेर काफ्का उपभोक्ता 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 मा वर्णन गरिए अनुसार, पहिले हेरिएका सन्देशहरूको ट्र्याक राख्न र नक्कलहरू हटाउनको लागि हामी idempotent पठन प्रयोग गर्न सक्छौं।

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

व्यक्तिगत अवलोकनहरूले देखाउँछन् कि सन्देशहरूको तीव्रता बढ्दै जाँदा प्रत्येक व्यक्तिगत सन्देशको मूल्य घट्दै जान्छ। ठूला सन्देशहरू समग्र रूपमा हेर्दा मूल्यवान हुन्छन्।

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

उच्च उपलब्धताको लागि काफ्काको दृष्टिकोण ActiveMQ को दृष्टिकोण भन्दा धेरै फरक छ। काफ्का स्केल-आउट क्लस्टरहरू वरिपरि डिजाइन गरिएको छ जहाँ सबै ब्रोकर उदाहरणहरूले एकै समयमा सन्देशहरू प्राप्त र वितरण गर्छन्।

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

काफ्का हुन् सधैं प्रणाली। धेरै ठूला काफ्का प्रयोगकर्ताहरूले उनीहरूको क्लस्टरहरू कहिल्यै बन्द गर्दैनन् र सफ्टवेयर सधैं क्रमिक पुन: सुरुको साथ अद्यावधिक हुन्छ। यो सन्देशहरू र दलालहरू बीच अन्तरक्रियाहरूको लागि अघिल्लो संस्करण संग अनुकूलता ग्यारेन्टी गरेर हासिल गरिएको छ।

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

आधार केसमा, काफ्का क्लस्टरमा निम्न गुणहरूसँग एउटा विषय सिर्जना गरिएको छ:

• विभाजनहरूको संख्या। पहिले छलफल गरिए अनुसार, यहाँ प्रयोग गरिएको सही मान समानान्तर पढाइको इच्छित स्तरमा निर्भर गर्दछ।
• प्रतिकृति कारक (कारक) ले क्लस्टरमा कति दलाल उदाहरणहरू यो विभाजनको लागि लगहरू समावेश गर्नुपर्छ निर्धारण गर्दछ।

समन्वयका लागि ZooKeepers प्रयोग गरेर, काफ्काले क्लस्टरमा दलालहरू बीच नयाँ विभाजनहरू निष्पक्ष रूपमा वितरण गर्ने प्रयास गर्छन्। यो एकल उदाहरण द्वारा गरिन्छ जुन नियन्त्रकको रूपमा कार्य गर्दछ।

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

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

निर्माता कन्फिगरेसनको अंश प्यारामिटर हो acks, जसले एप्लिकेसन थ्रेडले पठाउन जारी राख्नु अघि सन्देशको कति प्रतिकृतिहरू स्वीकार गर्नुपर्छ (स्वीकार गर्नुपर्छ) निर्धारण गर्दछ: 0, 1, वा सबै। यदि सेट गर्नुहोस् सबै, त्यसपछि जब सन्देश प्राप्त हुन्छ, नेताले विषय सेटिङद्वारा परिभाषित धेरै संकेतहरू (आफै सहित) बाट रेकर्डको पुष्टिकरणहरू (स्वीकृतिहरू) प्राप्त गर्ने बित्तिकै निर्मातालाई पुष्टिकरण पठाउनेछ। min.insync.replicas (पूर्वनिर्धारित १)। यदि सन्देश सफलतापूर्वक नक्कल गर्न सकिँदैन भने, निर्माताले अनुप्रयोग अपवाद (NotEnoughReplicas वा NotEnoughReplicasAfterAppend).

एक सामान्य कन्फिगरेसनले 3 को प्रतिकृति कारक (1 नेता, 2 अनुयायी प्रति विभाजन) र प्यारामिटरको साथ एक विषय सिर्जना गर्दछ। min.insync.replicas 2 मा सेट गरिएको छ। यस अवस्थामा, क्लस्टरले विषय विभाजन प्रबन्ध गर्ने दलालहरू मध्ये एकलाई ग्राहक अनुप्रयोगहरूलाई असर नगरी तल जान अनुमति दिनेछ।

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

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

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

एकल काफ्का ब्रोकरको तुलनामा काफ्का क्लस्टरमा धेरै राम्रो प्रदर्शन सम्भव छ, किनभने विषय विभाजनहरू धेरै अलग-अलग मेसिनहरूमा मापन गर्न सकिन्छ।

परिणामहरू

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

अघिल्लो अनुवादित भाग: सन्देश दलालहरू बुझ्दै। ActiveMQ र Kafka को साथ सन्देश को मेकानिक्स सिक्दै। अध्याय १

अनुवाद गरियो: tele.gg/middle_java

फेरि जारी राखौंला…

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

के काफ्का तपाईंको संगठनमा प्रयोग गरिन्छ?

• हो

• कुनै

• पहिले प्रयोग गरिएको थियो, अहिले छैन

• प्रयोग गर्ने योजना छ

38 प्रयोगकर्ताहरूले मतदान गरे। 8 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com