कफका के साथ इवेंट लॉगिंग

नमस्कार, हेब्र!

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



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

"इवेंट सोर्सिंग" शब्द का अनुवाद रॉबर्ट मार्टिन द्वारा और इस लेख में क्लीन आर्किटेक्चर के हमारे प्रकाशन में "इवेंट लॉगिंग" दोनों के रूप में किया गया है । अगर कोई "पंपिंग इवेंट्स" के अनुवाद से प्रभावित होता है - तो कृपया मुझे बताएं।

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

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

इवेंट लॉगिंग क्या है?

इस विषय पर कई उत्कृष्ट परिचयात्मक लेख हैं, इसलिए मैं खुद को सबसे संक्षिप्त परिचय तक सीमित करूंगा। घटनाओं को पंजीकृत करते समय, हम अपने सिस्टम में उपयोग की जाने वाली संस्थाओं की "वर्तमान" स्थिति को नहीं बचाते हैं, लेकिन इन संस्थाओं से संबंधित घटनाओं की धारा। प्रत्येक घटना एक तथ्य है जो राज्य में परिवर्तन (पहले से!) का वर्णन करता है जो वस्तु के साथ हुआ है । जैसा कि आप जानते हैं, तथ्यों पर चर्चा और अपरिवर्तित नहीं हैं ।

जब हमारे पास इस तरह की घटनाओं की एक धारा होती है, तो एक इकाई की वर्तमान स्थिति को उससे संबंधित सभी घटनाओं को कम करके स्पष्ट किया जा सकता है; हालाँकि, ध्यान रखें कि विपरीत संभव नहीं है - केवल "वर्तमान" स्थिति को संरक्षित करते हुए, हम बहुत सारी मूल्यवान कालानुक्रमिक जानकारी को छोड़ देते हैं।

इवेंट लॉगिंग राज्य के अधिक पारंपरिक तरीकों से शांतिपूर्वक सहवास कर सकता है । एक नियम के रूप में, सिस्टम कई प्रकार के निकाय प्रकारों (उदाहरण के लिए: उपयोगकर्ता, ऑर्डर, माल, ...) को संसाधित करता है और यह बहुत संभव है कि घटनाओं का पंजीकरण इनमें से कुछ श्रेणियों के लिए ही उपयोगी होगा। यह ध्यान रखना महत्वपूर्ण है कि यहां हमें "सभी या कुछ भी नहीं" की पसंद का सामना नहीं करना पड़ता है; यह हमारे आवेदन में अतिरिक्त राज्य प्रबंधन सुविधा के बारे में है।

कफका में घटना भंडारण

हल करने के लिए पहली समस्या: काफ्का में घटनाओं को कैसे स्टोर करें? तीन संभावित रणनीतियाँ हैं:

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

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

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

इसके अलावा, आप दोनों रणनीतियों को एक साथ लागू कर सकते हैं, यदि आपके पास अतिरिक्त भंडारण स्थान है: एक व्यापक विषय से इकाई प्रकार के विषयों का उत्पादन करें।



बाकी लेख में, हम केवल एक प्रकार की इकाई के साथ और एक ही विषय के साथ काम करेंगे, हालाँकि प्रस्तुत सामग्री को कई विषयों या इकाई प्रकारों के साथ आसानी से लागू और लागू किया जा सकता है।

(EDIT: जैसा कि क्रिस हंट ने उल्लेख किया है, मार्टिन क्लेपमैन का एक उत्कृष्ट लेख है , जिसमें विस्तार से जांच की गई है कि विषय और खंड द्वारा घटनाओं को कैसे वितरित किया जाए)।

घटना लॉगिंग प्रतिमान में सबसे सरल भंडारण संचालन

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

अंतिम उपाय में सच्चाई इवेंट लॉग होगी: वर्तमान स्थिति हमेशा किसी विशेष इकाई से जुड़ी घटनाओं की धारा से कटौती की जा सकती है। इसके लिए, डेटाबेस इंजन को एक शुद्ध फ़ंक्शन (साइड इफेक्ट्स के बिना) की आवश्यकता होगी जो घटना और प्रारंभिक स्थिति को स्वीकार करता है, और परिवर्तित स्थिति लौटाता है: Event = > State => State । इस तरह के एक समारोह और प्रारंभिक राज्य के मूल्य की उपस्थिति में , वर्तमान स्थिति घटनाओं के प्रवाह का एक दृढ़ संकल्प है (राज्य परिवर्तन समारोह को साफ होना चाहिए ताकि इसे समान घटनाओं के लिए बार-बार स्वतंत्र रूप से लागू किया जा सके।)

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



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

काफ्का-धाराओं में इस तरह का एक ऑपरेशन स्थानीय भंडारण में एक धारा का दृढ़ संकल्प है। प्रत्येक स्थानीय भंडारण में केवल उन खंडों का डेटा होता है जो किसी दिए गए नोड द्वारा खपत होते हैं। बॉक्स से बाहर, दो स्थानीय भंडारण कार्यान्वयन उपलब्ध हैं: रैम में और रॉक्सडीबी पर आधारित।

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

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

 KStreamBuilder builder = new KStreamBuilder(); builder.stream(keySerde, valueSerde, "my_entity_events") .groupByKey(keySerde, valueSerde) //  :     .reduce((currentState, event) -> ..., "my_entity_store"); .toStream(); //     return builder; 

