การเชื่อมต่อ bootstrap อาจสำเร็จได้ในขณะที่ไคลเอนต์ Kafka ยังไม่สามารถผลิตหรือบริโภคได้ เซิร์ฟเวอร์ bootstrap ช่วยให้ไคลเอนต์ค้นหาคลัสเตอร์ พวกมันไม่จำเป็นต้องเป็นปลายทางเดียวที่ไคลเอนต์จะเชื่อมต่อ

ข้อมูลเมตาของ broker มีที่อยู่ที่ใช้สำหรับการเชื่อมต่อในภายหลัง หากชื่อหรือพอร์ตเหล่านั้นเข้าถึงไม่ได้ผ่านเส้นทางพร็อกซีที่ตั้งใจไว้ การเชื่อมต่อแรกที่สำเร็จก็ไม่ได้แก้ไขงานที่เหลือ

อ่านปลายทางที่ประกาศ

เปรียบเทียบที่อยู่ bootstrap กับที่อยู่ broker ที่ไคลเอนต์ได้รับจริง นามแฝง bootstrap สาธารณะอาจนำไปสู่ชื่อที่ประกาศแบบส่วนตัว และการส่งต่อพอร์ตภายในเครื่องหนึ่งพอร์ตไม่ได้เขียนที่อยู่ทุกแห่งในข้อมูลเมตาใหม่โดยอัตโนมัติ

ระบุเส้นทางพร็อกซีที่การใช้งานไคลเอนต์รองรับด้วย คุณสมบัติ SOCKS ของระบบ Java ไม่ใช่การรับประกันว่าการขนส่งของไลบรารีที่อิง NIO จะใช้กลไกพร็อกซีของ JDK Socket ตรวจสอบไคลเอนต์ Kafka จริงและการรวมระบบเครือข่ายแทนการสันนิษฐานว่าซ็อกเก็ต Java ทุกตัวเคารพการตั้งค่าเดียวกัน

ไคลเอนต์ที่ตระหนักถึงพร็อกซีต้องมีเส้นทางที่ได้รับอนุญาตไปยังปลายทาง broker ที่เกี่ยวข้อง การจัดวางระดับเครือข่ายต้องมีการเข้าถึงและการแก้ชื่อที่สอดคล้องกัน สิ่งเหล่านี้เป็นการออกแบบที่แตกต่างกัน และทั้งสองไม่ได้มาจากการระบุพร็อกซีเป็นเซิร์ฟเวอร์ bootstrap เท่านั้น

แยกการตั้งค่าโปรโตคอลความปลอดภัยและการรับรองความถูกต้องออกจากกัน พร็อกซีสามารถสร้างเส้นทาง TCP ได้ในขณะที่ตัวตน TLS การรับรองความถูกต้อง SASL หรือการอนุญาต broker ยังล้มเหลว

สำหรับการวินิจฉัย ให้บันทึกว่าปลายทางใดล้มเหลว และมาจากการกำหนดค่าคงที่หรือข้อมูลเมตาที่ส่งกลับมา ความแตกต่างนั้นจำกัดปัญหาได้มากกว่าการเปลี่ยนปลายทางที่เข้าถึงได้อยู่แล้วซ้ำๆ

บทความที่เกี่ยวข้อง