Kafka fia in proxy: bootstrap wurket, broker-ferbiningen mislearje
Ferkearet wêrom't in slagge Kafka-bootstrap-ferbining gjin proxy-tagong ta elke ûntdutsen broker garandearret.
In bootstrap-ferbining kin slagje wylst de Kafka-klient noch hieltyd net produsearje of konsumearje kin. Bootstrap-tsjinners helpe de klient it cluster te ûntdekken; se binne net needsaaklikerwize de iennichste einpunten dêr't er kontakt mei opnimt.
Broker-metadata befettet adressen dy't foar lettere ferbiningen brûkt wurde. As dy nammen of poarten net berikber binne fia de bedoelde proxy-route, lost de earste slagge ferbining de rest fan it wurk net op.
Lês de oankundige einpunten
Fergelykje it bootstrap-adres mei de broker-adressen dy't de klient eins krijt. In iepenbier bootstrap-alias kin liede ta privee oankundige nammen, en it trochstjoeren fan ien lokaal poart skriuwt net automatysk elk adres yn metadata oer.
Identifisearje ek it proxy-paad dat de klient-ymplemintaasje stipet. In Java-systeem-SOCKS-eigenskip is gjin garânsje dat in NIO-basearre transport fan in bibleteek it JDK Socket-proxymeganisme brûkt. Kontrolearje de eigentlike Kafka-klient en netwurkynjeraasje ynstee fan oan te nimmen dat elke Java-socket deselde ynstelling respektearret.
In proxy-bewuste klient hat in tastien route nei de oanbelangjende broker-einpunten nedich. In regeling op netwurknivo hat oerienkommende berikberens en namme-oplossing nedich. Dat binne ferskillende ûntwerpen, en gjin fan beide wurdt levere troch allinnich in proxy as bootstrap-tsjinner te listen.
Hâld de ynstellingen foar befeiligingsprotokol en autentikaasje skieden. In proxy kin in TCP-route meitsje wylst TLS-identiteit, SASL-autentikaasje of broker-autorisaasje noch hieltyd mislearje.
Notearje foar diagnostyk hokker einpunt mislearre en oft it út statyske konfiguraasje of út weromjûn metadata kaam. Dat ûnderskied beheint it probleem folle mear as it hieltyd feroarjen fan in einpunt dat al berikber wie.