પ્રોક્સી દ્વારા Kafka: bootstrap કામ કરે છે, broker જોડાણો નિષ્ફળ જાય છે
કેમ સફળ Kafka bootstrap જોડાણ દ્વારા શોધાયેલા દરેક broker સુધી પ્રોક્સી પહોંચની ખાતરી આપતું નથી તે સમજાવે છે.
Kafka ક્લાયન્ટ હજી પણ ઉત્પાદન કે વપરાશ કરી શકતો ન હોય ત્યારે bootstrap જોડાણ સફળ થઈ શકે છે. Bootstrap સર્વરો ક્લાયન્ટને ક્લસ્ટર શોધવામાં મદદ કરે છે; તે જરૂરી નથી કે તેઓ જ એકમાત્ર એન્ડપોઇન્ટ હોય જેની સાથે તે જોડાશે.
Broker મેટાડેટામાં પછીના જોડાણો માટે વપરાતા સરનામાં હોય છે. જો તે નામો કે પોર્ટ ઇચ્છિત પ્રોક્સી માર્ગ દ્વારા પહોંચી શકાય તેવા ન હોય, તો પ્રથમ સફળ જોડાણ બાકીનું કામ ઉકેલતું નથી.
જાહેર કરેલા એન્ડપોઇન્ટ વાંચો
Bootstrap સરનામાની સરખામણી ક્લાયન્ટને ખરેખર મળતા broker સરનામાં સાથે કરો. જાહેર bootstrap ઉપનામ ખાનગી જાહેર નામો તરફ દોરી શકે છે, અને એક સ્થાનિક પોર્ટ ફોરવર્ડ કરવાથી મેટાડેટાના દરેક સરનામાં આપોઆપ ફરીથી લખાતા નથી.
ક્લાયન્ટ અમલીકરણ કયો પ્રોક્સી માર્ગ સમર્થન કરે છે તે પણ ઓળખો. Java સિસ્ટમ SOCKS ગુણધર્મ એ બાંયધરી નથી કે લાઇબ્રેરીનું NIO-આધારિત પરિવહન JDK Socket પ્રોક્સી પદ્ધતિ વાપરે છે. દરેક Java સોકેટ સમાન સેટિંગનું પાલન કરે છે એમ ધારવાને બદલે વાસ્તવિક Kafka ક્લાયન્ટ અને નેટવર્ક એકીકરણ તપાસો.
પ્રોક્સી-જાગૃત ક્લાયન્ટને સંબંધિત broker એન્ડપોઇન્ટ સુધી માન્ય માર્ગની જરૂર છે. નેટવર્ક-સ્તરની ગોઠવણને અનુરૂપ પહોંચ અને નામ ઉકેલની જરૂર છે. આ અલગ ડિઝાઇન છે, અને પ્રોક્સીને bootstrap સર્વર તરીકે યાદીમાં મૂકવાથી કોઈ પણ મળતું નથી.
સુરક્ષા પ્રોટોકોલ અને પ્રમાણીકરણ સેટિંગ્સ અલગ રાખો. પ્રોક્સી TCP માર્ગ સ્થાપિત કરી શકે છે જ્યારે TLS ઓળખ, SASL પ્રમાણીકરણ અથવા broker અધિકૃતિ હજી નિષ્ફળ જાય છે.
નિદાન માટે, કયો એન્ડપોઇન્ટ નિષ્ફળ ગયો અને તે સ્થિર રૂપરેખાંકનમાંથી આવ્યો કે પરત મળેલા મેટાડેટામાંથી તે નોંધો. તે ભેદ પહેલેથી પહોંચી શકાય તેવા એન્ડપોઇન્ટને વારંવાર બદલવા કરતાં સમસ્યાને ઘણી વધુ સાંકડી કરે છે.