Kafka-ն պրոքսիի միջով. bootstrap-ը աշխատում է, broker-ի միացումները ձախողվում են

Bootstrap միացումը կարող է հաջողվել, մինչդեռ Kafka հաճախորդը դեռ չի կարող արտադրել կամ սպառել։ Bootstrap սերվերները օգնում են հաճախորդին գտնել կլաստերը. դրանք պարտադիր չէ, որ միակ վերջնակետերն են, որոնց հետ նա կկապվի։

Broker-ի մետատվյալները պարունակում են հասցեներ, որոնք օգտագործվում են հետագա միացումների համար։ Եթե այդ անունները կամ պորտերը հասանելի չեն նախատեսված պրոքսի ուղով, առաջին հաջող միացումը չի լուծում աշխատանքի մնացած մասը։

Կարդացեք հայտարարված վերջնակետերը

Համեմատեք bootstrap հասցեն այն broker հասցեների հետ, որոնք հաճախորդը փաստացի ստանում է։ Հանրային bootstrap ծածկանունը կարող է տանել դեպի մասնավոր հայտարարված անուններ, և մեկ լոկալ պորտի փոխանցումը ինքնաշխատ չի վերագրում մետատվյալների յուրաքանչյուր հասցե։

Նաև որոշեք պրոքսի ուղին, որն աջակցում է հաճախորդի իրականացումը։ Java համակարգի SOCKS հատկությունը երաշխիք չէ, որ գրադարանի NIO-ի վրա հիմնված փոխադրումը օգտագործում է JDK Socket-ի պրոքսի մեխանիզմը։ Ստուգեք իրական Kafka հաճախորդը և ցանցային ինտեգրումը՝ փոխարենը ենթադրելու, որ յուրաքանչյուր Java socket հարգում է նույն կարգավորումը։

Պրոքսին տեղյակ հաճախորդին անհրաժեշտ է թույլատրված ուղի դեպի համապատասխան broker վերջնակետեր։ Ցանցային մակարդակի լուծումը պահանջում է համապատասխան հասանելիություն և անունների լուծում։ Դրանք տարբեր նախագծեր են, և ոչ մեկը չի տրամադրվում միայն պրոքսին որպես bootstrap սերվեր թվարկելով։

Անվտանգության արձանագրության և նույնականացման կարգավորումները պահեք առանձին։ Պրոքսին կարող է TCP ուղի ստեղծել, մինչդեռ TLS ինքնությունը, SASL նույնականացումը կամ broker-ի թույլտվությունը դեռ ձախողվում են։

Ախտորոշման համար նշեք, թե որ վերջնակետը ձախողվեց և արդյոք այն եկել է ստատիկ կոնֆիգուրացիայից, թե վերադարձված մետատվյալներից։ Այդ տարբերությունը շատ ավելի է նեղացնում խնդիրը, քան արդեն հասանելի վերջնակետի կրկնվող փոփոխությունը։