В ບົດຄວາມສຸດທ້າຍ ພວກເຮົາໄດ້ເບິ່ງກຸ່ມ RabbitMQ ສໍາລັບຄວາມທົນທານຕໍ່ຄວາມຜິດພາດແລະຄວາມພ້ອມສູງ. ຕອນນີ້ໃຫ້ຂຸດເລິກເຂົ້າໄປໃນ Apache Kafka.

ທີ່ນີ້ຫົວຫນ່ວຍຂອງການຈໍາລອງແມ່ນການແບ່ງປັນ. ແຕ່ລະຫົວຂໍ້ມີຫນຶ່ງຫຼືຫຼາຍພາກ. ແຕ່ລະພາກສ່ວນມີຜູ້ນໍາມີຫຼືບໍ່ມີຜູ້ຕິດຕາມ. ເມື່ອສ້າງຫົວຂໍ້, ທ່ານລະບຸຈໍານວນພາທິຊັນແລະຄ່າສໍາປະສິດການຈໍາລອງ. ມູນຄ່າປົກກະຕິແມ່ນ 3, ຊຶ່ງຫມາຍຄວາມວ່າສາມ replicas: ຫນຶ່ງຜູ້ນໍາແລະສອງຜູ້ຕິດຕາມ.

ເຂົ້າ. 1. ສີ່ພາກສ່ວນແມ່ນແຈກຢາຍລະຫວ່າງສາມນາຍຫນ້າ

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

ການແບ່ງສ່ວນລົ້ມເຫຼວ

ເມື່ອນາຍຫນ້າລົ້ມເຫລວ, ຜູ້ນໍາຂອງຫຼາຍໆພາກສ່ວນມັກຈະລົ້ມເຫລວ. ໃນແຕ່ລະພວກມັນ, ຜູ້ຕິດຕາມຈາກໂຫນດອື່ນກາຍເປັນຜູ້ນໍາ. ໃນຄວາມເປັນຈິງ, ນີ້ບໍ່ແມ່ນກໍລະນີສະເຫມີ, ເນື່ອງຈາກວ່າປັດໄຈ synchronization ຍັງມີອິດທິພົນ: ບໍ່ວ່າຈະມີຜູ້ຕິດຕາມ synchronized, ແລະຖ້າບໍ່, ຫຼັງຈາກນັ້ນການປ່ຽນເປັນ replica unsynchronized ແມ່ນອະນຸຍາດໃຫ້. ແຕ່ບໍ່ໃຫ້ສິ່ງທີ່ສັບສົນສໍາລັບໃນປັດຈຸບັນ.

ນາຍຫນ້າ 3 ອອກຈາກເຄືອຂ່າຍ, ແລະຜູ້ນໍາໃຫມ່ຖືກເລືອກສໍາລັບພາກ 2 ຢູ່ນາຍຫນ້າ 2.

ເຂົ້າ. 2. ນາຍຫນ້າ 3 ເສຍຊີວິດແລະຜູ້ຕິດຕາມຂອງລາວໃນນາຍຫນ້າ 2 ຖືກເລືອກຕັ້ງເປັນຜູ້ນໍາໃຫມ່ຂອງ partition 2.

ຫຼັງຈາກນັ້ນ, ນາຍຫນ້າ 1 ໃບແລະພາກທີ 1 ຍັງສູນເສຍຜູ້ນໍາຂອງຕົນ, ພາລະບົດບາດຂອງນາຍຫນ້າໄດ້ຜ່ານ 2.

ເຂົ້າ. 3. ມີນາຍໜ້າຄົນໜຶ່ງເຫຼືອ. ຜູ້ນໍາທັງຫມົດແມ່ນຢູ່ໃນຫນຶ່ງນາຍຫນ້າທີ່ບໍ່ມີການຊ້ໍາຊ້ອນ

ເມື່ອນາຍຫນ້າ 1 ກັບມາອອນໄລນ໌, ມັນຈະເພີ່ມຜູ້ຕິດຕາມສີ່ຄົນ, ສະຫນອງການຊ້ໍາຊ້ອນບາງຢ່າງໃຫ້ກັບແຕ່ລະການແບ່ງປັນ. ແຕ່ຜູ້ນໍາທັງຫມົດຍັງຄົງຢູ່ໃນນາຍຫນ້າ 2.

ເຂົ້າ. 4. ຜູ້ນໍາຍັງຄົງຢູ່ໃນນາຍຫນ້າ 2

ເມື່ອນາຍຫນ້າ 3 ຂຶ້ນມາ, ພວກເຮົາກັບຄືນໄປບ່ອນສາມ replicas ຕໍ່ partition. ແຕ່ຜູ້ນໍາທັງຫມົດແມ່ນຍັງຢູ່ໃນນາຍຫນ້າ 2.

ເຂົ້າ. 5. ການຈັດວາງບໍ່ສົມດຸນຂອງຜູ້ນໍາຫຼັງຈາກການຟື້ນຟູນາຍຫນ້າ 1 ແລະ 3

Kafka ມີເຄື່ອງມືສໍາລັບການປັບສົມດຸນຜູ້ນໍາທີ່ດີກວ່າ RabbitMQ. ຢູ່ທີ່ນັ້ນ, ທ່ານຕ້ອງໃຊ້ plugin ພາກສ່ວນທີສາມຫຼື script ທີ່ປ່ຽນແປງນະໂຍບາຍສໍາລັບການເຄື່ອນຍ້າຍ master node ໂດຍການຫຼຸດຜ່ອນການຊ້ໍາຊ້ອນລະຫວ່າງການເຄື່ອນຍ້າຍ. ນອກຈາກນັ້ນ, ສໍາລັບແຖວຂະຫນາດໃຫຍ່, ພວກເຮົາຕ້ອງຍອມຮັບຄວາມບໍ່ມີຢູ່ໃນລະຫວ່າງການ synchronization.

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

ເພື່ອແກ້ໄຂບັນຫານີ້, Kafka ສະເຫນີສອງທາງເລືອກ:

• ທາງເລືອກ auto.leader.rebalance.enable=true ອະ​ນຸ​ຍາດ​ໃຫ້ node controller ອັດ​ຕະ​ໂນ​ມັດ​ມອບ​ຫມາຍ​ຜູ້​ນໍາ​ກັບ​ຄືນ​ໄປ​ບ່ອນ replicas ທີ່​ຕ້ອງ​ການ​ແລະ​ເຮັດ​ໃຫ້​ການ​ຟື້ນ​ຟູ​ການ​ແຜ່​ກະ​ຈາຍ​ເປັນ​ເອ​ກະ​ພາບ​.
• ຜູ້ບໍລິຫານສາມາດແລ່ນສະຄຣິບໄດ້ kafka-preferred-replica-election.sh ສໍາລັບການມອບຫມາຍໃຫມ່ດ້ວຍຕົນເອງ.

ເຂົ້າ. 6. Replicas ຫຼັງຈາກ rebalancing

ນີ້ແມ່ນສະບັບທີ່ງ່າຍດາຍຂອງຄວາມລົ້ມເຫລວ, ແຕ່ຄວາມເປັນຈິງແມ່ນສັບສົນຫຼາຍ, ເຖິງແມ່ນວ່າບໍ່ມີຫຍັງສັບສົນຫຼາຍຢູ່ທີ່ນີ້. ມັນທັງຫມົດມາລົງເພື່ອ synchronized replicas (In-Sync Replicas, ISR).

ສຳເນົາແບບຊິ້ງ (ISR)

ISR ແມ່ນຊຸດຂອງ replicas ຂອງພາທິຊັນທີ່ຖືວ່າເປັນ "synchronized" (in-sync). ມີຜູ້ນໍາ, ແຕ່ອາດຈະບໍ່ມີຜູ້ຕິດຕາມ. ຜູ້ຕິດຕາມແມ່ນຖືວ່າຖືກ ​​synchronized ຖ້າມັນເຮັດສໍາເນົາທີ່ແນ່ນອນຂອງຂໍ້ຄວາມຂອງຜູ້ນໍາທັງຫມົດກ່ອນທີ່ໄລຍະເວລາຈະຫມົດອາຍຸ. replica.lag.time.max.ms.

ຜູ້ຕິດຕາມຖືກໂຍກຍ້າຍອອກຈາກ ISR ທີ່ຕັ້ງໄວ້ຖ້າມັນ:

• ບໍ່​ໄດ້​ເຮັດ​ໃຫ້​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ເລືອກ​ສໍາ​ລັບ​ໄລ​ຍະ​ replica.lag.time.max.ms (ຄາດ​ວ່າ​ຕາຍ​)
• ບໍ່ໄດ້ຈັດການການປັບປຸງໃນລະຫວ່າງໄລຍະ replica.lag.time.max.ms (ຖືວ່າຊ້າ)

ຜູ້ຕິດຕາມເຮັດການຮ້ອງຂໍຕົວຢ່າງໃນໄລຍະເວລາ replica.fetch.wait.max.ms, ເຊິ່ງເລີ່ມຕົ້ນເປັນ 500ms.

ເພື່ອອະທິບາຍຢ່າງຊັດເຈນຈຸດປະສົງຂອງ ISR, ພວກເຮົາຈໍາເປັນຕ້ອງເບິ່ງການຢືນຢັນຈາກຜູ້ຜະລິດແລະບາງສະຖານະການທີ່ລົ້ມເຫລວ. ຜູ້ຜະລິດສາມາດເລືອກເວລາທີ່ນາຍຫນ້າສົ່ງການຢືນຢັນ:

• acks=0, ການຢືນຢັນບໍ່ໄດ້ຖືກສົ່ງ
• acks=1, ການຢືນຢັນຖືກສົ່ງຫຼັງຈາກຜູ້ນໍາໄດ້ຂຽນຂໍ້ຄວາມໄປຫາບັນທຶກທ້ອງຖິ່ນຂອງລາວ
• acks=all, ການຢືນຢັນຈະຖືກສົ່ງຫຼັງຈາກ replicas ທັງຫມົດໃນ ISR ໄດ້ຂຽນຂໍ້ຄວາມໄປຍັງບັນທຶກທ້ອງຖິ່ນ

ໃນຄໍາສັບພາສາ Kafka, ຖ້າ ISR ໄດ້ບັນທຶກຂໍ້ຄວາມ, ມັນແມ່ນ "ຫມັ້ນສັນຍາ". Acks=ທັງໝົດແມ່ນທາງເລືອກທີ່ປອດໄພທີ່ສຸດ, ແຕ່ຍັງເພີ່ມຄວາມລ່າຊ້າຕື່ມອີກ. ຂໍໃຫ້ເບິ່ງສອງຕົວຢ່າງຂອງຄວາມລົ້ມເຫລວແລະວິທີການທາງເລືອກ 'acks' ທີ່ແຕກຕ່າງກັນພົວພັນກັບແນວຄວາມຄິດ ISR.

