"अपाचे काफ्का" पुस्तक। स्ट्रीम प्रसंस्करण और डेटा विश्लेषण ”

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

यह पुस्तक किसके लिए है?

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

अन्य अध्याय, विशेष रूप से 2, 8, 9, और 10, मान लेते हैं कि पाठक के पास लिनक्स के साथ अनुभव है और लिनक्स नेटवर्क और स्टोरेज स्थापित करने से परिचित है। काफ्का की पुस्तक और सॉफ्टवेयर आर्किटेक्चर के शेष हिस्सों पर अधिक सामान्य शब्दों में चर्चा की गई है, इसलिए पाठकों से किसी विशेष ज्ञान की आवश्यकता नहीं है।

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

अध्याय 2. काफ्का स्थापित करना

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

जावा स्थापित करें

चिड़ियाघरकीपर या काफ्का स्थापित करने से पहले, आपको जावा वातावरण को स्थापित और कॉन्फ़िगर करना होगा। यह अनुशंसा की जाती है कि आप जावा 8 का उपयोग करें, और यह एक संस्करण हो सकता है, या तो आपके ऑपरेटिंग सिस्टम में शामिल है या सीधे java.com से डाउनलोड किया गया है। हालाँकि, चिड़ियाघरकीपर और काफ्का जावा रनटाइम संस्करण के साथ काम करेंगे, लेकिन उपयोगिताओं और अनुप्रयोगों को विकसित करते समय पूर्ण जावा डेवलपमेंट किट (जेडडीके) का उपयोग करना अधिक सुविधाजनक है। ये स्थापना चरण मानते हैं कि आपके पास JDK संस्करण 8.0.51 /usr/java/jdk1.8.0.151 निर्देशिका में स्थापित है।

चिड़ियाघर कीपर स्थापित करें

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


काफ्का को चिड़ियाघरकीपर रिपॉजिटरी के स्थिर संस्करण 3.4.6 के साथ अच्छी तरह से परीक्षण किया गया है, जिसे apache.org से डाउनलोड किया जा सकता है।

स्टैंडअलोन सर्वर

निम्न उदाहरण / usr / स्थानीय / ज़ुकेर डायरेक्टरी में बुनियादी सेटिंग्स के साथ ZooKeeper स्थापित करने और / var / lib / zookeeper डायरेक्टरी में डेटा सहेजने को प्रदर्शित करता है:

# tar -zxf zookeeper-3.4.6.tar.gz # mv zookeeper-3.4.6 /usr/local/zookeeper # mkdir -p /var/lib/zookeeper # cat > /usr/local/zookeeper/conf/zoo.cfg << EOF > tickTime=2000 > dataDir=/var/lib/zookeeper > clientPort=2181 > EOF # /usr/local/zookeeper/bin/zkServer.sh start JMX enabled by default Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED # export JAVA_HOME=/usr/java/jdk1.8.0_51 # /usr/local/zookeeper/bin/zkServer.sh start JMX enabled by default Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED # 

अब आप सत्यापित कर सकते हैं कि ZooKeeper क्लाइंट पोर्ट से कनेक्ट करके और चार-अक्षर srvr कमांड भेजकर ऑफ़लाइन काम करने वाला है:

 # telnet localhost 2181 Trying ::1... Connected to localhost. Escape character is '^]'. srvr Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT Latency min/avg/max: 0/0/0 Received: 1 Sent: 0 Connections: 1 Outstanding: 0 Zxid: 0x0 Mode: standalone Node count: 4 Connection closed by foreign host. # 

चिड़ियाघर की चौकी

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

कलाकारों की टुकड़ी में ZooKeeper सर्वर के संचालन को कॉन्फ़िगर करने के लिए, उनके पास सभी सर्वरों की एक सूची के साथ एक एकल कॉन्फ़िगरेशन होना चाहिए, और डेटा निर्देशिका में प्रत्येक सर्वर के पास इस सर्वर के पहचानकर्ता के साथ एक myid फ़ाइल होनी चाहिए। अगर कलाकारों की टुकड़ी में zoo1.example.com, zoo2.example.com और zoo3.example.com नाम दिए गए हैं, तो कॉन्फ़िगरेशन फ़ाइल कुछ इस तरह दिख सकती है:

 tickTime=2000 dataDir=/var/lib/zookeeper clientPort=2181 initLimit=20 syncLimit=5 server.1=zoo1.example.com:2888:3888 server.2=zoo2.example.com:2888:3888 server.3=zoo3.example.com:2888:3888 

