प्रॉक्सी के ज़रिए Kafka: bootstrap काम करता है, broker कनेक्शन विफल होते हैं

Bootstrap कनेक्शन सफल हो सकता है जबकि Kafka क्लाइंट अभी भी उत्पादन या उपभोग नहीं कर सकता। Bootstrap सर्वर क्लाइंट को क्लस्टर खोजने में मदद करते हैं; ज़रूरी नहीं कि वे ही एकमात्र एंडपॉइंट हों जिनसे वह जुड़ेगा।

Broker मेटाडेटा में बाद के कनेक्शनों के लिए इस्तेमाल होने वाले पते होते हैं। अगर वे नाम या पोर्ट इच्छित प्रॉक्सी मार्ग से पहुँच योग्य नहीं हैं, तो पहला सफल कनेक्शन बाकी काम नहीं सुलझाता।

घोषित एंडपॉइंट पढ़ें

Bootstrap पते की तुलना उन broker पतों से करें जो क्लाइंट वास्तव में प्राप्त करता है। एक सार्वजनिक bootstrap उपनाम निजी घोषित नामों तक ले जा सकता है, और एक स्थानीय पोर्ट आगे बढ़ाने से मेटाडेटा का हर पता अपने आप फिर से नहीं लिखा जाता।

यह भी पहचानें कि क्लाइंट कार्यान्वयन किस प्रॉक्सी मार्ग का समर्थन करता है। Java सिस्टम SOCKS प्रॉपर्टी इस बात की गारंटी नहीं है कि किसी लाइब्रेरी का NIO-आधारित ट्रांसपोर्ट JDK Socket प्रॉक्सी तंत्र का उपयोग करता है। हर Java सॉकेट के एक ही सेटिंग का पालन करने की धारणा के बजाय वास्तविक Kafka क्लाइंट और नेटवर्क एकीकरण की जाँच करें।

प्रॉक्सी-जागरूक क्लाइंट को प्रासंगिक broker एंडपॉइंट तक अनुमत मार्ग चाहिए। नेटवर्क-स्तर की व्यवस्था को संबंधित पहुँच और नाम समाधान चाहिए। ये अलग डिज़ाइन हैं, और प्रॉक्सी को bootstrap सर्वर के रूप में सूचीबद्ध करने से कोई भी नहीं मिलता।

सुरक्षा प्रोटोकॉल और प्रमाणीकरण सेटिंग्स अलग रखें। एक प्रॉक्सी TCP मार्ग स्थापित कर सकता है जबकि TLS पहचान, SASL प्रमाणीकरण या broker प्राधिकरण अभी भी विफल हो सकता है।

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