Acks=1 ແລະ ISR

ໃນຕົວຢ່າງນີ້, ພວກເຮົາຈະເຫັນວ່າຖ້າຜູ້ນໍາບໍ່ລໍຖ້າຂໍ້ຄວາມຈາກຜູ້ຕິດຕາມທັງຫມົດຈະຖືກບັນທຶກໄວ້, ຫຼັງຈາກນັ້ນການສູນເສຍຂໍ້ມູນແມ່ນເປັນໄປໄດ້ຖ້າຜູ້ນໍາລົ້ມເຫລວ. ການນໍາທາງໄປຫາຜູ້ຕິດຕາມທີ່ບໍ່ໄດ້ຊິ້ງສາມາດຖືກເປີດໃຊ້ງານຫຼືປິດການໃຊ້ງານໂດຍການຕັ້ງຄ່າ ບໍ່ສະອາດ.leader.election.enable.

ໃນຕົວຢ່າງນີ້, ຜູ້ຜະລິດມີຄ່າ acks=1. ພາກສ່ວນໄດ້ຖືກແຈກຢາຍໃນທົ່ວສາມນາຍຫນ້າ. ນາຍຫນ້າ 3 ແມ່ນຢູ່ຫລັງ, ມັນ synchronized ກັບຜູ້ນໍາແປດວິນາທີກ່ອນຫນ້ານີ້ແລະໃນປັດຈຸບັນ 7456 ຂໍ້ຄວາມຢູ່ຫລັງ. ນາຍຫນ້າ 1 ມີພຽງແຕ່ຫນຶ່ງວິນາທີ. ຜູ້ຜະລິດຂອງພວກເຮົາສົ່ງຂໍ້ຄວາມແລະໄດ້ຮັບ ack ກັບຄືນໄປບ່ອນຢ່າງໄວວາ, ໂດຍບໍ່ມີການ overhead ຂອງຜູ້ຕິດຕາມຊ້າຫຼືຕາຍທີ່ຜູ້ນໍາບໍ່ໄດ້ລໍຖ້າ.

ເຂົ້າ. 7. ISR ກັບສາມ replicas

ນາຍຫນ້າ 2 ລົ້ມເຫລວແລະຜູ້ຜະລິດໄດ້ຮັບຄວາມຜິດພາດໃນການເຊື່ອມຕໍ່. ຫຼັງຈາກທີ່ຜູ້ນໍາຜ່ານໄປຫານາຍຫນ້າ 1, ພວກເຮົາສູນເສຍ 123 ຂໍ້ຄວາມ. ຜູ້ຕິດຕາມນາຍຫນ້າ 1 ແມ່ນສ່ວນຫນຶ່ງຂອງ ISR, ແຕ່ບໍ່ໄດ້ synchronized ຢ່າງເຕັມສ່ວນກັບຜູ້ນໍາໃນເວລາທີ່ມັນຫຼຸດລົງ.

ເຂົ້າ. 8. ຂໍ້​ຄວາມ​ຈະ​ສູນ​ເສຍ​ໄປ​ໃນ​ເວ​ລາ​ທີ່​ມັນ​ເກີດ​ອຸ​ປະ​ສັກ​

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

ເຂົ້າ. 9. ການສົ່ງຂໍ້ຄວາມສືບຕໍ່ຫຼັງຈາກພັກຜ່ອນສັ້ນໆ

ນາຍຫນ້າ 3 ແມ່ນຍັງຢູ່ຫລັງ. ມັນເຮັດການຮ້ອງຂໍການດຶງຂໍ້ມູນແຕ່ບໍ່ສາມາດ sync. ນີ້ອາດຈະເປັນຍ້ອນການເຊື່ອມຕໍ່ເຄືອຂ່າຍຊ້າລະຫວ່າງນາຍຫນ້າ, ບັນຫາການເກັບຮັກສາ, ແລະອື່ນໆ. ມັນຖືກໂຍກຍ້າຍອອກຈາກ ISR. ໃນປັດຈຸບັນ ISR ປະກອບດ້ວຍຫນຶ່ງ replica - ຜູ້ນໍາ! ຜູ້ຜະລິດສືບຕໍ່ສົ່ງຂໍ້ຄວາມແລະໄດ້ຮັບການຢືນຢັນ.

ເຂົ້າ. 10. ຜູ້ຕິດຕາມໃນນາຍຫນ້າ 3 ຖືກໂຍກຍ້າຍອອກຈາກ ISR

ນາຍຫນ້າ 1 ລົ້ມລົງແລະຫນ້າທີ່ຜູ້ນໍາໄປຫານາຍຫນ້າ 3 ກັບການສູນເສຍ 15286 ຂໍ້ຄວາມ! ຜູ້ຜະລິດໄດ້ຮັບຂໍ້ຄວາມຄວາມຜິດພາດການເຊື່ອມຕໍ່. ການຫັນປ່ຽນໄປສູ່ຜູ້ນໍານອກ ISR ແມ່ນເປັນໄປໄດ້ພຽງແຕ່ຍ້ອນການຕັ້ງຄ່າ unclean.leader.election.enable=true. ຖ້າມັນຖືກຕິດຕັ້ງຢູ່ໃນ ທີ່ບໍ່ຖືກຕ້ອງ, ຫຼັງຈາກນັ້ນການຫັນປ່ຽນຈະບໍ່ເກີດຂຶ້ນແລະການຮ້ອງຂໍການອ່ານແລະຂຽນທັງຫມົດຈະຖືກປະຕິເສດ. ໃນກໍລະນີນີ້, ພວກເຮົາລໍຖ້ານາຍຫນ້າ 1 ກັບຄືນມາດ້ວຍຂໍ້ມູນ intact ຂອງລາວໃນ replica, ເຊິ່ງຈະເປັນຜູ້ນໍາອີກເທື່ອຫນຶ່ງ.

ເຂົ້າ. 11. ນາຍໜ້າ 1 ຕົກ. ເມື່ອຄວາມລົ້ມເຫລວເກີດຂື້ນ, ຂໍ້ຄວາມຈໍານວນຫລາຍຈະສູນເສຍ

ຜູ້ຜະລິດສ້າງການເຊື່ອມຕໍ່ກັບນາຍຫນ້າສຸດທ້າຍແລະເຫັນວ່າລາວເປັນຜູ້ນໍາຂອງພາກສ່ວນ. ລາວເລີ່ມສົ່ງຂໍ້ຄວາມໄປຫານາຍຫນ້າ 3.

ເຂົ້າ. 12. ຫຼັງຈາກພັກຜ່ອນສັ້ນ, ຂໍ້ຄວາມຖືກສົ່ງອີກເທື່ອຫນຶ່ງໄປຫາພາກ 0

ພວກເຮົາໄດ້ເຫັນວ່າ, ນອກເຫນືອຈາກການຂັດຂວາງສັ້ນເພື່ອສ້າງການເຊື່ອມຕໍ່ໃຫມ່ແລະຄົ້ນຫາຜູ້ນໍາໃຫມ່, ຜູ້ຜະລິດກໍາລັງສົ່ງຂໍ້ຄວາມຢ່າງຕໍ່ເນື່ອງ. ການຕັ້ງຄ່ານີ້ຮັບປະກັນຄວາມພ້ອມໃນຄ່າໃຊ້ຈ່າຍຂອງຄວາມສອດຄ່ອງ (ຄວາມປອດໄພຂອງຂໍ້ມູນ). Kafka ໄດ້ສູນເສຍຫລາຍພັນຂໍ້ຄວາມແຕ່ຍັງສືບຕໍ່ຍອມຮັບການຂຽນໃຫມ່.

Acks=ທັງໝົດ ແລະ ISR

ໃຫ້ເຮັດຊ້ໍາສະຖານະການນີ້ອີກເທື່ອຫນຶ່ງ, ແຕ່ກັບ acks=ທັງໝົດ. ນາຍໜ້າ 3 ມີເວລາ latency ສະເລ່ຍສີ່ວິນາທີ. ຜູ້ຜະລິດສົ່ງຂໍ້ຄວາມກັບ acks=ທັງໝົດ, ແລະໃນປັດຈຸບັນບໍ່ໄດ້ຮັບການຕອບສະຫນອງໄວ. ຜູ້ນໍາລໍຖ້າຂໍ້ຄວາມທີ່ຈະຖືກບັນທຶກໄວ້ໂດຍ replicas ທັງຫມົດໃນ ISR.

ເຂົ້າ. 13. ISR ກັບສາມ replicas. ອັນຫນຶ່ງແມ່ນຊ້າ, ສົ່ງຜົນໃຫ້ການບັນທຶກການຊັກຊ້າ

ຫຼັງຈາກສີ່ວິນາທີຂອງການຊັກຊ້າເພີ່ມເຕີມ, ນາຍຫນ້າ 2 ສົ່ງ ack. ການຈຳລອງທັງໝົດໄດ້ຖືກປັບປຸງຢ່າງຄົບຖ້ວນແລ້ວ.

ເຂົ້າ. 14. replicas ທັງຫມົດບັນທຶກຂໍ້ຄວາມແລະສົ່ງ ack

ນາຍຫນ້າ 3 ໃນປັດຈຸບັນຕົກຢູ່ຫລັງຕື່ມອີກແລະຖືກໂຍກຍ້າຍອອກຈາກ ISR. Latency ແມ່ນຫຼຸດລົງຢ່າງຫຼວງຫຼາຍເນື່ອງຈາກບໍ່ມີຕົວແບບຊ້າໆທີ່ເຫຼືອຢູ່ໃນ ISR. ນາຍຫນ້າ 2 ໃນປັດຈຸບັນລໍຖ້າພຽງແຕ່ນາຍຫນ້າ 1, ແລະລາວມີ lag ສະເລ່ຍຂອງ 500 ms.

ເຂົ້າ. 15. ການຈໍາລອງໃນນາຍຫນ້າ 3 ຖືກໂຍກຍ້າຍອອກຈາກ ISR

ຫຼັງຈາກນັ້ນ, ນາຍຫນ້າ 2 ຕົກລົງແລະຜູ້ນໍາຜ່ານໄປຫານາຍຫນ້າ 1 ໂດຍບໍ່ມີການສູນເສຍຂໍ້ຄວາມ.

ເຂົ້າ. 16. ນາຍໜ້າ 2 ຕົກ

ຜູ້ຜະລິດຊອກຫາຜູ້ນໍາໃຫມ່ແລະເລີ່ມສົ່ງຂໍ້ຄວາມຫາລາວ. latency ແມ່ນຫຼຸດລົງຕື່ມອີກເພາະວ່າ ISR ໃນປັດຈຸບັນປະກອບດ້ວຍຫນຶ່ງ replica! ເພາະສະນັ້ນທາງເລືອກ acks=ທັງໝົດ ບໍ່ໄດ້ເພີ່ມການຊໍ້າຊ້ອນ.

