Kafka tra prokurilo: bootstrap funkcias, brokeraj konektoj malsukcesas
Klarigas kial sukcesa Kafka-bootstrap-konekto ne garantiass prokuran atingon al ĉiu malkovrita brokero.
Bootstrap-konekto povas sukcesi dum la Kafka-kliento ankoraŭ ne povas produkti aŭ konsumi. Bootstrap-serviloj helpas la klienton malkovri la klusteron; ili ne nepre estas la solaj finpunktoj, al kiuj ĝi konektiĝos.
Brokeraj metadatenoj enhavas adresojn uzatajn por postaj konektoj. Se tiuj nomoj aŭ pordoj neatingeblas tra la intencita prokura vojo, la unua sukcesa konekto ne solvas la reston de la tasko.
Legu la anoncitajn finpunktojn
Komparu la bootstrap-adreson kun la brokeraj adresoj, kiujn la kliento efektive ricevas. Publika bootstrap-kaŝnomo povas konduki al privataj anoncitaj nomoj, kaj plusendado de unu loka pordo ne aŭtomate reskribas ĉiun adreson en la metadatenoj.
Identigu ankaŭ la prokuran vojon, kiun subtenas la klienta efektivigo. Java-sistema SOCKS-atributo ne garantias, ke NIO-bazita transporto de biblioteko uzas la JDK-Socket-prokuran mekanismon. Kontrolu la faktan Kafka-klienton kaj la retan integriĝon anstataŭ supozi, ke ĉiu Java-ingo respektas la saman agordon.
Prokurkonscia kliento bezonas permesitan vojon al la koncernaj brokeraj finpunktoj. Retnivela aranĝo bezonas respondan atingeblon kaj nomrezolucion. Tiuj estas malsamaj dezajnoj, kaj neniu el ili proviziĝas nur per listigo de prokurilo kiel bootstrap-servilo.
Tenu sekurecprotokolajn kaj aŭtentigajn agordojn aparte. Prokurilo povas establi TCP-vojon dum TLS-identeco, SASL-aŭtentigo aŭ brokera rajtigo ankoraŭ malsukcesas.
Por diagnozo, notu kiun finpunkton malsukcesis kaj ĉu ĝi venis el statika agordo aŭ el redonitaj metadatenoj. Tiu distingo mallarĝigas la problemon multe pli ol ripeta ŝanĝado de finpunkto, kiu jam estis atingebla.