🍏 🌰 🤗 काफ्का धाराओं के साथ अनुप्रयोगों की उच्च उपलब्धता सुनिश्चित करना 👇 😶 👗

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

हमें क्या जानने की जरूरत है

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

कफका: विभाजन डेटा

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

उपभोक्ता एप्लिकेशन उपभोक्ता समूहों में व्यवस्थित होते हैं, और प्रत्येक समूह में उपभोक्ताओं के एक या अधिक उदाहरण हो सकते हैं।

उपभोक्ता समूह में एक उपभोक्ता का प्रत्येक उदाहरण इनपुट विषय के विभाजन के अनूठे सेट से डेटा को संसाधित करने के लिए जिम्मेदार है।

उपभोक्ता उदाहरण अनिवार्य रूप से आपके उपभोक्ताओं के समूह में प्रसंस्करण को बढ़ाने का एक साधन है।

काफ्का: रिबैलेंसिंग कंज्यूमर ग्रुप

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

कफ़का धाराएँ: धाराएँ

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

स्रोत: kafka.apache.org/21/documentation/streams/altecture

कफका धाराओं में कई और तत्व हैं, जैसे कि कार्य, प्रसंस्करण टोपोलॉजी, थ्रेडिंग मॉडल, आदि, जिसके बारे में हम इस पोस्ट में चर्चा नहीं करेंगे। अधिक जानकारी यहां पाई जा सकती है।

काफ्का स्ट्रीम: स्टेट स्टोरेज

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

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

राज्य भंडारण के बारे में अधिक जानकारी यहां पाई जा सकती है ।

कफका धाराओं के साथ उच्च उपलब्धता समस्याग्रस्त क्यों है?

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

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

TransferWise SPaaS (Stream Processing as a Service)

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

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

उत्पाद टीमों को वास्तविक समय में एकत्रित डेटा को अपडेट करने की आवश्यकता है। हमारे ग्राहकों को तुरंत धन हस्तांतरित करने की क्षमता प्रदान करने के लिए यह आवश्यक है। हमारे सामान्य SLA:

किसी भी दिन, कुल डेटा का 99.99% 10 सेकंड से कम में उपलब्ध होना चाहिए।

आपको एक विचार देने के लिए, तनाव परीक्षण के दौरान, काफ्का स्ट्रीम 20,085 इनपुट संदेशों को प्रति सेकंड संसाधित और एकत्र करने में सक्षम था। इस प्रकार, सामान्य लोड के तहत SLA के 10 सेकंड काफी विश्वसनीय लग रहे थे। दुर्भाग्य से, हमारे एसएलए नोड्स के रोलिंग अपडेट के दौरान नहीं पहुंचा था, जिस पर आवेदन तैनात किए गए हैं, और नीचे मैं वर्णन करूंगा कि यह क्यों हुआ।

स्लाइडिंग नोड अपडेट

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

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

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

स्टैंडबाय प्रतिकृतियां

काफ्का धाराओं के अनुप्रयोगों के लिए पुनर्संतुलन समय को कम करने के लिए, बैकअप प्रतिकृतियों की एक अवधारणा है, जो कि config में num.standby.replicas के रूप में परिभाषित की जाती है। बैकअप प्रतिकृतियां स्थानीय स्टेट स्टोर की प्रतियां हैं। यह तंत्र राज्य की दुकान को काफ्का धाराओं के एक उदाहरण से दूसरे में दोहराने के लिए संभव बनाता है। जब कफका धाराएं किसी भी कारण से मर जाती हैं, तो राज्य पुनर्प्राप्ति प्रक्रिया की अवधि कम से कम हो सकती है। दुर्भाग्य से, जिन कारणों के लिए मैं नीचे बताऊंगा, यहां तक कि बैकअप प्रतिकृतियां भी रोलिंग सेवा अपडेट के साथ मदद नहीं करेंगी।

मान लीजिए हमारे पास दो अलग-अलग मशीनों पर काफ्का धाराओं के दो उदाहरण हैं: नोड-ए और नोड-बी। कफका धाराओं के प्रत्येक उदाहरण के लिए, num.standby.replicas = 1 को इन 2 नोड्स पर दर्शाया गया है। इस विन्यास के साथ, प्रत्येक काफ्का स्ट्रीम उदाहरण दूसरे नोड पर रिपॉजिटरी की अपनी प्रति बनाए रखता है। एक रोलिंग अद्यतन के दौरान, हमारे पास निम्न स्थिति है:

सेवा के नए संस्करण को नोड-ए में तैनात किया गया है।
नोड-ए पर काफ्का धाराएं अक्षम हैं।
असंतुलन शुरू हो गया है।
नोड-ए से रिपॉजिटरी को पहले ही नोड-बी में दोहराया गया है, क्योंकि हमने कॉन्फ़िगरेशन num.standby.replicas = 1 निर्दिष्ट किया है।
नोड-बी में पहले से ही नोड-ए की छाया प्रति है, इसलिए पुनर्संतुलन प्रक्रिया लगभग तुरंत होती है।
नोड-एक फिर से शुरू होता है।
नोड- उपभोक्ताओं के एक समूह में शामिल होता है।
काफ्का ब्रोकर काफ्का स्ट्रीम्स का एक नया उदाहरण देखता है और पुनर्संतुलन शुरू करता है।

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

उपलब्धि: काफ्का धाराओं के साथ उच्च उपलब्धता

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

हमारे प्रारंभिक सेटअप के साथ समस्या यह थी कि हमारे पास सभी नोड्स पर सभी टीमों के लिए उपभोक्ताओं का एक समूह था। अब, उपभोक्ताओं के एक समूह के बजाय, हमारे पास दो हैं, और दूसरा "गर्म" क्लस्टर के रूप में कार्य करता है। ठेस में, नोड्स में एक विशेष चर CLUSTER_ID होता है, जो Kafka धाराओं के अनुप्रयोग के लिए जोड़ा जाता है। यहाँ एक नमूना स्प्रिंग बूट अनुप्रयोग है। विन्यास विन्यास:

application.yml

spring.profiles: production
streaming-pipelines:
team-a-stream-app-id: "${CLUSTER_ID}-team-a-stream-app"
team-b-stream-app-id: "${CLUSTER_ID}-team-b-stream-app"

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

अतिरिक्त क्लस्टर जोड़ने के अलावा, ऐसे ट्रिक्स भी हैं जो बार-बार असंतुलन के साथ समस्या को कम कर सकते हैं।

Group.initial.rebalance.delay.ms बढ़ाएँ

Kafka 0.11.0.0 के साथ शुरू, कॉन्फ़िगरेशन group.initial.rebalance.delay.ms जोड़ा गया है। प्रलेखन के अनुसार, यह सेटिंग निम्न के लिए जिम्मेदार है:

समूह के समन्वयक को समूह के उपभोक्ता के आरंभिक पुन: संतुलन में देरी के कारण मिलीसेकंड में समय की मात्रा अधिक होगी।

उदाहरण के लिए, यदि हम इस सेटिंग में 60,000 मिलीसेकंड सेट करते हैं, तो एक रोलिंग अपडेट के साथ हमारे पास रिलीज के लिए एक मिनट की खिड़की हो सकती है। यदि इस समय विंडो में काफ़्का स्ट्रीम इंस्टेंस सफलतापूर्वक फिर से शुरू होता है, तो कोई रिबैलेंसिंग नहीं कहा जाएगा। कृपया ध्यान दें कि जिस डेटा के लिए काफ़्का स्ट्रीम्स का पुनः आरंभ होना जिम्मेदार था, वह तब तक अनुपलब्ध रहेगा, जब तक नोड ऑनलाइन मोड में नहीं लौटता। उदाहरण के लिए, यदि एक उदाहरण रिबूट के बारे में आठ सेकंड लगते हैं, तो आपके पास उस डेटा के लिए आठ सेकंड का डाउनटाइम होगा जो इस उदाहरण के लिए जिम्मेदार है।

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

परिवर्तन-लॉग विषयों में खंड आकार सिकुड़ रहा है

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

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

निष्कर्ष

भले ही काफ्का स्ट्रीम एक रोलिंग सेवा अद्यतन के दौरान उच्च उपलब्धता प्रदान करने की अंतर्निहित क्षमता प्रदान नहीं करती है, फिर भी यह बुनियादी ढांचे के स्तर पर किया जा सकता है। हमें याद रखना चाहिए कि काफ्का स्ट्रीम अपाचे फ्लिंक या अपाचे स्पार्क के विपरीत "क्लस्टर फ्रेमवर्क" नहीं है। यह एक हल्का जावा पुस्तकालय है जो डेवलपर्स को स्ट्रीमिंग डेटा के लिए स्केलेबल एप्लिकेशन बनाने की अनुमति देता है। इसके बावजूद, यह "99.99%" उपलब्धता के रूप में इस तरह के महत्वाकांक्षी स्ट्रीमिंग लक्ष्यों को प्राप्त करने के लिए आवश्यक बिल्डिंग ब्लॉक प्रदान करता है।

काफ्का धाराओं के साथ अनुप्रयोगों की उच्च उपलब्धता सुनिश्चित करना