इस कॉन्फ़िगरेशन में, initLimit समय की मात्रा है जो दास नोड्स मास्टर से जुड़ सकता है। SyncLimit मान मास्टर से दास नोड्स के अंतराल को सीमित करता है। दोनों मान टिकटाइम इकाइयों में निर्दिष्ट हैं, अर्थात् initLimit = 20 · 2000 एमएस = 40 एस। कॉन्फ़िगरेशन सभी कलाकारों की टुकड़ी को भी सूचीबद्ध करता है। वे प्रारूप server.X = hostname: peerPort: लीडरपोर्ट में निम्नलिखित मापदंडों के साथ हैं:

• X सर्वर पहचानकर्ता है। यह पूर्णांक होना चाहिए, लेकिन गणना शून्य से नहीं हो सकती है और अनुक्रमिक नहीं हो सकती है;
• hostname - होस्ट नाम या सर्वर आईपी पता;
• पीयरपोर्ट - टीसीपी पोर्ट जिसके माध्यम से सर्वर एक-दूसरे के साथ संचार करते हैं;
• लीडरपोर्ट - टीसीपी पोर्ट जिसके माध्यम से होस्ट का चयन किया जाता है।

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

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

काफ्का ब्रोकर स्थापित करना

जावा और चिड़ियाघरकीपर के कॉन्फ़िगरेशन को पूरा करने के बाद, आप अपाचे काफ्का की स्थापना के साथ आगे बढ़ सकते हैं। Apache Kafka की नवीनतम रिलीज़ kafka.apache.org/downloads.html पर डाउनलोड की जा सकती है।

निम्नलिखित उदाहरण में, / usr / स्थानीय / कफका निर्देशिका में कफका मंच स्थापित करें, इसे पहले लॉन्च किए गए चिड़ियाघरकीपर सर्वर का उपयोग करने के लिए कॉन्फ़िगर करें और संदेश लॉग खंडों को / tmp / kafka- लॉग निर्देशिका में सहेजें:

 # tar -zxf kafka_2.11-0.9.0.1.tgz # mv kafka_2.11-0.9.0.1 /usr/local/kafka # mkdir /tmp/kafka-logs # export JAVA_HOME=/usr/java/jdk1.8.0_51 # /usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties # 

काफ्का दलाल को लॉन्च करने के बाद, आप क्लस्टर के साथ कोई भी सरल ऑपरेशन करके, परीक्षण विषय बनाने, संदेश उत्पन्न करने और उनका उपभोग करने सहित इसके कामकाज का परीक्षण कर सकते हैं।

धागे बनाना और जांचना:

 # /usr/local/kafka/bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test Created topic "test". # /usr/local/kafka/bin/kafka-topics.sh --zookeeper localhost:2181 --describe --topic test Topic:test PartitionCount:1 ReplicationFactor:1 Configs: Topic: test Partition: 0 Leader: 0 Replicas: 0 Isr: 0 # 

परीक्षण विषय के लिए संदेश उत्पन्न करना:

 # /usr/local/kafka/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test Test Message 1 Test Message 2 ^D # 

परीक्षण विषय से संदेश भेजना:

 # /usr/local/kafka/bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginning Test Message 1 Test Message 2 ^C Consumed 2 messages # 

ब्रोकर कॉन्फ़िगरेशन

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

बुनियादी ब्रोकर सेटिंग्स

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

broker.id

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

बंदरगाह

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

zookeeper.connect

ब्रोकर के मेटाडेटा को स्टोर करने के लिए चिड़ियाघरकीपर जिस पथ का उपयोग करता है वह zookeeper.connect कॉन्फ़िगरेशन पैरामीटर का उपयोग करके सेट किया गया है। नमूना कॉन्फ़िगरेशन में, ज़ूकेपर स्थानीय होस्ट पर 2181 पोर्ट पर चलता है, जिसे स्थानीयहोस्ट के रूप में इंगित किया गया है: 2181। इस पैरामीटर का प्रारूप प्रपत्र होस्टनाम की पंक्तियों की अर्धविराम से अलग सूची है: पोर्ट / पथ, सहित:

• hostname - ZooKeeper सर्वर का होस्टनाम या IP पता;
• पोर्ट - सर्वर के लिए क्लाइंट पोर्ट नंबर;
• / पथ - एक वैकल्पिक चिड़ियाघर कीपर पथ काफ्का क्लस्टर की नई जड़ (चुरोट) पथ के रूप में उपयोग किया जाता है। यदि यह निर्दिष्ट नहीं है, तो रूट पथ का उपयोग किया जाता है।

यदि निर्दिष्ट चेरोट पथ मौजूद नहीं है, तो यह ब्रोकर के शुरू होने पर बनाया जाएगा।

log.dirs

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

num.recovery.threads.per.data.dir

काफ्का लॉग सेगमेंट को संसाधित करने के लिए एक कस्टम थ्रेड पूल का उपयोग करता है। वर्तमान में यह लागू है:

• सामान्य स्टार्टअप के दौरान - प्रत्येक अनुभाग के लॉग सेगमेंट को खोलने के लिए;
• एक विफलता के बाद शुरू - प्रत्येक खंड के लॉग सेगमेंट की जांच करने और कम करने के लिए;
• बंद करो - धीरे लॉग खंडों को बंद करने के लिए।

डिफ़ॉल्ट रूप से, प्रति लॉग निर्देशिका में केवल एक थ्रेड का उपयोग किया जाता है। चूंकि यह केवल शुरू करने और रोकने के दौरान होता है, इसलिए ऑपरेशनों को समानांतर बनाने के लिए उनमें से अधिक का उपयोग करना समझ में आता है। एक गलत शटडाउन से उबरने पर, इस दृष्टिकोण का उपयोग करने के लाभ कई घंटों तक पहुंच सकते हैं यदि बड़ी संख्या में विभाजन के साथ दलाल को फिर से शुरू किया जाए! याद रखें कि इस पैरामीटर का मान log.dirs का उपयोग करके निर्दिष्ट संख्या से एक लॉग निर्देशिका के आधार पर निर्धारित किया जाता है। यही है, यदि num.recovery.threads.per.data.dir पैरामीटर का मान 8 है, और log.dirs में तीन पथ निर्दिष्ट हैं, तो थ्रेड्स की कुल संख्या 24 है।

auto.create.topics.enable

काफ्का के डिफ़ॉल्ट कॉन्फ़िगरेशन के अनुसार, ब्रोकर को स्वतः ही एक विषय बनाना चाहिए जब:

• निर्माता विषय पंक्ति में लिखना शुरू करता है;
• उपभोक्ता विषय पंक्ति से पढ़ना शुरू करता है;
• कोई भी ग्राहक विषय मेटाडेटा का अनुरोध करता है।

कई मामलों में, यह व्यवहार अवांछनीय हो सकता है, विशेष रूप से इस तथ्य के कारण कि कफका प्रोटोकॉल का उपयोग किए बिना किसी विषय के अस्तित्व की जांच करने का कोई तरीका नहीं है, जिससे इसे बनाया जा सके। यदि आप स्पष्ट रूप से या प्रारंभिक प्रणाली के माध्यम से उस निर्माण को नियंत्रित करते हैं, तो आप auto.create.topics.enable पैरामीटर को गलत पर सेट कर सकते हैं।

डिफ़ॉल्ट थीम सेटिंग्स

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

num.partitions

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

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

log.retention.ms

अधिक बार नहीं, काफ्का में संदेश भंडारण समय में सीमित है। डिफ़ॉल्ट मान log.retention.hours पैरामीटर का उपयोग करके कॉन्फ़िगरेशन फ़ाइल में निर्दिष्ट किया गया है और 168 घंटे, या 1 सप्ताह के बराबर है। हालाँकि, आप दो अन्य मापदंडों - log.retention.minutes और log.retention.ms का उपयोग कर सकते हैं। इन तीनों मापदंडों में एक ही बात निर्धारित होती है - उस समय की अवधि जिसके बाद संदेश हटा दिए जाते हैं। लेकिन यह log.retention.ms पैरामीटर का उपयोग करने के लिए अनुशंसित है, क्योंकि यदि कई पैरामीटर निर्दिष्ट हैं, तो प्राथमिकता माप की सबसे छोटी इकाई से संबंधित है, इसलिए log.retention.ms का मान हमेशा उपयोग किया जाएगा।

log.retention.bytes

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

log.segment.bytes

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

