Kafka caur starpniekserveri: bootstrap darbojas, brokeru savienojumi neizdodas
Izskaidro, kāpēc veiksmīgs Kafka bootstrap savienojums negarantē starpniekservera piekļuvi katram atklātajam brokerim.
Bootstrap savienojums var izdoties, kamēr Kafka klients joprojām nevar ražot vai patērēt. Bootstrap serveri palīdz klientam atklāt klasteri; tie ne vienmēr ir vienīgie galapunkti, ar kuriem tas savienosies.
Brokera metadatos ir adreses, kas tiek izmantotas vēlākiem savienojumiem. Ja šie nosaukumi vai porti nav sasniedzami paredzētajā starpniekservera maršrutā, pirmais veiksmīgais savienojums neatrisina pārējo darbu.
Izlasiet izziņotos galapunktus
Salīdziniet bootstrap adresi ar brokera adresēm, ko klients faktiski saņem. Publisks bootstrap aizstājvārds var novest pie privātiem izziņotiem nosaukumiem, un viena lokālā porta pāradresēšana automātiski nepārraksta katru metadatu adresi.
Nosakiet arī starpniekservera ceļu, ko atbalsta klienta ieviešana. Java sistēmas SOCKS īpašība negarantē, ka bibliotēkas uz NIO balstītā transportēšana izmanto JDK Socket starpniekservera mehānismu. Pārbaudiet faktisko Kafka klientu un tīkla integrāciju, nevis pieņemiet, ka katrs Java socket ievēro vienu un to pašu iestatījumu.
Starpniekserveri apzinātam klientam ir vajadzīgs atļauts maršruts uz attiecīgajiem brokera galapunktiem. Tīkla līmeņa risinājumam ir vajadzīga atbilstoša sasniedzamība un nosaukumu izšķiršana. Tie ir dažādi risinājumi, un neviens no tiem netiek nodrošināts, tikai uzskaitot starpniekserveri kā bootstrap serveri.
Turiet drošības protokola un autentifikācijas iestatījumus atsevišķi. Starpniekserveris var izveidot TCP ceļu, kamēr TLS identitāte, SASL autentifikācija vai brokera autorizācija joprojām neizdodas.
Diagnostikai atzīmējiet, kurš galapunkts neizdevās un vai tas nāca no statiskas konfigurācijas vai atgrieztiem metadatiem. Šī atšķirība daudz vairāk sašaurina problēmu nekā atkārtota jau sasniedzama galapunkta maiņa.