ເຂົ້າ. 17. Replica on broker 1 ນໍາພາໂດຍບໍ່ມີການສູນເສຍຂໍ້ຄວາມ

ຫຼັງຈາກນັ້ນ, ນາຍຫນ້າ 1 crash ແລະນໍາໄປຫານາຍຫນ້າ 3 ກັບການສູນເສຍ 14238 ຂໍ້ຄວາມ!

ເຂົ້າ. 18. ນາຍໜ້າ 1 ຕາຍ ແລະ ການຫັນປ່ຽນການເປັນຜູ້ນຳດ້ວຍການຕັ້ງຄ່າທີ່ບໍ່ສະອາດ ສົ່ງຜົນໃຫ້ການສູນເສຍຂໍ້ມູນຢ່າງກວ້າງຂວາງ

ພວກເຮົາບໍ່ສາມາດຕິດຕັ້ງຕົວເລືອກໄດ້ ບໍ່ສະອາດ.leader.election.enable ເຂົ້າໄປໃນຄວາມຫມາຍ ທີ່ແທ້ຈິງ. ໂດຍຄ່າເລີ່ມຕົ້ນມັນເທົ່າກັບ ທີ່ບໍ່ຖືກຕ້ອງ. ການຕັ້ງຄ່າ acks=ທັງໝົດ с unclean.leader.election.enable=true ສະຫນອງການເຂົ້າເຖິງທີ່ມີຄວາມປອດໄພຂອງຂໍ້ມູນບາງອັນ. ແຕ່ຕາມທີ່ທ່ານສາມາດເຫັນໄດ້, ພວກເຮົາຍັງສາມາດສູນເສຍຂໍ້ຄວາມ.

ແຕ່ຈະເປັນແນວໃດຖ້າພວກເຮົາຕ້ອງການເພີ່ມຄວາມປອດໄພຂອງຂໍ້ມູນ? ທ່ານສາມາດໃສ່ unclean.leader.election.enable = ຜິດ, ແຕ່ນີ້ຈະບໍ່ຈໍາເປັນຕ້ອງປົກປ້ອງພວກເຮົາຈາກການສູນເສຍຂໍ້ມູນ. ຖ້າຜູ້ນໍາຫຼຸດລົງຢ່າງຫນັກແຫນ້ນແລະເອົາຂໍ້ມູນກັບມັນ, ຫຼັງຈາກນັ້ນຂໍ້ຄວາມຍັງສູນເສຍ, ບວກກັບຄວາມພ້ອມຈະສູນເສຍຈົນກ່ວາຜູ້ບໍລິຫານຈະຟື້ນຟູສະຖານະການ.

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

Acks=all, min.insync.replicas ແລະ ISR

ດ້ວຍ​ການ​ຕັ້ງ​ຄ່າ​ຫົວ​ຂໍ້​ min.insync.replicas ພວກເຮົາກໍາລັງເພີ່ມລະດັບຄວາມປອດໄພຂອງຂໍ້ມູນ. ໃຫ້ຂອງໄປໂດຍຜ່ານພາກສ່ວນສຸດທ້າຍຂອງສະຖານະການທີ່ຜ່ານມາອີກເທື່ອຫນຶ່ງ, ແຕ່ທີ່ໃຊ້ເວລານີ້ກັບ min.insync.replicas=2.

ດັ່ງນັ້ນນາຍຫນ້າ 2 ມີຜູ້ນໍາ replica ແລະຜູ້ຕິດຕາມກ່ຽວກັບນາຍຫນ້າ 3 ຖືກໂຍກຍ້າຍອອກຈາກ ISR.

ເຂົ້າ. 19. ISR ຈາກສອງ replicas

ນາຍຫນ້າ 2 ຕົກແລະຜູ້ນໍາຜ່ານໄປຫານາຍຫນ້າ 1 ໂດຍບໍ່ມີການສູນເສຍຂໍ້ຄວາມ. ແຕ່ໃນປັດຈຸບັນ ISR ປະກອບດ້ວຍພຽງແຕ່ຫນຶ່ງ replica. ນີ້ບໍ່ກົງກັບຈໍານວນຕໍາ່ສຸດທີ່ທີ່ຈະໄດ້ຮັບບັນທຶກ, ແລະດັ່ງນັ້ນນາຍຫນ້າຕອບສະຫນອງຕໍ່ຄວາມພະຍາຍາມຂຽນດ້ວຍຄວາມຜິດພາດ. NotEnoughReplicas.

ເຂົ້າ. 20. ຈໍານວນຂອງ ISRs ແມ່ນຫນຶ່ງຕ່ໍາກວ່າທີ່ລະບຸໄວ້ໃນ min.insync.replicas

ການ​ຕັ້ງ​ຄ່າ​ນີ້​ເສຍ​ສະ​ລະ​ການ​ມີ​ຢູ່​ສໍາ​ລັບ​ຄວາມ​ສອດ​ຄ່ອງ​. ກ່ອນທີ່ຈະຮັບຮູ້ຂໍ້ຄວາມ, ພວກເຮົາຮັບປະກັນວ່າມັນຖືກຂຽນເຖິງຢ່າງຫນ້ອຍສອງຕົວແບບຈໍາລອງ. ນີ້ເຮັດໃຫ້ຜູ້ຜະລິດມີຄວາມຫມັ້ນໃຈຫຼາຍຂຶ້ນ. ທີ່ນີ້, ການສູນເສຍຂໍ້ຄວາມແມ່ນເປັນໄປໄດ້ພຽງແຕ່ຖ້າຫາກວ່າສອງ replicas ລົ້ມເຫລວພ້ອມໆກັນໃນໄລຍະເວລາສັ້ນໆຈົນກ່ວາຂໍ້ຄວາມຈະຖືກ replicated ກັບຜູ້ຕິດຕາມເພີ່ມເຕີມ, ເຊິ່ງເປັນໄປບໍ່ໄດ້. ແຕ່ຖ້າທ່ານມີຄວາມວິຕົກກັງວົນທີ່ສຸດ, ທ່ານສາມາດກໍານົດປັດໄຈການຈໍາລອງເປັນ 5, ແລະ min.insync.replicas ໂດຍ 3. ນີ້ສາມນາຍຫນ້າຕ້ອງລົ້ມລົງໃນເວລາດຽວກັນເພື່ອສູນເສຍບັນທຶກ! ແນ່ນອນ, ທ່ານຈ່າຍສໍາລັບຄວາມຫນ້າເຊື່ອຖືນີ້ໃນ latency ເພີ່ມເຕີມ.

ໃນເວລາທີ່ການເຂົ້າເຖິງແມ່ນມີຄວາມຈໍາເປັນສໍາລັບຄວາມປອດໄພຂໍ້ມູນ

ຄືໃນ ກໍລະນີກັບ RabbitMQ, ບາງຄັ້ງການເຂົ້າເຖິງແມ່ນມີຄວາມຈໍາເປັນສໍາລັບຄວາມປອດໄພຂອງຂໍ້ມູນ. ນີ້ແມ່ນສິ່ງທີ່ທ່ານຕ້ອງຄິດກ່ຽວກັບ:

• ຜູ້ເຜີຍແພ່ສາມາດສົ່ງຄືນຄວາມຜິດພາດໄດ້ ແລະໃຫ້ການບໍລິການຂັ້ນຕົ້ນ ຫຼືຜູ້ໃຊ້ພະຍາຍາມອີກຄັ້ງໃນພາຍຫຼັງບໍ?
• ຜູ້ເຜີຍແຜ່ສາມາດບັນທຶກຂໍ້ຄວາມຢູ່ໃນທ້ອງຖິ່ນຫຼືໃນຖານຂໍ້ມູນເພື່ອລອງໃໝ່ໃນພາຍຫຼັງບໍ?

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

ຄວາມຫມາຍຂອງ ISR

ຊຸດ ISR ຊ່ວຍໃຫ້ທ່ານສາມາດເລືອກຄວາມສົມດູນທີ່ດີທີ່ສຸດລະຫວ່າງຄວາມປອດໄພຂອງຂໍ້ມູນແລະການແຝງເວລາ. ຕົວຢ່າງ, ຮັບປະກັນຄວາມພ້ອມໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວຂອງ replicas ສ່ວນໃຫຍ່, ຫຼຸດຜ່ອນຜົນກະທົບຂອງ replicas ຕາຍຫຼືຊ້າໃນແງ່ຂອງ latency.

ພວກເຮົາເລືອກຄວາມຫມາຍຕົວເຮົາເອງ replica.lag.time.max.ms ຕາມ​ຄວາມ​ຕ້ອງ​ການ​ຂອງ​ທ່ານ​. ໂດຍພື້ນຖານແລ້ວ, ພາລາມິເຕີນີ້ຫມາຍຄວາມວ່າມີຄວາມຊັກຊ້າຫຼາຍປານໃດທີ່ພວກເຮົາເຕັມໃຈທີ່ຈະຍອມຮັບເວລາ acks=ທັງໝົດ. ຄ່າເລີ່ມຕົ້ນແມ່ນສິບວິນາທີ. ຖ້າມັນຍາວເກີນໄປສໍາລັບທ່ານ, ທ່ານສາມາດຫຼຸດຜ່ອນມັນໄດ້. ຫຼັງຈາກນັ້ນ, ຄວາມຖີ່ຂອງການປ່ຽນແປງໃນ ISR ຈະເພີ່ມຂຶ້ນ, ນັບຕັ້ງແຕ່ຜູ້ຕິດຕາມຈະຖືກໂຍກຍ້າຍແລະເພີ່ມເລື້ອຍໆ.

RabbitMQ ແມ່ນພຽງແຕ່ຊຸດຂອງກະຈົກທີ່ຕ້ອງໄດ້ຮັບການ replicated. ກະຈົກຊ້າແນະນໍາການຊັກຊ້າເພີ່ມເຕີມ, ແລະກະຈົກທີ່ຕາຍແລ້ວສາມາດລໍຖ້າຈົນກ່ວາແພັກເກັດທີ່ກວດເບິ່ງຄວາມພ້ອມຂອງແຕ່ລະ node (ຫມາຍຕິກສຸດທິ) ເພື່ອຕອບສະຫນອງ. ISR ເປັນວິທີທີ່ຫນ້າສົນໃຈເພື່ອຫຼີກເວັ້ນບັນຫາ latency ເຫຼົ່ານີ້. ແຕ່ພວກເຮົາມີຄວາມສ່ຽງທີ່ຈະສູນເສຍການຊ້ໍາຊ້ອນນັບຕັ້ງແຕ່ ISR ສາມາດຫຼຸດລົງພຽງແຕ່ຜູ້ນໍາ. ເພື່ອຫຼີກເວັ້ນຄວາມສ່ຽງນີ້, ໃຊ້ການຕັ້ງຄ່າ min.insync.replicas.

ການຮັບປະກັນການເຊື່ອມຕໍ່ລູກຄ້າ