संदेश जनरेशन की कम आवृत्ति की विशेषता वाले विषयों में साइज़ लॉग सेगमेंट महत्वपूर्ण है। उदाहरण के लिए, यदि कोई विषय प्रति दिन केवल 100 एमबी संदेश प्राप्त करता है, और डिफ़ॉल्ट मान पर log.segment.bytes पैरामीटर सेट है, तो एक खंड को भरने में 10 दिन लगते हैं। और जब से लॉग सेगमेंट को बंद नहीं किया जाता है, तब तक संदेशों को अमान्य घोषित नहीं किया जा सकता है, फिर लॉग.retention.ms पैरामीटर के 604.8 मिलियन (1 सप्ताह) के मान के साथ, बंद लॉग सेगमेंट को संचलन से वापस लेने से पहले 17 दिनों में संदेश जमा हो सकते हैं। ऐसा इसलिए है क्योंकि जब आप 10 दिनों में जमा हुए संदेशों के साथ एक खंड को बंद करते हैं, तो आपको इसे 7 दिनों के लिए स्टोर करना होगा, इससे पहले कि आप इसे अपनाए गए अस्थायी नियमों के अनुसार इसे रिटायर कर सकें, क्योंकि अंतिम संदेश समाप्त होने से पहले खंड को हटाया नहीं जा सकता है। ।

log.segment.ms

लॉग सेगमेंट के समापन को नियंत्रित करने का एक और तरीका है log.segment.ms पैरामीटर का उपयोग करके, जो उस समय की लंबाई को निर्दिष्ट करता है जिसके बाद लॉग सेगमेंट बंद हो जाता है। Log.retention.bytes और log.retention.ms मापदंडों की तरह, log.segment.bytes और log.segment.ms पैरामीटर पारस्परिक रूप से अनन्य नहीं हैं। काफ्का लॉग सेगमेंट को बंद कर देता है जब या तो समय समाप्त हो जाता है या निर्दिष्ट आकार सीमा पूरी हो जाती है, इसके आधार पर इनमें से कौन सी घटना पहले होती है। डिफ़ॉल्ट रूप से, log.segment.ms पैरामीटर का मान सेट नहीं किया जाता है, जिसके परिणामस्वरूप लॉग सेगमेंट का समापन उनके आकार से निर्धारित होता है।

message.max.bytes

काफ्का ब्रोकर उत्पन्न संदेशों के अधिकतम आकार को सीमित करने के लिए message.max.bytes पैरामीटर का उपयोग करने की अनुमति देता है। इस पैरामीटर के लिए डिफ़ॉल्ट मान 1,000,000 (1 एमबी) है। एक निर्माता जो एक बड़ा संदेश भेजने की कोशिश करता है, उसे ब्रोकर से एक त्रुटि सूचना प्राप्त होगी, लेकिन संदेश स्वीकार नहीं किया जाएगा। जैसा कि ब्रोकर की सेटिंग में निर्दिष्ट बाइट्स में अन्य सभी आकारों के मामले में, हम संपीड़ित संदेश के आकार के बारे में बात कर रहे हैं, इसलिए निर्माता संदेश भेज सकते हैं, जिनमें से आकार असम्पीडित बहुत बड़ा है यदि उन्हें संदेश द्वारा निर्दिष्ट सीमाओं से संकुचित किया जा सकता है। ।

संदेश का आकार बढ़ने से प्रदर्शन प्रभावित हो सकता है। एक बड़ा संदेश आकार का मतलब है कि ब्रोकर थ्रेड जो नेटवर्क कनेक्शन और अनुरोधों को संसाधित करते हैं, प्रत्येक अनुरोध के लिए अधिक समय लगेगा। बड़े संदेश भी डिस्क पर लिखे गए डेटा की मात्रा को बढ़ाते हैं, जो I / O थ्रूपुट को प्रभावित करता है।

हार्डवेयर चयन

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

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

डिस्क थ्रूपुट

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

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

डिस्क की क्षमता

क्षमता भंडारण का दूसरा पहलू है। डिस्क स्थान की आवश्यक मात्रा निर्धारित की जाती है कि एक ही समय में कितने संदेशों को संग्रहीत करने की आवश्यकता है। यदि ब्रोकर को प्रति दिन 1 टीबी यातायात प्राप्त होने की उम्मीद है, तो 7-दिन के भंडारण के साथ, उसे कम से कम 7 टीबी के लॉग सेगमेंट के लिए उपलब्ध स्टोरेज की आवश्यकता होगी। आपको अन्य फ़ाइलों के लिए कम से कम 10% की ओवररन पर भी विचार करना चाहिए, संभावित ट्रैफ़िक में उतार-चढ़ाव या समय के साथ इसकी वृद्धि के लिए बफर की गिनती नहीं करना चाहिए।

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

