प्रोक्सीमार्फत Kafka: bootstrap काम गर्छ, तर broker जडानहरू असफल हुन्छन्

Kafka क्लाइन्टले अझै उत्पादन वा उपभोग गर्न नसके पनि bootstrap जडान सफल हुन सक्छ। Bootstrap सर्भरहरूले क्लाइन्टलाई क्लस्टर पत्ता लगाउन मद्दत गर्छन्; ती क्लाइन्टले जोडिने मात्र अन्त्य बिन्दुहरू नहुन सक्छन्।

Broker मेटाडेटामा पछिका जडानका लागि प्रयोग हुने ठेगानाहरू हुन्छन्। यदि ती नाम वा पोर्टहरू इच्छित प्रोक्सी मार्गबाट पुग्न नसकिने भए, पहिलो सफल जडानले बाँकी काम समाधान गर्दैन।

घोषित अन्त्य बिन्दुहरू पढ्नुहोस्

Bootstrap ठेगानालाई क्लाइन्टले वास्तवमा प्राप्त गर्ने broker ठेगानाहरूसँग तुलना गर्नुहोस्। सार्वजनिक bootstrap उपनामले निजी घोषित नामहरूमा लैजान सक्छ, र एउटा स्थानीय पोर्ट अगाडि पठाउँदा मेटाडेटाका सबै ठेगानाहरू स्वतः पुनःलेखिँदैनन्।

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

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

सुरक्षा प्रोटोकल र प्रमाणीकरण सेटिङहरू अलग राख्नुहोस्। प्रोक्सीले TCP मार्ग स्थापना गर्न सक्छ, तर TLS पहिचान, SASL प्रमाणीकरण वा broker अधिकार अझै असफल हुन सक्छ।

निदानका लागि, कुन अन्त्य बिन्दु असफल भयो र त्यो स्थिर कन्फिगरेसनबाट आयो वा फर्काइएको मेटाडेटाबाट आयो भनी नोट गर्नुहोस्। त्यो भिन्नताले पहिले नै पहुँचयोग्य अन्त्य बिन्दु बारम्बार बदल्नुभन्दा समस्यालाई धेरै साँघुरो बनाउँछ।