ໃນການຕັ້ງຄ່າ bootstrap.servers ຜູ້ຜະລິດແລະຜູ້ບໍລິໂພກສາມາດກໍານົດນາຍຫນ້າຫຼາຍສໍາລັບການເຊື່ອມຕໍ່ລູກຄ້າ. ແນວຄວາມຄິດແມ່ນວ່າເມື່ອຫນຶ່ງ node ລົງ, ມີຫຼາຍອັນທີ່ເຫລືອໄວ້ທີ່ລູກຄ້າສາມາດເປີດການເຊື່ອມຕໍ່ໄດ້. ເຫຼົ່ານີ້ແມ່ນບໍ່ຈໍາເປັນຜູ້ນໍາພາກ, ແຕ່ພຽງແຕ່ເປັນ springboard ສໍາລັບການໂຫຼດເບື້ອງຕົ້ນ. ລູກ​ຄ້າ​ສາ​ມາດ​ຖາມ​ເຂົາ​ເຈົ້າ​ວ່າ node hosts ຜູ້​ນໍາ​ການ​ອ່ານ / ຂຽນ​ພາ​ທິ​ຊັນ​.

ໃນ RabbitMQ, ລູກຄ້າສາມາດເຊື່ອມຕໍ່ກັບ node ໃດ, ແລະເສັ້ນທາງພາຍໃນສົ່ງຄໍາຮ້ອງຂໍໄປບ່ອນທີ່ມັນຈໍາເປັນຕ້ອງໄປ. ນີ້ຫມາຍຄວາມວ່າທ່ານສາມາດຕິດຕັ້ງ load balancer ຢູ່ທາງຫນ້າຂອງ RabbitMQ. Kafka ຮຽກຮ້ອງໃຫ້ລູກຄ້າເຊື່ອມຕໍ່ກັບ node ທີ່ເປັນເຈົ້າພາບຜູ້ນໍາພາທິຊັນທີ່ສອດຄ້ອງກັນ. ໃນສະຖານະການດັ່ງກ່າວ, ທ່ານບໍ່ສາມາດຕິດຕັ້ງ load balancer ໄດ້. ລາຍການ bootstrap.servers ມັນເປັນສິ່ງສໍາຄັນທີ່ລູກຄ້າສາມາດເຂົ້າເຖິງແລະຊອກຫາຂໍ້ທີ່ຖືກຕ້ອງຫຼັງຈາກຄວາມລົ້ມເຫລວ.

ສະຖາປັດຕະຍະກໍາ Kafka Consensus

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

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

Zookeeper ເກັບຮັກສາສະຖານະຂອງກຸ່ມ:

• ບັນຊີລາຍຊື່ຂອງຫົວຂໍ້, ພາກສ່ວນ, ການຕັ້ງຄ່າ, replicas ຜູ້ນໍາໃນປະຈຸບັນ, replicas ທີ່ຕ້ອງການ.
• ສະມາຊິກກຸ່ມ. ແຕ່ລະນາຍໜ້າ pings ກຸ່ມ Zookeeper. ຖ້າມັນບໍ່ໄດ້ຮັບ ping ພາຍໃນໄລຍະເວລາທີ່ກໍານົດໄວ້, Zookeeper ບັນທຶກນາຍຫນ້າວ່າບໍ່ສາມາດໃຊ້ໄດ້.
• ການ​ເລືອກ​ຂໍ້​ມູນ​ຕົ້ນ​ຕໍ​ແລະ​ອຸ​ປະ​ກອນ​ສໍາ​ລັບ​ການ​ຄວບ​ຄຸມ​.

ໂຫນດຄວບຄຸມແມ່ນຫນຶ່ງໃນນາຍຫນ້າ Kafka ທີ່ຮັບຜິດຊອບໃນການເລືອກຕັ້ງຜູ້ນໍາແບບຈໍາລອງ. Zookeeper ສົ່ງການແຈ້ງເຕືອນໃຫ້ຜູ້ຄວບຄຸມກ່ຽວກັບການເປັນສະມາຊິກຂອງກຸ່ມແລະການປ່ຽນແປງຫົວຂໍ້, ແລະຜູ້ຄວບຄຸມຕ້ອງປະຕິບັດການປ່ຽນແປງເຫຼົ່ານີ້.

ຕົວຢ່າງ, ໃຫ້ເອົາຫົວຂໍ້ໃຫມ່ທີ່ມີສິບພາທິຊັນແລະປັດໄຈການຈໍາລອງຂອງ 3. ຜູ້ຄວບຄຸມຕ້ອງເລືອກຜູ້ນໍາສໍາລັບແຕ່ລະພາທິຊັນ, ພະຍາຍາມແຈກຢາຍຜູ້ນໍາທີ່ດີທີ່ສຸດໃນບັນດານາຍຫນ້າ.

ສໍາ​ລັບ​ການ​ຄວບ​ຄຸມ​ແຕ່​ລະ​ພາກ​ສ່ວນ​:

• ປັບປຸງຂໍ້ມູນໃນ Zookeeper ກ່ຽວກັບ ISR ແລະຜູ້ນໍາ;
• ສົ່ງ LeaderAndISRCommand ໄປຫາແຕ່ລະນາຍຫນ້າທີ່ເປັນເຈົ້າພາບ replica ຂອງ partition ນີ້, ແຈ້ງໃຫ້ນາຍຫນ້າກ່ຽວກັບ ISR ແລະຜູ້ນໍາ.

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

ຜູ້ນໍາແຕ່ລະຄົນມີຄວາມຮັບຜິດຊອບໃນການທົດແທນ ISRs. ການຕັ້ງຄ່າ replica.lag.time.max.ms ກໍານົດຜູ້ທີ່ຈະເຂົ້າໄປໃນບ່ອນນັ້ນ. ເມື່ອ ISR ປ່ຽນແປງ, ຜູ້ນໍາສົ່ງຂໍ້ມູນໃຫມ່ໄປຫາ Zookeeper.

Zookeeper ໄດ້ຖືກແຈ້ງໃຫ້ຊາບສະເຫມີກ່ຽວກັບການປ່ຽນແປງໃດໆເພື່ອວ່າໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວ, ການຄຸ້ມຄອງການຫັນປ່ຽນໄປສູ່ຜູ້ນໍາໃຫມ່ຢ່າງລຽບງ່າຍ.

ເຂົ້າ. 21. Kafka Consensus

ອະນຸສັນຍາການຈຳລອງ

ຄວາມເຂົ້າໃຈລາຍລະອຽດຂອງການຈໍາລອງຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈສະຖານະການສູນເສຍຂໍ້ມູນທີ່ເປັນໄປໄດ້.

ການສອບຖາມຕົວຢ່າງ, Log End Offset (LEO) ແລະ Highwater Mark (HW)

ພວກເຮົາໄດ້ພິຈາລະນາວ່າຜູ້ຕິດຕາມສົ່ງຄໍາຮ້ອງຂໍການດຶງໄປຫາຜູ້ນໍາເປັນໄລຍະ. ໄລຍະຫ່າງເລີ່ມຕົ້ນແມ່ນ 500ms. ນີ້ແຕກຕ່າງຈາກ RabbitMQ ໃນທີ່ການຈໍາລອງ RabbitMQ ບໍ່ໄດ້ຖືກເລີ່ມຕົ້ນໂດຍບ່ອນແລກປ່ຽນຄວາມຄິວແຕ່ໂດຍແມ່ບົດ. ແມ່ບົດຍູ້ການປ່ຽນແປງກັບກະຈົກ.

ຜູ້ນໍາແລະຜູ້ຕິດຕາມທັງຫມົດບັນທຶກປ້າຍບັນທຶກການສິ້ນສຸດ (LEO) ແລະປ້າຍ Highwater (HW). ເຄື່ອງຫມາຍ LEO ເກັບຮັກສາການຊົດເຊີຍຂອງຂໍ້ຄວາມສຸດທ້າຍໃນ replica ທ້ອງຖິ່ນ, ແລະ HW ຖືການຊົດເຊີຍຂອງຄໍາຫມັ້ນສັນຍາສຸດທ້າຍ. ຈື່ໄວ້ວ່າສໍາລັບສະຖານະຄໍາຫມັ້ນສັນຍາ, ຂໍ້ຄວາມຕ້ອງໄດ້ຮັບການຄົງຢູ່ໃນທົ່ວທຸກ replicas ISR. ນີ້ຫມາຍຄວາມວ່າ LEO ມັກຈະນໍາຫນ້າ HW ເລັກນ້ອຍ.

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

ໃຫ້ສັງເກດວ່າ "ຄົງຢູ່" ຫມາຍຄວາມວ່າຂຽນໃສ່ຫນ່ວຍຄວາມຈໍາ, ບໍ່ແມ່ນໃສ່ແຜ່ນ. ສໍາລັບການປະຕິບັດ, Kafka synchronizes ກັບ disk ໃນໄລຍະສະເພາະໃດຫນຶ່ງ. RabbitMQ ຍັງມີຊ່ວງເວລາດັ່ງກ່າວ, ແຕ່ມັນຈະສົ່ງການຮັບຮູ້ກັບຜູ້ເຜີຍແຜ່ພຽງແຕ່ຫຼັງຈາກແມ່ບົດແລະກະຈົກທັງຫມົດໄດ້ຂຽນຂໍ້ຄວາມໃສ່ແຜ່ນ. ນັກພັດທະນາ Kafka, ສໍາລັບເຫດຜົນການປະຕິບັດ, ຕັດສິນໃຈສົ່ງ ack ທັນທີທີ່ຂໍ້ຄວາມຖືກຂຽນລົງໃນຄວາມຊົງຈໍາ. ການເດີມພັນ Kafka ທີ່ຊໍ້າຊ້ອນຈະຊົດເຊີຍຄວາມສ່ຽງຕໍ່ການເກັບຮັກສາຂໍ້ຄວາມທີ່ຮັບຮູ້ໂດຍຫຍໍ້ໃນຄວາມຊົງຈໍາເທົ່ານັ້ນ.

ຄວາມລົ້ມເຫຼວຂອງຜູ້ນໍາ

ເມື່ອຜູ້ນໍາລົ້ມ, Zookeeper ແຈ້ງເຕືອນຜູ້ຄວບຄຸມ, ແລະມັນເລືອກຕົວແບບຜູ້ນໍາໃຫມ່. ຜູ້ນໍາໃຫມ່ກໍານົດເຄື່ອງຫມາຍ HW ໃຫມ່ຕາມ LEO ຂອງລາວ. ຜູ້ຕິດຕາມຫຼັງຈາກນັ້ນໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບຜູ້ນໍາໃຫມ່. ອີງຕາມສະບັບຂອງ Kafka, ຜູ້ຕິດຕາມຈະເລືອກເອົາຫນຶ່ງໃນສອງສະຖານະການ:

