ການເຊື່ອມຕໍ່ bootstrap ອາດສຳເລັດໃນຂະນະທີ່ລູກຄ້າ Kafka ຍັງບໍ່ສາມາດຜະລິດ ຫຼື ບໍລິໂພກໄດ້. ເຊີບເວີ bootstrap ຊ່ວຍລູກຄ້າຄົ້ນພົບ cluster; ພວກມັນບໍ່ຈຳເປັນຈຸດປາຍທາງດຽວທີ່ລູກຄ້າຈະເຊື່ອມຕໍ່.

ເມຕາດາຕາຂອງ broker ມີທີ່ຢູ່ທີ່ໃຊ້ສຳລັບການເຊື່ອມຕໍ່ຕໍ່ໄປ. ຖ້າຊື່ ຫຼື ພອດເຫຼົ່ານັ້ນເຂົ້າເຖິງບໍ່ໄດ້ຜ່ານເສັ້ນທາງ proxy ທີ່ຕັ້ງໄວ້, ການເຊື່ອມຕໍ່ສຳເລັດທຳອິດບໍ່ໄດ້ແກ້ໄຂວຽກທີ່ເຫຼືອ.

ອ່ານຈຸດປາຍທາງທີ່ປະກາດ

ປຽບທຽບທີ່ຢູ່ bootstrap ກັບທີ່ຢູ່ broker ທີ່ລູກຄ້າໄດ້ຮັບຕົວຈິງ. ຊື່ສະແດງ bootstrap ສາທາລະນະອາດນຳໄປຫາຊື່ສ່ວນຕົວທີ່ປະກາດ, ແລະ ການສົ່ງຕໍ່ພອດທ້ອງຖິ່ນດຽວບໍ່ໄດ້ຂຽນທີ່ຢູ່ທຸກອັນໃນເມຕາດາຕາໃໝ່ໂດຍອັດຕະໂນມັດ.

ລະບຸເສັ້ນທາງ proxy ທີ່ການຈັດຕັ້ງລູກຄ້າຮອງຮັບດ້ວຍ. ຄຸນສົມບັດ SOCKS ຂອງລະບົບ Java ບໍ່ແມ່ນການຮັບປະກັນວ່າການຂົນສົ່ງຂອງຫ້ອງສະໝຸດທີ່ອີງໃສ່ NIO ໃຊ້ກົນໄກ proxy Socket ຂອງ JDK. ກວດສອບລູກຄ້າ Kafka ຕົວຈິງ ແລະ ການເຊື່ອມໂຍງເຄືອຂ່າຍ ແທນທີ່ຈະສົມມຸດວ່າທຸກ socket Java ເຄົາລົບການຕັ້ງຄ່າດຽວກັນ.

ລູກຄ້າທີ່ຮູ້ຈັກ proxy ຕ້ອງການເສັ້ນທາງທີ່ໄດ້ຮັບອະນຸຍາດໄປຫາຈຸດປາຍທາງ broker ທີ່ກ່ຽວຂ້ອງ. ການຈັດການລະດັບເຄືອຂ່າຍຕ້ອງການການເຂົ້າເຖິງ ແລະ ການແກ້ໄຂຊື່ທີ່ສອດຄ່ອງ. ເຫຼົ່ານີ້ເປັນການອອກແບບທີ່ແຕກຕ່າງ ແລະ ບໍ່ມີອັນໃດໄດ້ມາພຽງແຕ່ລະບຸ proxy ເປັນເຊີບເວີ bootstrap.

ແຍກການຕັ້ງຄ່າໂປຣໂຕຄອນຄວາມປອດໄພ ແລະ ການພິສູດຢືນຢັນອອກຈາກກັນ. proxy ສາມາດສ້າງເສັ້ນທາງ TCP ໃນຂະນະທີ່ຕົວຕົນ TLS, ການພິສູດຢືນຢັນ SASL ຫຼື ການອະນຸຍາດ broker ຍັງລົ້ມເຫລວ.

ສຳລັບການວິໄຈ, ບັນທຶກວ່າຈຸດປາຍທາງໃດລົ້ມເຫລວ ແລະ ມັນມາຈາກການຕັ້ງຄ່າຄົງທີ່ ຫຼື ຈາກເມຕາດາຕາທີ່ສົ່ງກັບມາ. ຄວາມແຕກຕ່າງນັ້ນເຮັດໃຫ້ບັນຫາແຄບລົງຫຼາຍກວ່າການປ່ຽນຈຸດປາຍທາງທີ່ເຂົ້າເຖິງໄດ້ແລ້ວຊ້ຳໆ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