Kafka د پروکسي له لارې: bootstrap کار کوي، خو د broker اړيکې ناکامېږي

د bootstrap اړیکه کېدای شي بریالۍ شي، په داسې حال کې چې Kafka کلاینټ لا هم نشي کولی تولید یا مصرف وکړي. Bootstrap سرورونه کلاینټ سره مرسته کوي چې کلسټر ومومي؛ دوی ممکن یوازینې هغه پای ټکي نه وي چې کلاینټ ورسره نښلوي.

د broker میټاډاټا هغه پتې لري چې د وروستیو اړیکو لپاره کارول کیږي. که هغه نومونه یا پورټونه د ټاکل شوي پروکسي لارې له لارې د لاسرسي وړ نه وي، لومړنۍ بریالۍ اړیکه پاتې کار نه حل کوي.

اعلان شوې پای ټکي ولولئ

د bootstrap پته له هغو broker پتو سره پرتله کړئ چې کلاینټ واقعاً ترلاسه کوي. یو عامه bootstrap مستعار نوم کېدای شي خصوصي اعلان شوو نومونو ته ورسوي، او د یو ځایي پورټ لیږدول په میټاډاټا کې هره پته په اتوماتيک ډول نه بیا لیکي.

هغه پروکسي لاره هم وپیژنئ چې د کلاینټ تطبیق یې ملاتړ کوي. د Java سیسټم SOCKS ځانګړتیا دا تضمین نه ده چې د کتابتون NIO پر بنسټ لیږد د JDK Socket پروکسي میکانیزم کاروي. د دې پرځای چې فرض کړئ هره Java سوکیټ ورته تنظیم مني، اصلي Kafka کلاینټ او شبکه یوځای کول وګورئ.

پروکسي پوهاوی لرونکي کلاینټ ته اړوند broker پای ټکو ته د اجازه ورکړل شوې لارې ته اړتیا ده. د شبکې کچې ترتیب ته اړونده لاسرسي او نوم حل ته اړتیا ده. دا جلا ډیزاینونه دي، او هیچا ته هم یوازې د پروکسي bootstrap سرور په توګه لیست کولو سره نه ورکول کیږي.

د امنیت پروتوکول او تصدیق تنظیمات جلا وساتئ. پروکسي کولی شي د TCP لاره جوړه کړي، په داسې حال کې چې TLS هویت، SASL تصدیق یا د broker اجازه لا هم ناکامېږي.

د تشخیص لپاره، یادونه وکړئ چې کوم پای ټکی ناکام شو او ایا هغه له ثابت ترتیب څخه راغی که له بیرته راګرځیدل شوو میټاډاټا څخه. دا توپیر ستونزه ډېره زیاته محدوده کوي، د هغه پای ټکي د تکراري بدلون په پرتله چې لا دمخه د لاسرسي وړ و.