1. ມັນຈະຕັດບັນທຶກທ້ອງຖິ່ນໄປຫາ HW ທີ່ຮູ້ຈັກແລະສົ່ງຄໍາຮ້ອງຂໍໃຫ້ຜູ້ນໍາໃຫມ່ສໍາລັບຂໍ້ຄວາມຫຼັງຈາກເຄື່ອງຫມາຍນີ້.
2. ຈະສົ່ງຄໍາຮ້ອງຂໍໄປຫາຜູ້ນໍາເພື່ອຊອກຫາ HW ໃນເວລາທີ່ລາວຖືກເລືອກຕັ້ງເປັນຜູ້ນໍາ, ແລະຫຼັງຈາກນັ້ນຕັດບັນທຶກການຊົດເຊີຍນີ້. ຈາກນັ້ນມັນຈະເລີ່ມເຮັດການຮ້ອງຂໍການດຶງຂໍ້ມູນເປັນໄລຍະເລີ່ມຈາກການຊົດເຊີຍນີ້.

ຜູ້ຕິດຕາມອາດຈະຈໍາເປັນຕ້ອງຕັດບັນທຶກສໍາລັບເຫດຜົນຕໍ່ໄປນີ້:

• ເມື່ອຜູ້ນໍາລົ້ມເຫລວ, ຜູ້ຕິດຕາມທໍາອິດໃນຊຸດ ISR ທີ່ລົງທະບຽນກັບ Zookeeper ຊະນະການເລືອກຕັ້ງແລະກາຍເປັນຜູ້ນໍາ. ຜູ້ຕິດຕາມທັງຫມົດໃນ ISR, ເຖິງແມ່ນວ່າຖືກພິຈາລະນາວ່າ "ຢູ່ໃນ sync," ອາດຈະບໍ່ໄດ້ຮັບສໍາເນົາຂໍ້ຄວາມທັງຫມົດຈາກອະດີດຜູ້ນໍາ. ມັນເປັນໄປໄດ້ທັງໝົດທີ່ຜູ້ຕິດຕາມທີ່ໂດດເດັ່ນບໍ່ມີສຳເນົາທີ່ທັນສະໄໝທີ່ສຸດ. Kafka ຮັບປະກັນວ່າບໍ່ມີຄວາມແຕກຕ່າງກັນລະຫວ່າງ replicas. ດັ່ງນັ້ນ, ເພື່ອຫຼີກເວັ້ນຄວາມແຕກຕ່າງ, ຜູ້ຕິດຕາມແຕ່ລະຄົນຕ້ອງຕັດບັນທຶກຂອງມັນໃຫ້ກັບມູນຄ່າ HW ຂອງຜູ້ນໍາໃຫມ່ໃນເວລາເລືອກຕັ້ງຂອງລາວ. ນີ້ແມ່ນເຫດຜົນອີກອັນຫນຶ່ງທີ່ເຮັດໃຫ້ການຕັ້ງຄ່າ acks=ທັງໝົດ ສໍາຄັນຫຼາຍສໍາລັບຄວາມສອດຄ່ອງ.
• ຂໍ້ຄວາມຖືກຂຽນເປັນໄລຍະໆໃສ່ແຜ່ນ. ຖ້າທຸກ nodes cluster ລົ້ມເຫລວໃນເວລາດຽວກັນ, replicas with different offsets will be stored on the disks. ມັນເປັນໄປໄດ້ວ່າເມື່ອນາຍຫນ້າກັບມາອອນໄລນ໌, ຜູ້ນໍາໃຫມ່ທີ່ຖືກເລືອກຕັ້ງຈະຢູ່ຫລັງຜູ້ຕິດຕາມຂອງລາວຍ້ອນວ່າລາວຖືກບັນທຶກໄວ້ໃນແຜ່ນກ່ອນຄົນອື່ນ.

Reunion ກັບກຸ່ມ

ເມື່ອເຂົ້າຮ່ວມກຸ່ມຄືນໃໝ່, ຕົວແບບຈໍາລອງເຮັດເຊັ່ນດຽວກັນກັບເວລາທີ່ຜູ້ນໍາລົ້ມເຫລວ: ພວກເຂົາກວດເບິ່ງການຈໍາລອງຂອງຜູ້ນໍາແລະຕັດບັນທຶກຂອງພວກເຂົາໄປຫາ HW ຂອງມັນ (ໃນເວລາເລືອກຕັ້ງ). ໃນການປຽບທຽບ, RabbitMQ ປະຕິບັດຢ່າງເທົ່າທຽມກັນກັບຂໍ້ທີ່ລວມກັນເປັນອັນໃຫມ່ຫມົດ. ໃນທັງສອງກໍລະນີ, ນາຍຫນ້າຈະຍົກເລີກລັດທີ່ມີຢູ່. ຖ້າການ synchronization ອັດຕະໂນມັດຖືກນໍາໃຊ້, ຫຼັງຈາກນັ້ນແມ່ບົດຕ້ອງ replicate ຢ່າງແທ້ຈິງເນື້ອໃນໃນປະຈຸບັນທັງຫມົດກັບກະຈົກໃຫມ່ໃນວິທີການ "ໃຫ້ໂລກທັງຫມົດລໍຖ້າ". ແມ່ບົດບໍ່ຍອມຮັບການປະຕິບັດການອ່ານຫຼືຂຽນໃດໆໃນລະຫວ່າງການປະຕິບັດການນີ້. ວິທີການນີ້ສ້າງບັນຫາໃນແຖວຂະຫນາດໃຫຍ່.

Kafka ແມ່ນບັນທຶກທີ່ແຈກຢາຍ, ແລະໂດຍທົ່ວໄປມັນເກັບຮັກສາຂໍ້ຄວາມຫຼາຍກ່ວາແຖວ RabbitMQ, ບ່ອນທີ່ຂໍ້ມູນຖືກໂຍກຍ້າຍອອກຈາກແຖວຫຼັງຈາກອ່ານ. ຄິວທີ່ໃຊ້ວຽກຄວນຈະຍັງຂ້ອນຂ້າງນ້ອຍ. ແຕ່ Kafka ແມ່ນໄມ້ທ່ອນທີ່ມີນະໂຍບາຍການເກັບຮັກສາຂອງຕົນເອງ, ເຊິ່ງສາມາດກໍານົດໄລຍະເວລາຂອງມື້ຫຼືອາທິດ. ວິທີການຂັດຂວາງແຖວແລະວິທີການ synchronization ຢ່າງເຕັມທີ່ແມ່ນບໍ່ສາມາດຍອມຮັບໄດ້ຢ່າງແທ້ຈິງສໍາລັບບັນທຶກທີ່ແຈກຢາຍ. ແທນທີ່ຈະ, ຜູ້ຕິດຕາມ Kafka ພຽງແຕ່ຕັດບັນທຶກຂອງພວກເຂົາໄປຫາ HW ຂອງຜູ້ນໍາ (ໃນເວລາການເລືອກຕັ້ງຂອງລາວ) ຖ້າສໍາເນົາຂອງພວກເຂົາແມ່ນຢູ່ຂ້າງຫນ້າຂອງຜູ້ນໍາ. ໃນກໍລະນີທີ່ເປັນໄປໄດ້, ເມື່ອຜູ້ຕິດຕາມຢູ່ເບື້ອງຫຼັງ, ມັນພຽງແຕ່ເລີ່ມຕົ້ນການຮ້ອງຂໍການດຶງຂໍ້ມູນເລີ່ມຕົ້ນດ້ວຍ LEO ໃນປະຈຸບັນຂອງມັນ.

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

ການສູນເສຍການເຊື່ອມຕໍ່

Kafka ມີອົງປະກອບຫຼາຍກ່ວາ RabbitMQ, ດັ່ງນັ້ນມັນມີຊຸດພຶດຕິກໍາທີ່ສັບສົນຫຼາຍເມື່ອກຸ່ມຖືກຕັດການເຊື່ອມຕໍ່. ແຕ່ Kafka ໄດ້ຖືກອອກແບບໃນເບື້ອງຕົ້ນສໍາລັບກຸ່ມ, ດັ່ງນັ້ນວິທີແກ້ໄຂໄດ້ຖືກຄິດອອກໄດ້ດີຫຼາຍ.

ຂ້າງລຸ່ມນີ້ແມ່ນສະຖານະການຄວາມລົ້ມເຫຼວຂອງການເຊື່ອມຕໍ່ຈໍານວນຫນຶ່ງ:

• ສະຖານະການທີ 1: ຜູ້ຕິດຕາມບໍ່ເຫັນຜູ້ນຳ, ແຕ່ຍັງເຫັນຜູ້ຮັກສາສັດຢູ່.
• ສະຖານະການທີ 2: ຜູ້ນໍາບໍ່ເຫັນຜູ້ຕິດຕາມ, ແຕ່ຍັງເຫັນ Zookeeper.
• ສະຖານະການທີ 3: ຜູ້ຕິດຕາມເຫັນຜູ້ນໍາ, ແຕ່ບໍ່ເຫັນຜູ້ຮັກສາສັດ.
• ສະຖານະການ 4: ຜູ້ນໍາເຫັນຜູ້ຕິດຕາມ, ແຕ່ບໍ່ເຫັນ Zookeeper.
• ສະຖານະການ 5: ຜູ້ຕິດຕາມແມ່ນແຍກອອກຈາກທັງສອງຂໍ້ Kafka ອື່ນໆແລະ Zookeeper.
• ສະຖານະການ 6: ຜູ້ນໍາໄດ້ຖືກແຍກອອກຈາກທັງສອງຂໍ້ Kafka ອື່ນໆແລະ Zookeeper.
• ສະຖານະການທີ 7: ໂນດຕົວຄວບຄຸມ Kafka ບໍ່ສາມາດເຫັນໂຫນດ Kafka ອື່ນໄດ້.
• ສະຖານະການທີ 8: ຕົວຄວບຄຸມ Kafka ບໍ່ເຫັນ Zookeeper.

ແຕ່ລະສະຖານະການມີພຶດຕິກໍາຂອງຕົນເອງ.

ສະຖານະການທີ 1: ຜູ້ຕິດຕາມບໍ່ເຫັນຜູ້ນຳ, ແຕ່ຍັງຄົງເຫັນ Zookeeper

ເຂົ້າ. 22. ສະຖານະການ 1: ISR ຂອງສາມ replicas