स्मृति

ऑपरेशन के सामान्य मोड में, उपभोक्ता काफ्का अनुभाग के अंत से पढ़ता है, और उपभोक्ता लगातार खोए हुए समय के लिए बनाता है और केवल निर्माताओं के पीछे थोड़ा पीछे होता है, अगर बिल्कुल। , , . , , -.

Kafka JVM . , X X , 5 . Kafka . Kafka , , , Kafka.

, Kafka, . ( ) . Kafka ( ) . 1 , , . , (. 6) ( 8). , .

सीपीयू

, , . . Kafka, , . . Kafka ' . .

Kafka

Kafka , , Amazon Web Services (AWS). AWS , CPU, . Kafka. , . / SSD. (, AWS Elastic Block Store). CPU .
, AWS m4 r3. m4 , , . r3 SSD-, . i2 d2.

Kafka

Kafka , (. 2.2). — . — . Kafka . Kafka. 6.

?

Kafka . — . 10 , 2 , — . , 100 % ( ) (. 6). , .

, , — . , ( ). 80 % , , . , , . , , .

Kafka. — zookeeper.connect. ZooKeeper . — broker.id. broker.id , . , , , .

Linux , , Kafka. , , . /etc/sysctl.conf, Linux, .

Linux . , «» , Kafka.
, , , () . , , Kafka. , Kafka , , .

— . — , - . . vm.swappiness , 1. ( ) , . , .

, «» , , . Kafka /. : (, SSD), NVRAM (, RAID). «» , . vm.dirty_background_ratio , ( 10). ( ), 5. 0, .

«» , , vm.dirty_ratio , — 20 ( ). , 60 80. , / . vm.dirty_ratio Kafka, .

«» Kafka . /proc/vmstat:

 # cat /proc/vmstat | egrep "dirty|writeback" nr_dirty 3875 nr_writeback 29 nr_writeback_temp 0 # 

डिस्क

, RAID- , . , EXT4 (fourth extended file system — ) XFS (Extents File System — ). EXT4 , . , (5), . EXT4 , . XFS , , EXT4. XFS Kafka , , . , /.

, , noatime. /: (ctime), (mtime) (atime). atime . . atime , , , ( realtime). Kafka atime, . noatime /, ctime mtime.

Linux — , , . Kafka , - . ( ) , . . net.core.wmem_default net.core.rmem_default , 2 097 152 (2 ). , , .

TCP net.ipv4.tcp_wmem net.ipv4.tcp_rmem. , , . — 4096 65536 2048000 — , 4 , — 64 , — 2 . , net.core.wmem_max net.core.rmem_max. Kafka .

. TCP 1 net.ipv4.tcp_window_scaling, . net.ipv4.tcp_max_syn_backlog , 1024, . net.core.netdev_max_backlog, 1000, , , , .

Kafka , .

Java , , . , Java 7 Garbage First (G1). G1 . , , .

G1 . .

• MaxGCPauseMillis. . — G1 . 200 . , G1 , , , , 200 .
• InitiatingHeapOccupancyPercent. , . 45. , G1 , 45 % , (Eden), .

Kafka , . 64 , Kafka 5 . 20 MaxGCPauseMillis. InitiatingHeapOccupancyPercent 35, , .

Kafka G1, . . :

 # export JAVA_HOME=/usr/java/jdk1.8.0_51 # export KAFKA_JVM_PERFORMANCE_OPTS="-server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true" # /usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties # 

Kafka , . - , . Kafka (. 6), . Kafka, .

Kafka , , ( , , AWS), , . . , «» (. 6).

: Kafka , , , . ( ) . , , .

ZooKeeper

Kafka ZooKeeper , . ZooKeeper Kafka. , ZooKeeper Kafka . ZooKeeper Kafka ( ZooKeeper , ).

ZooKeeper . ZooKeeper, Kafka, . ZooKeeper , ZooKeeper . — 1 , . ZooKeeper, , . ZooKeeper , . , Kafka Kafka ZooKeeper.

Kafka, , . Kafka ZooKeeper, . ZooKeeper, . , , , . , , .

सारांश

, Apache Kafka. , , . , Kafka, Kafka. Kafka ( 3), ( 4).

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर पाई जा सकती है
» सामग्री
» अंश

20% — Apache Kafka