माइक्रोसर्विस पर आधारित ऑर्डर प्रोसेसिंग का पूरा उदाहरण कंफ्लुएंट वेबसाइट पर उपलब्ध है।

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

वर्तमान स्थिति देखें

हमने एक राज्य भंडार बनाया है, जहाँ नोड को सौंपे गए खंडों से आने वाली सभी संस्थाओं की वर्तमान स्थिति स्थित है, लेकिन अब इस भंडार का अनुरोध कैसे करें? यदि अनुरोध स्थानीय है (अर्थात, यह उसी नोड से आता है जहां रिपॉजिटरी स्थित है), तो सब कुछ बहुत सरल है:

 streams .store("my_entity_store", QueryableStoreTypes.keyValueStore()); .get(entityId); 

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

 metadataService .streamsMetadataForStoreAndKey("my_entity_store", entityId, keySerde) 

इसके बाद, आपको किसी तरह अनुरोध को सही नोड पर पुनर्निर्देशित करना होगा। कृपया ध्यान दें: जिस विशिष्ट तरीके से क्रॉस-साइट संचार को कार्यान्वित किया जाता है और उसे संभाला जाता है - चाहे वह REST हो, अक्का-रिमोट हो या कोई अन्य - ज़िम्मेदारी के काफ्का-धाराओं क्षेत्र से संबंधित नहीं है। काफ्का बस राज्य की दुकान तक पहुंच प्रदान करता है और यह जानकारी प्रदान करता है कि दिए गए id लिए किस राज्य का नोड स्थित है।

आपदा वसूली

राज्य के स्टोर अच्छे लगते हैं, लेकिन क्या होता है जब एक नोड विफल हो जाता है? किसी दिए गए सेगमेंट के लिए स्थानीय स्टेट स्टोर का पुनर्निर्माण करना भी एक महंगा ऑपरेशन हो सकता है। यह लंबे समय तक बढ़े हुए विलंब या अनुरोधों के नुकसान को भड़का सकता है, क्योंकि काफ्का-धाराओं को फिर से असंतुलित (नोड को जोड़ने या हटाने के बाद) करने की आवश्यकता होगी।

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

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

संगति

डिफ़ॉल्ट सेटिंग्स के साथ, काफ्का कम से कम एक बार डिलीवरी प्रदान करता है। अर्थात्, नोड विफलता की स्थिति में, कुछ संदेश कई बार वितरित किए जा सकते हैं। उदाहरण के लिए, यह संभव है कि राज्य स्टोर में लॉग में परिवर्तन के बाद सिस्टम क्रैश होने पर किसी विशेष घटना को दो बार राज्य के स्टोर पर लागू किया जाएगा, लेकिन इस विशेष ईवेंट के लिए ऑफसेट करने से पहले। शायद यह किसी भी कठिनाइयों का कारण नहीं होगा: हमारा राज्य अपडेट फ़ंक्शन ( Event = > State => State ) सामान्य रूप से ऐसी स्थितियों का सामना कर सकता है। हालांकि, यह सामना करने में सक्षम नहीं हो सकता है: ऐसे मामले में, कफका द्वारा प्रदान की जाने वाली सख्ती से एक बार की डिलीवरी की गारंटी का उपयोग किया जा सकता है। इस तरह की गारंटी केवल काफ्का विषयों को पढ़ने और लिखने पर लागू होती है, लेकिन यह वही है जो हम यहां कर रहे हैं: पृष्ठभूमि में, काफ्का विषयों में सभी प्रविष्टियां राज्य के स्टोर के लिए परिवर्तन लॉग को अपडेट करने और ऑफ़सेट करने के लिए कम हो जाती हैं । यह सब लेनदेन के रूप में किया जा सकता है।

इसलिए, यदि राज्य को अद्यतन करने के हमारे कार्य को इसकी आवश्यकता है, तो हम एकल कॉन्फ़िगरेशन विकल्प का उपयोग करके "कड़ाई से एक बार वितरण" के प्रसंस्करण के शब्दार्थ को सक्षम कर सकते हैं: processing.guarantee । इस वजह से, प्रदर्शन गिर जाता है, लेकिन कुछ भी व्यर्थ नहीं आता है।

घटना सुनना

अब जब हमने मूल बातें कवर की हैं - "वर्तमान स्थिति" को उद्धृत करते हुए और प्रत्येक इकाई के लिए इसे अपडेट करते हुए - साइड इफेक्ट को ट्रिगर करने के बारे में क्या? कुछ बिंदु पर, यह आवश्यक हो जाएगा, उदाहरण के लिए:

• अधिसूचना ईमेल भेज रहा है
• सर्च इंजन एंटिटी इंडेक्सिंग
• REST (या SOAP, CORBA, आदि) के माध्यम से बाहरी सेवाओं को कॉल करना

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

इसके अलावा, राज्य अद्यतन तर्क (ई Event = > State => State ) के साथ एक फ़ंक्शन कई बार (विफलताओं या पुनरारंभ होने की स्थिति में) चलाया जा सकता है, और अक्सर हम उन मामलों की संख्या को कम करना चाहते हैं जिनमें किसी विशेष घटना के लिए साइड इफेक्ट कई बार चलते हैं।

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

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

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

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

दृश्य और अनुमान बनाना

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



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

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

आगे क्या है

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

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

सारांश

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