ຄວາມລົ້ມເຫຼວຂອງການເຊື່ອມຕໍ່ແຍກນາຍຫນ້າ 3 ຈາກນາຍຫນ້າ 1 ແລະ 2, ແຕ່ບໍ່ແມ່ນຈາກ Zookeeper. ນາຍໜ້າ 3 ບໍ່ສາມາດສົ່ງຄຳຮ້ອງຂໍການດຶງຂໍ້ມູນໄດ້ອີກຕໍ່ໄປ. ຫຼັງຈາກເວລາຜ່ານໄປ replica.lag.time.max.ms ມັນຖືກລຶບອອກຈາກ ISR ແລະບໍ່ໄດ້ເຂົ້າຮ່ວມໃນຄໍາຫມັ້ນສັນຍາຂໍ້ຄວາມ. ເມື່ອການເຊື່ອມຕໍ່ຖືກຟື້ນຟູ, ມັນຈະສືບຕໍ່ການຮ້ອງຂໍການດຶງຂໍ້ມູນແລະເຂົ້າຮ່ວມ ISR ເມື່ອມັນພົບກັບຜູ້ນໍາ. Zookeeper ຈະສືບຕໍ່ໄດ້ຮັບ pings ແລະສົມມຸດວ່ານາຍຫນ້າແມ່ນມີຊີວິດຢູ່ແລະດີ.

ເຂົ້າ. 23. ສະຖານະການທີ 1: ນາຍໜ້າຈະຖືກລຶບອອກຈາກ ISR ຖ້າບໍ່ມີການຮ້ອງຂໍການດຶງຂໍ້ມູນຈາກມັນພາຍໃນໄລຍະ replica.lag.time.max.ms.

ບໍ່ມີການລະງັບສະໝອງ ຫຼື ໂຫນດຄືໃນ RabbitMQ. ແທນທີ່ຈະ, ການຊໍ້າຊ້ອນແມ່ນຫຼຸດລົງ.

ສະຖານະການທີ 2: ຜູ້ນໍາບໍ່ເຫັນຜູ້ຕິດຕາມໃດໆ, ແຕ່ຍັງຄົງເຫັນ Zookeeper

ເຂົ້າ. 24. ສະຖານະການ 2. ຜູ້ນໍາແລະຜູ້ຕິດຕາມສອງຄົນ

ການແບ່ງແຍກໃນການເຊື່ອມຕໍ່ເຄືອຂ່າຍແຍກຜູ້ນໍາຈາກຜູ້ຕິດຕາມ, ແຕ່ນາຍຫນ້າຍັງສາມາດເຫັນ Zookeeper. ເຊັ່ນດຽວກັນກັບສະຖານະການທໍາອິດ, ISR ຫຼຸດລົງ, ແຕ່ເວລານີ້ພຽງແຕ່ໄປຫາຜູ້ນໍາເທົ່ານັ້ນຍ້ອນວ່າຜູ້ຕິດຕາມທັງຫມົດຢຸດເຊົາການສົ່ງຄໍາຮ້ອງຂໍການດຶງຂໍ້ມູນ. ອີກເທື່ອຫນຶ່ງ, ບໍ່ມີການແບ່ງອອກຢ່າງມີເຫດຜົນ. ແທນທີ່ຈະ, ມີການສູນເສຍຊ້ໍາຊ້ອນສໍາລັບຂໍ້ຄວາມໃຫມ່ຈົນກ່ວາການເຊື່ອມຕໍ່ຈະຖືກຟື້ນຟູຄືນມາ. Zookeeper ຍັງສືບຕໍ່ໄດ້ຮັບ pings ແລະເຊື່ອວ່ານາຍຫນ້າແມ່ນມີຊີວິດຢູ່ແລະດີ.

ເຂົ້າ. 25. ສະຖານະການ 2. ISR ໄດ້ຫຼຸດລົງພຽງແຕ່ຜູ້ນໍາ

ສະຖານະການ 3. ຜູ້ຕິດຕາມເຫັນຜູ້ນໍາ, ແຕ່ບໍ່ເຫັນຜູ້ຮັກສາສັດ

ຜູ້ຕິດຕາມຖືກແຍກອອກຈາກ Zookeeper, ແຕ່ບໍ່ແມ່ນມາຈາກນາຍຫນ້າກັບຜູ້ນໍາ. ດັ່ງນັ້ນ, ຜູ້ຕິດຕາມສືບຕໍ່ເຮັດການຮ້ອງຂໍການດຶງຂໍ້ມູນແລະເປັນສະມາຊິກຂອງ ISR. Zookeeper ບໍ່ໄດ້ຮັບ pings ແລະລົງທະບຽນການລົ້ມລະລາຍຂອງນາຍຫນ້າ, ແຕ່ເນື່ອງຈາກວ່າມັນເປັນພຽງແຕ່ຜູ້ຕິດຕາມ, ບໍ່ມີຜົນສະທ້ອນຫຼັງຈາກການຟື້ນຕົວ.

ເຂົ້າ. 26. ສະຖານະການທີ 3: ຜູ້ຕິດຕາມຍັງສືບຕໍ່ສົ່ງຄໍາຮ້ອງຂໍການດຶງໄປຫາຜູ້ນໍາ

ສະຖານະການ 4. ຜູ້ນໍາເຫັນຜູ້ຕິດຕາມ, ແຕ່ບໍ່ເຫັນ Zookeeper

ເຂົ້າ. 27. ສະຖານະການ 4. ຜູ້ນໍາແລະຜູ້ຕິດຕາມສອງຄົນ

ຜູ້ນໍາແມ່ນແຍກອອກຈາກ Zookeeper, ແຕ່ບໍ່ແມ່ນມາຈາກນາຍຫນ້າກັບຜູ້ຕິດຕາມ.

ເຂົ້າ. 28. ສະຖານະການ 4: ຜູ້ນໍາໂດດດ່ຽວຈາກ Zookeeper

ຫຼັງຈາກເວລາໃດຫນຶ່ງ, Zookeeper ຈະລົງທະບຽນຄວາມລົ້ມເຫຼວຂອງນາຍຫນ້າແລະແຈ້ງໃຫ້ຜູ້ຄວບຄຸມກ່ຽວກັບມັນ. ລາວຈະເລືອກຜູ້ນໍາໃຫມ່ໃນບັນດາຜູ້ຕິດຕາມຂອງລາວ. ຢ່າງໃດກໍ່ຕາມ, ຜູ້ນໍາເດີມຈະສືບຕໍ່ຄິດວ່າເປັນຜູ້ນໍາແລະຈະສືບຕໍ່ຮັບເອົາການເຂົ້າຈາກ acks=1. ຜູ້ຕິດຕາມບໍ່ໄດ້ສົ່ງການຮ້ອງຂໍໃຫ້ລາວອີກຕໍ່ໄປ, ດັ່ງນັ້ນລາວຈະພິຈາລະນາພວກເຂົາຕາຍແລະພະຍາຍາມຫຼຸດລົງ ISR ກັບຕົວມັນເອງ. ແຕ່ເນື່ອງຈາກມັນບໍ່ມີການເຊື່ອມຕໍ່ກັບ Zookeeper, ມັນຈະບໍ່ສາມາດເຮັດສິ່ງນີ້ໄດ້, ແລະໃນຈຸດນັ້ນຈະປະຕິເສດທີ່ຈະຍອມຮັບລາຍການເພີ່ມເຕີມ.

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

ໃນໄວໆນີ້ລູກຄ້າສັງເກດເຫັນການປ່ຽນແປງຜູ້ນໍາແລະເລີ່ມສົ່ງບັນທຶກໄປຫາເຄື່ອງແມ່ຂ່າຍໃຫມ່. ເມື່ອເຄືອຂ່າຍຖືກຟື້ນຟູຄືນໃຫມ່, ຜູ້ນໍາຕົ້ນສະບັບເຫັນວ່າມັນບໍ່ແມ່ນຜູ້ນໍາອີກຕໍ່ໄປແລະຕັດບັນທຶກຂອງມັນໃຫ້ກັບຄ່າ HW ທີ່ຜູ້ນໍາໃຫມ່ມີໃນເວລາທີ່ຄວາມລົ້ມເຫຼວເພື່ອຫຼີກເວັ້ນການຄວາມແຕກຕ່າງຂອງບັນທຶກ. ຫຼັງຈາກນັ້ນ, ມັນຈະເລີ່ມສົ່ງຄໍາຮ້ອງຂໍການດຶງໄປຫາຜູ້ນໍາໃຫມ່. ບັນທຶກທັງໝົດຈາກຜູ້ນໍາເດີມທີ່ບໍ່ໄດ້ຈໍາລອງກັບຜູ້ນໍາໃຫມ່ແມ່ນສູນເສຍໄປ. ນັ້ນແມ່ນ, ຂໍ້ຄວາມທີ່ບໍ່ໄດ້ຮັບການຍອມຮັບໂດຍຜູ້ນໍາຕົ້ນສະບັບໃນສອງສາມວິນາທີໃນເວລາທີ່ຜູ້ນໍາສອງຄົນເຮັດວຽກຈະສູນເສຍໄປ.

ເຂົ້າ. 29. ສະຖານະການ 4. ຜູ້ນໍາໃນນາຍຫນ້າ 1 ກາຍເປັນຜູ້ຕິດຕາມຫຼັງຈາກເຄືອຂ່າຍຖືກຟື້ນຟູ.

ສະຖານະການ 5: ຜູ້ຕິດຕາມແມ່ນແຍກອອກຈາກທັງສອງຂໍ້ Kafka ອື່ນໆແລະ Zookeeper

ຜູ້ຕິດຕາມແມ່ນໂດດດ່ຽວຈາກທັງສອງຂໍ້ Kafka ອື່ນໆແລະ Zookeeper. ລາວພຽງແຕ່ຖອນຕົວອອກຈາກ ISR ຈົນກ່ວາເຄືອຂ່າຍຖືກຟື້ນຟູ, ແລະຫຼັງຈາກນັ້ນຈັບກັບຄົນອື່ນ.

ເຂົ້າ. 30. ສະຖານະການທີ 5: ຜູ້ຕິດຕາມທີ່ໂດດດ່ຽວຖືກໂຍກຍ້າຍອອກຈາກ ISR

ສະຖານະການ 6: ຜູ້ນໍາແມ່ນແຍກອອກຈາກທັງສອງຂໍ້ Kafka ອື່ນໆແລະ Zookeeper

ເຂົ້າ. 31. ສະຖານະການ 6. ຜູ້ນໍາແລະຜູ້ຕິດຕາມສອງຄົນ

ຜູ້ນໍາແມ່ນໂດດດ່ຽວຢ່າງສົມບູນຈາກຜູ້ຕິດຕາມຂອງລາວ, ຜູ້ຄວບຄຸມແລະ Zookeeper. ສໍາລັບໄລຍະເວລາສັ້ນມັນຈະສືບຕໍ່ຮັບເອົາລາຍການຈາກ acks=1.

ເຂົ້າ. 32. ສະຖານະການທີ 6: ການແຍກຜູ້ນໍາອອກຈາກໂຫມດ Kafka ແລະ Zookeeper ອື່ນໆ

ບໍ່ໄດ້ຮັບການຮ້ອງຂໍຫຼັງຈາກຫມົດອາຍຸ replica.lag.time.max.ms, ມັນຈະພະຍາຍາມຫຼຸດລົງ ISR ກັບຕົວມັນເອງ, ແຕ່ຈະບໍ່ສາມາດເຮັດໄດ້ເພາະວ່າບໍ່ມີການສື່ສານກັບ Zookeeper, ຫຼັງຈາກນັ້ນມັນຈະຢຸດເຊົາການຍອມຮັບການຂຽນ.

ໃນຂະນະດຽວກັນ, Zookeeper ຈະຫມາຍນາຍຫນ້າທີ່ໂດດດ່ຽວວ່າຕາຍແລ້ວແລະຜູ້ຄວບຄຸມຈະເລືອກເອົາຜູ້ນໍາໃຫມ່.

ເຂົ້າ. 33. ສະຖານະການ 6. ສອງຜູ້ນໍາ

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

ເຂົ້າ. 34. ສະຖານະການທີ 6: ຜູ້ຜະລິດປ່ຽນໄປສູ່ຜູ້ນໍາໃຫມ່

ການຢືນຢັນທັງຫມົດທີ່ເຮັດໂດຍຜູ້ນໍາຕົ້ນສະບັບນັບຕັ້ງແຕ່ການສູນເສຍການເຊື່ອມຕໍ່ຈະສູນເສຍໄປ. ເມື່ອເຄືອຂ່າຍຖືກຟື້ນຟູ, ຜູ້ນໍາເດີມຈະຄົ້ນພົບຜ່ານ Zookeeper ວ່າມັນບໍ່ແມ່ນຜູ້ນໍາອີກຕໍ່ໄປ. ຫຼັງຈາກນັ້ນ, ມັນຈະຕັດບັນທຶກຂອງມັນໄປຫາ HW ຂອງຜູ້ນໍາໃຫມ່ໃນເວລາເລືອກຕັ້ງແລະເລີ່ມສົ່ງຄໍາຮ້ອງຂໍເປັນຜູ້ຕິດຕາມ.

ເຂົ້າ. 35. ສະຖານະການທີ 6: ຜູ້ນໍາຕົ້ນສະບັບກາຍເປັນຜູ້ຕິດຕາມຫຼັງຈາກການເຊື່ອມຕໍ່ເຄືອຂ່າຍຖືກຟື້ນຟູ

ໃນສະຖານະການນີ້, ການແຍກຕ່າງຫາກຢ່າງມີເຫດຜົນອາດຈະເກີດຂຶ້ນໃນໄລຍະເວລາສັ້ນໆ, ແຕ່ວ່າພຽງແຕ່ຖ້າ acks=1 и min.insync.replicas ຍັງ 1. ການແຍກຕົວຕາມເຫດຜົນຈະສິ້ນສຸດລົງໂດຍອັດຕະໂນມັດຫຼັງຈາກເຄືອຂ່າຍຖືກຟື້ນຟູຄືນໃຫມ່, ເມື່ອຜູ້ນໍາເດີມຮູ້ວ່າລາວບໍ່ແມ່ນຜູ້ນໍາອີກຕໍ່ໄປ, ຫຼືເມື່ອລູກຄ້າທຸກຄົນຮູ້ວ່າຜູ້ນໍາມີການປ່ຽນແປງແລະເລີ່ມຂຽນໄປຫາຜູ້ນໍາໃຫມ່ - ອັນໃດກໍ່ຕາມຈະເກີດຂຶ້ນກ່ອນ. ໃນກໍລະນີໃດກໍ່ຕາມ, ຂໍ້ຄວາມບາງຢ່າງຈະສູນເສຍ, ແຕ່ວ່າພຽງແຕ່ມີ acks=1.

ມີຕົວແປອື່ນຂອງສະຖານະການນີ້ທີ່, ກ່ອນທີ່ເຄືອຂ່າຍຈະແບ່ງປັນ, ຜູ້ຕິດຕາມໄດ້ລົ້ມລົງແລະຜູ້ນໍາໄດ້ບີບອັດ ISR ໃຫ້ກັບຕົວເອງ. ຫຼັງຈາກນັ້ນມັນຈະກາຍເປັນໂດດດ່ຽວເນື່ອງຈາກການສູນເສຍການເຊື່ອມຕໍ່. ຜູ້​ນໍາ​ໃຫມ່​ແມ່ນ​ໄດ້​ຮັບ​ການ​ເລືອກ​ຕັ້ງ​, ແຕ່​ຜູ້​ນໍາ​ຕົ້ນ​ສະ​ບັບ​ຍັງ​ສືບ​ຕໍ່​ຮັບ​ເອົາ​ການ​ເຂົ້າ​ຮ່ວມ​, ເຖິງ​ແມ່ນ​ວ່າ​ acks=ທັງໝົດ, ເນື່ອງຈາກວ່າບໍ່ມີຄົນອື່ນໃນ ISR ຍົກເວັ້ນເຂົາ. ບັນທຶກເຫຼົ່ານີ້ຈະສູນເສຍໄປເມື່ອເຄືອຂ່າຍຖືກຟື້ນຟູຄືນມາ. ວິທີດຽວທີ່ຈະຫຼີກເວັ້ນທາງເລືອກນີ້ແມ່ນ min.insync.replicas = 2.

ສະຖານະການທີ 7: ໂນດຕົວຄວບຄຸມ Kafka ບໍ່ສາມາດເຫັນໂຫນດ Kafka ອື່ນໄດ້

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

ສະຖານະການທີ 8: ຕົວຄວບຄຸມ Kafka ບໍ່ເຫັນ Zookeeper

Zookeeper ຈະບໍ່ໄດ້ຮັບ ping ຈາກຕົວຄວບຄຸມທີ່ຫຼຸດລົງແລະຈະເລືອກໂຫນດ Kafka ໃຫມ່ເປັນຕົວຄວບຄຸມ. ຕົວຄວບຄຸມຕົ້ນສະບັບສາມາດສືບຕໍ່ນໍາສະເຫນີຕົວຂອງມັນເອງເຊັ່ນນັ້ນ, ແຕ່ມັນບໍ່ໄດ້ຮັບການແຈ້ງການຈາກ Zookeeper, ດັ່ງນັ້ນມັນຈະບໍ່ມີວຽກງານໃດໆທີ່ຈະປະຕິບັດ. ເມື່ອເຄືອຂ່າຍຖືກຟື້ນຟູ, ລາວຈະຮູ້ວ່າລາວບໍ່ແມ່ນຜູ້ຄວບຄຸມອີກຕໍ່ໄປ, ແຕ່ໄດ້ກາຍເປັນໂຫນດ Kafka ປົກກະຕິ.

ບົດສະຫຼຸບຈາກສະຖານະການ

ພວກເຮົາເຫັນວ່າການສູນເສຍການເຊື່ອມຕໍ່ຜູ້ຕິດຕາມບໍ່ໄດ້ເຮັດໃຫ້ເກີດການສູນເສຍຂໍ້ຄວາມ, ແຕ່ພຽງແຕ່ຫຼຸດຜ່ອນການຊ້ໍາຊ້ອນຊົ່ວຄາວຈົນກ່ວາເຄືອຂ່າຍຖືກຟື້ນຟູຄືນໃຫມ່. ນີ້, ແນ່ນອນ, ສາມາດນໍາໄປສູ່ການສູນເສຍຂໍ້ມູນຖ້າຫາກວ່າຫນຶ່ງຫຼືຫຼາຍ nodes ໄດ້ຖືກສູນເສຍໄປ.

ຖ້າຜູ້ນໍາຖືກແຍກອອກຈາກ Zookeeper ເນື່ອງຈາກການສູນເສຍການເຊື່ອມຕໍ່, ນີ້ອາດຈະເຮັດໃຫ້ຂໍ້ຄວາມສູນເສຍຈາກ acks=1. ການຂາດການສື່ສານກັບ Zookeeper ເຮັດໃຫ້ເກີດການແບ່ງປັນຢ່າງມີເຫດຜົນສັ້ນໆກັບຜູ້ນໍາທັງສອງ. ບັນຫານີ້ຖືກແກ້ໄຂໂດຍພາລາມິເຕີ acks=ທັງໝົດ.

Parameter min.insync.replicas ເຂົ້າໄປໃນການຈໍາລອງສອງຫຼືຫຼາຍກວ່ານັ້ນສະຫນອງການຮັບປະກັນເພີ່ມເຕີມວ່າສະຖານະການໄລຍະສັ້ນດັ່ງກ່າວຈະບໍ່ສົ່ງຜົນໃຫ້ຂໍ້ຄວາມສູນເສຍຄືກັບສະຖານະການ 6.

ສະຫຼຸບຂໍ້ຄວາມທີ່ລືມ

ໃຫ້ບອກວິທີການທັງຫມົດທີ່ທ່ານສາມາດສູນເສຍຂໍ້ມູນໃນ Kafka:

• ຜູ້ນໍາໃດໆລົ້ມເຫລວຖ້າຂໍ້ຄວາມຖືກຢືນຢັນໂດຍໃຊ້ acks=1
• ການຫັນປ່ຽນການເປັນຜູ້ນໍາທີ່ບໍ່ສະອາດ, ນັ້ນແມ່ນ, ໄປສູ່ຜູ້ຕິດຕາມນອກ ISR, ເຖິງແມ່ນວ່າ acks=ທັງໝົດ
• ການແຍກຜູ້ນໍາອອກຈາກ Zookeeper ຖ້າຂໍ້ຄວາມຖືກຢືນຢັນໂດຍໃຊ້ acks=1
• ການໂດດດ່ຽວຢ່າງສົມບູນຂອງຜູ້ນໍາທີ່ໄດ້ຫຼຸດລົງກຸ່ມ ISR ແລ້ວ. ຂໍ້ຄວາມທັງຫມົດຈະສູນເສຍ, ເຖິງແມ່ນວ່າ acks=ທັງໝົດ. ນີ້ແມ່ນພຽງແຕ່ຖ້າຫາກວ່າ min.insync.replicas=1.
• ຄວາມລົ້ມເຫຼວພ້ອມໆກັນຂອງທຸກ nodes partition. ເນື່ອງຈາກວ່າຂໍ້ຄວາມຖືກຮັບຮູ້ຈາກຫນ່ວຍຄວາມຈໍາ, ບາງອັນອາດຈະບໍ່ຖືກຂຽນໃສ່ແຜ່ນ. ຫຼັງຈາກປິດເປີດເຄື່ອງເຊີບເວີ, ບາງຂໍ້ຄວາມອາດຈະຫາຍໄປ.

ການຫັນປ່ຽນການເປັນຜູ້ນໍາທີ່ບໍ່ສະອາດສາມາດຫຼີກລ່ຽງໄດ້ໂດຍການຫ້າມພວກເຂົາຫຼືຮັບປະກັນຢ່າງຫນ້ອຍສອງການຊໍ້າຊ້ອນ. ການຕັ້ງຄ່າທີ່ທົນທານທີ່ສຸດແມ່ນການປະສົມປະສານ acks=ທັງໝົດ и min.insync.replicas ຫຼາຍກ່ວາ 1.

ການປຽບທຽບໂດຍກົງຂອງຄວາມຫນ້າເຊື່ອຖືຂອງ RabbitMQ ແລະ Kafka

ເພື່ອຮັບປະກັນຄວາມຫນ້າເຊື່ອຖືແລະຄວາມພ້ອມສູງ, ທັງສອງແພລະຕະຟອມປະຕິບັດລະບົບການຈໍາລອງຂັ້ນຕົ້ນແລະຮອງ. ຢ່າງໃດກໍຕາມ, RabbitMQ ມີ heel Achilles. ເມື່ອເຊື່ອມຕໍ່ຄືນໃໝ່ຫຼັງຈາກຄວາມລົ້ມເຫຼວ, nodes ຍົກເລີກຂໍ້ມູນຂອງເຂົາເຈົ້າ ແລະ synchronization ຈະຖືກບລັອກ. ນີ້ whammy ສອງໂທຫາເຂົ້າໄປໃນຄໍາຖາມຄວາມຍາວຂອງແຖວຂະຫນາດໃຫຍ່ໃນ RabbitMQ. ທ່ານຈະຕ້ອງຍອມຮັບການຫຼຸດຜ່ອນການຊໍ້າຊ້ອນຫຼືເວລາຂັດຂວາງຍາວ. ການຫຼຸດຜ່ອນການຊໍ້າຊ້ອນເພີ່ມຄວາມສ່ຽງຂອງການສູນເສຍຂໍ້ມູນຂະຫນາດໃຫຍ່. ແຕ່ຖ້າແຖວມີຂະຫນາດນ້ອຍ, ຫຼັງຈາກນັ້ນເພື່ອປະໂຫຍດຂອງການຊ້ໍາຊ້ອນ, ໄລຍະເວລາສັ້ນໆຂອງການບໍ່ສາມາດໃຊ້ໄດ້ (ສອງສາມວິນາທີ) ສາມາດຈັດການກັບຄວາມພະຍາຍາມເຊື່ອມຕໍ່ຊ້ໍາກັນ.

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

RabbitMQ ແມ່ນດີກວ່າ Kafka ໃນຄວາມຫນ້າເຊື່ອຖືໃນເວລາທີ່ເຄື່ອງແມ່ຂ່າຍຫຼາຍໃນ cluster ລົ້ມເຫລວໃນເວລາດຽວກັນ. ດັ່ງທີ່ພວກເຮົາໄດ້ກ່າວມາແລ້ວ, RabbitMQ ສົ່ງການຢືນຢັນກັບຜູ້ເຜີຍແຜ່ພຽງແຕ່ຫຼັງຈາກຂໍ້ຄວາມຖືກຂຽນໃສ່ແຜ່ນໂດຍແມ່ບົດແລະກະຈົກທັງຫມົດ. ແຕ່ນີ້ເພີ່ມຄວາມລ່າຊ້າເພີ່ມເຕີມສໍາລັບສອງເຫດຜົນ:

• fsync ທຸກໆສອງສາມຮ້ອຍ milliseconds
• ຄວາມລົ້ມເຫຼວຂອງກະຈົກສາມາດສັງເກດເຫັນໄດ້ພຽງແຕ່ຫຼັງຈາກຕະຫຼອດຊີວິດຂອງແພັກເກັດທີ່ກວດເບິ່ງຄວາມພ້ອມຂອງແຕ່ລະ node (ຫມາຍຕິກສຸດທິ) ຫມົດອາຍຸ. ຖ້າກະຈົກຊ້າລົງຫຼືຕົກລົງ, ນີ້ເພີ່ມຄວາມລ່າຊ້າ.

ການເດີມພັນຂອງ Kafka ແມ່ນວ່າຖ້າຂໍ້ຄວາມຖືກເກັບໄວ້ໃນທົ່ວຫຼາຍໂຫນດ, ມັນສາມາດຮັບຮູ້ຂໍ້ຄວາມທັນທີທີ່ພວກເຂົາຕີຄວາມຊົງຈໍາ. ເນື່ອງຈາກວ່ານີ້, ມີຄວາມສ່ຽງທີ່ຈະສູນເສຍຂໍ້ຄວາມຂອງປະເພດໃດຫນຶ່ງ (ເຖິງແມ່ນວ່າ acks=ທັງໝົດ, min.insync.replicas=2) ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ຄວາມ​ລົ້ມ​ເຫຼວ​ພ້ອມ​ກັນ​.

ໂດຍລວມ, Kafka ສະແດງໃຫ້ເຫັນການປະຕິບັດຊອບແວທີ່ດີກວ່າແລະຖືກອອກແບບຕັ້ງແຕ່ພື້ນຖານສໍາລັບກຸ່ມ. ຈໍານວນຜູ້ຕິດຕາມສາມາດເພີ່ມຂຶ້ນເປັນ 11 ຖ້າຈໍາເປັນສໍາລັບຄວາມຫນ້າເຊື່ອຖື. ປັດໄຈການຈໍາລອງ 5 ແລະຈໍານວນຕໍາ່ສຸດທີ່ຂອງ replicas ໃນ synchronization min.insync.replicas=3 ຈະເຮັດໃຫ້ການສູນເສຍຂໍ້ຄວາມເປັນເຫດການທີ່ຫາຍາກຫຼາຍ. ຖ້າໂຄງສ້າງພື້ນຖານຂອງທ່ານສາມາດສະຫນັບສະຫນູນອັດຕາສ່ວນການຈໍາລອງນີ້ແລະລະດັບຂອງການຊໍ້າຊ້ອນ, ຫຼັງຈາກນັ້ນທ່ານສາມາດເລືອກທາງເລືອກນີ້.

ການຈັດກຸ່ມ RabbitMQ ແມ່ນດີສໍາລັບຄິວຂະຫນາດນ້ອຍ. ແຕ່ເຖິງແມ່ນແຖວນ້ອຍໆກໍ່ສາມາດເຕີບໂຕໄດ້ໄວເມື່ອມີການຈະລາຈອນຫຼາຍ. ເມື່ອແຖວມີຂະໜາດໃຫຍ່, ເຈົ້າຈະຕ້ອງເລືອກທີ່ຍາກລະຫວ່າງຄວາມພ້ອມ ແລະ ຄວາມໜ້າເຊື່ອຖື. ການຈັດກຸ່ມ RabbitMQ ແມ່ນເຫມາະສົມທີ່ສຸດສໍາລັບສະຖານະການທີ່ບໍ່ແມ່ນປົກກະຕິທີ່ຜົນປະໂຫຍດຂອງຄວາມຍືດຫຍຸ່ນຂອງ RabbitMQ ຫຼາຍກວ່າຂໍ້ເສຍຂອງການຈັດກຸ່ມຂອງມັນ.

ຢາແກ້ພິດອັນໜຶ່ງຕໍ່ກັບຄວາມອ່ອນແອຂອງ RabbitMQ ຕໍ່ກັບແຖວຂະໜາດໃຫຍ່ແມ່ນການທຳລາຍພວກມັນອອກເປັນຫຼາຍແຖວນ້ອຍກວ່າ. ຖ້າທ່ານບໍ່ຕ້ອງການໃຫ້ຄໍາສັ່ງຂອງແຖວທັງຫມົດ, ແຕ່ວ່າພຽງແຕ່ຂໍ້ຄວາມທີ່ກ່ຽວຂ້ອງ (ຕົວຢ່າງ, ຂໍ້ຄວາມຈາກລູກຄ້າສະເພາະ), ຫຼືບໍ່ສັ່ງຫຍັງເລີຍ, ຫຼັງຈາກນັ້ນທາງເລືອກນີ້ແມ່ນຍອມຮັບ: ເບິ່ງໂຄງການຂອງຂ້ອຍ. Rebalancer ເພື່ອແຍກແຖວ (ໂຄງການຍັງຢູ່ໃນຂັ້ນຕອນຕົ້ນ).

ສຸດທ້າຍ, ຢ່າລືມກ່ຽວກັບຈໍານວນຂອງແມງໄມ້ໃນ clustering ແລະ replication ກົນໄກຂອງທັງ RabbitMQ ແລະ Kafka. ເມື່ອເວລາຜ່ານໄປ, ລະບົບຕ່າງໆໄດ້ກາຍເປັນຜູ້ໃຫຍ່ແລະມີຄວາມຫມັ້ນຄົງ, ແຕ່ບໍ່ມີຂໍ້ຄວາມໃດໆທີ່ຈະປອດໄພ 100% ຈາກການສູນເສຍ! ນອກນີ້, ອຸບັດເຫດຂະໜາດໃຫຍ່ເກີດຂຶ້ນຢູ່ສູນຂໍ້ມູນ!

ຖ້າຂ້ອຍພາດບາງສິ່ງບາງຢ່າງ, ເຮັດຜິດພາດ, ຫຼືເຈົ້າບໍ່ເຫັນດີກັບຈຸດໃດຫນຶ່ງ, ກະລຸນາຂຽນຄໍາເຫັນຫຼືຕິດຕໍ່ຂ້ອຍ.

ຂ້ອຍມັກຈະຖືກຖາມວ່າ: "ສິ່ງທີ່ຈະເລືອກ, Kafka ຫຼື RabbitMQ?", "ເວທີໃດດີກວ່າ?". ຄວາມຈິງແລ້ວມັນກໍ່ຂຶ້ນກັບສະຖານະການຂອງເຈົ້າ, ປະສົບການໃນປະຈຸບັນ, ແລະອື່ນໆ. ຂ້ອຍລັງເລທີ່ຈະໃຫ້ຄວາມຄິດເຫັນຂອງຂ້ອຍເພາະວ່າມັນເປັນເລື່ອງງ່າຍເກີນໄປທີ່ຈະແນະນໍາເວທີດຽວສໍາລັບທຸກກໍລະນີການນໍາໃຊ້ແລະຂໍ້ຈໍາກັດທີ່ເປັນໄປໄດ້. ຂ້າພະເຈົ້າໄດ້ຂຽນບົດເລື່ອງຊຸດນີ້ເພື່ອໃຫ້ທ່ານສາມາດປະກອບຄວາມຄິດເຫັນຂອງທ່ານເອງ.

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

ຂ້າພະເຈົ້າເຫັນເຕັກໂນໂລຢີອື່ນໆທີ່ຂາດຄວາມຫນ້າເຊື່ອຖືແລະການຮັບປະກັນການສັ່ງຊື້, ຫຼັງຈາກນັ້ນຂ້າພະເຈົ້າເບິ່ງ RabbitMQ ແລະ Kafka ແລະຮັບຮູ້ມູນຄ່າທີ່ບໍ່ຫນ້າເຊື່ອຂອງທັງສອງລະບົບນີ້.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com