ຄວາມເຂົ້າໃຈນາຍຫນ້າຂໍ້ຄວາມ. ການຮຽນຮູ້ກົນໄກການສົ່ງຂໍ້ຄວາມກັບ ActiveMQ ແລະ Kafka. ບົດທີ 3. Kafka

ສືບຕໍ່ການແປພາສາຂອງປຶ້ມນ້ອຍ:
ຄວາມເຂົ້າໃຈນາຍຫນ້າຂໍ້ຄວາມ
author: Jakub Korab, ຜູ້ຈັດພິມ: O'Reilly Media, Inc., ວັນທີພິມເຜີຍແຜ່: ເດືອນມິຖຸນາ 2017, ISBN: 9781492049296.

ພາກສ່ວນທີ່ແປຜ່ານມາ: ຄວາມເຂົ້າໃຈນາຍຫນ້າຂໍ້ຄວາມ. ການຮຽນຮູ້ກົນໄກການສົ່ງຂໍ້ຄວາມກັບ ActiveMQ ແລະ Kafka. ບົດທີ 1 ບົດແນະນຳ

ບົດທີ 3

Kafka

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

ເນື່ອງຈາກເປົ້າຫມາຍສູງສຸດນີ້, ຄວາມຕ້ອງການອື່ນໆກໍ່ເກີດຂື້ນຕາມທໍາມະຊາດ. Kafka ຄວນ:

• ຈະໄວທີ່ສຸດ
• ໃຫ້ແບນວິດຫຼາຍຂຶ້ນເມື່ອເຮັດວຽກກັບຂໍ້ຄວາມ
• ຮອງຮັບ Publisher-Subscriber ແລະຕົວແບບ Point-to-Point
• ຢ່າຊ້າລົງດ້ວຍການເພີ່ມຜູ້ບໍລິໂພກ. ຕົວຢ່າງ, ການປະຕິບັດຂອງທັງແຖວແລະຫົວຂໍ້ໃນ ActiveMQ ຫຼຸດລົງຍ້ອນວ່າຈໍານວນຜູ້ບໍລິໂພກໃນຈຸດຫມາຍປາຍທາງເຕີບໂຕ.
• ສາມາດປັບຂະ ໜາດ ໄດ້ຕາມແນວນອນ; ຖ້ານາຍຫນ້າຫນຶ່ງທີ່ຍັງຄົງມີຂໍ້ຄວາມສາມາດເຮັດໄດ້ພຽງແຕ່ໃນຄວາມໄວສູງສຸດຂອງແຜ່ນ, ຫຼັງຈາກນັ້ນມັນມີຄວາມຫມາຍທີ່ຈະໄປນອກເຫນືອຕົວຢ່າງຂອງນາຍຫນ້າດຽວເພື່ອເພີ່ມປະສິດຕິພາບ.
• ຈໍາ​ກັດ​ການ​ເຂົ້າ​ເຖິງ​ການ​ເກັບ​ຮັກ​ສາ​ແລະ​ການ​ດຶງ​ຂໍ້​ຄວາມ​ຄືນ​ໃຫມ່​

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

ແບບຈໍາລອງຈຸດຫມາຍປາຍທາງລວມ

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

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

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

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

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

ຮູບທີ 3-1. Kafka Partitions

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

ກຳລັງອ່ານຂໍ້ຄວາມ

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

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

ບັນຫາການອ່ານສາມາດສະແດງໄດ້ດັ່ງນີ້:

• ຫົວ​ຂໍ້​ມີ​ການ​ແບ່ງ​ປັນ​ຫຼາຍ​
• ຫຼາຍກຸ່ມຂອງຜູ້ບໍລິໂພກສາມາດນໍາໃຊ້ຫົວຂໍ້ໃດຫນຶ່ງໃນເວລາດຽວກັນ
• ກຸ່ມຜູ້ບໍລິໂພກສາມາດມີຫຼາຍຕົວຢ່າງແຍກຕ່າງຫາກ

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

ຜູ້ບໍລິໂພກແລະກຸ່ມຜູ້ບໍລິໂພກ

ໃຫ້ເອົາເປັນຈຸດເລີ່ມຕົ້ນຂອງຫົວຂໍ້ທີ່ມີການແບ່ງປັນຫນຶ່ງ (ຮູບທີ 3-2).

ຮູບ 3-2. ຜູ້ບໍລິໂພກອ່ານຈາກການແບ່ງປັນ

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

ເມື່ອຜູ້ບໍລິໂພກທີ່ມີເຫດຜົນທີສອງເຊື່ອມຕໍ່ໂດຍໃຊ້ group_id ທີ່ແຕກຕ່າງກັນ, ມັນຈັດການຕົວຊີ້ທີສອງທີ່ບໍ່ຂຶ້ນກັບຕົວທໍາອິດ (ຮູບທີ 3-3). ດັ່ງນັ້ນ, ຫົວຂໍ້ Kafka ປະຕິບັດຄືກັບແຖວທີ່ມີຜູ້ບໍລິໂພກຫນຶ່ງຄົນແລະຄືກັບຫົວຂໍ້ການຈອງ (pub-sub) ປົກກະຕິທີ່ຜູ້ບໍລິໂພກຫຼາຍຄົນສະຫມັກ, ໂດຍມີຜົນປະໂຫຍດເພີ່ມເຕີມທີ່ຂໍ້ຄວາມທັງຫມົດຖືກເກັບໄວ້ແລະສາມາດດໍາເນີນການຫຼາຍຄັ້ງ.

ຮູບທີ 3-3. ຜູ້ບໍລິໂພກສອງຄົນໃນກຸ່ມຜູ້ບໍລິໂພກທີ່ແຕກຕ່າງກັນອ່ານຈາກການແບ່ງປັນດຽວກັນ

ຜູ້ບໍລິໂພກໃນກຸ່ມຜູ້ບໍລິໂພກ

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

ຮູບ 3-4. ຜູ້ບໍລິໂພກສອງຄົນໃນກຸ່ມຜູ້ບໍລິໂພກດຽວກັນອ່ານຈາກການແບ່ງປັນດຽວກັນ

ຮູບແບບການປຸງແຕ່ງນີ້, ໃນຈໍານວນຕົວຢ່າງຂອງຜູ້ບໍລິໂພກເກີນຈໍານວນການແບ່ງສ່ວນ, ສາມາດຄິດວ່າເປັນປະເພດຂອງຜູ້ບໍລິໂພກສະເພາະ. ນີ້ສາມາດເປັນປະໂຫຍດຖ້າທ່ານຕ້ອງການ "active-passive" (ຫຼື "hot-warm") clustering ຂອງຕົວຢ່າງຜູ້ບໍລິໂພກຂອງທ່ານ, ເຖິງແມ່ນວ່າການດໍາເນີນການຂອງຜູ້ບໍລິໂພກຫຼາຍໃນຂະຫນານ ("active-active" ຫຼື "hot-hot") ແມ່ນປົກກະຕິຫຼາຍກ່ວາຫຼາຍ. ຜູ້ບໍລິໂພກ.

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

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

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

ວິທີການ canonical ເພື່ອແກ້ໄຂບັນຫານີ້ໃນ Kafka ແມ່ນການໃຊ້ bОແບ່ງ​ປັນ​ເພີ່ມ​ເຕີມ​.

ການແບ່ງສ່ວນ

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

ຮູບ 3-5. ຜູ້ບໍລິໂພກຄົນຫນຶ່ງອ່ານຈາກຫຼາຍພາທິຊັນ

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

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

ຮູບ 3-6. ຜູ້ບໍລິໂພກສອງຄົນໃນກຸ່ມຜູ້ບໍລິໂພກດຽວກັນອ່ານຈາກການແບ່ງປັນທີ່ແຕກຕ່າງກັນ

ໂຄງການນີ້ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຂອງຄວາມສັບສົນຂອງນາຍຫນ້າ Kafka ເມື່ອທຽບກັບການແຈກຢາຍຂໍ້ຄວາມທີ່ຕ້ອງການເພື່ອຮັກສາແຖວ JMS. ໃນທີ່ນີ້ທ່ານບໍ່ຈໍາເປັນຕ້ອງກັງວົນກ່ຽວກັບຈຸດຕໍ່ໄປນີ້:

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

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

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

ກຳລັງສົ່ງຂໍ້ຄວາມ

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

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

ໃນບົດທີ 2, ພວກເຮົາໄດ້ປຶກສາຫາລືສະຖານະການການພະນັນອອນໄລນ໌ທີ່ເຫດການທີ່ກ່ຽວຂ້ອງຕ້ອງໄດ້ຮັບການປຸງແຕ່ງຕາມລໍາດັບໂດຍຜູ້ບໍລິໂພກດຽວ:

1. ບັນຊີຜູ້ໃຊ້ຖືກຕັ້ງຄ່າ.
2. ເງິນຖືກເຂົ້າບັນຊີ.
3. ການເດີມພັນແມ່ນເຮັດໃຫ້ຖອນເງິນອອກຈາກບັນຊີ.

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

ການໂຕ້ຕອບນີ້ເບິ່ງຄືວ່າ:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

ຂຽນຍຸດທະສາດການແບ່ງສ່ວນຂອງທ່ານເອງ

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

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

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

ເນື່ອງຈາກວ່າມູນຄ່າຂອງລາຍເຊັນຈະແຕກຕ່າງກັນໄປຕາມ payload, ຍຸດທະສາດ hashing ເລີ່ມຕົ້ນຂອງສ່ວນຕິດຕໍ່ຂອງ Partitioner ຈະບໍ່ເປັນກຸ່ມຂໍ້ຄວາມທີ່ກ່ຽວຂ້ອງ. ດັ່ງນັ້ນ, ພວກເຮົາຈະຕ້ອງຂຽນຍຸດທະສາດຂອງພວກເຮົາເອງທີ່ຈະວິເຄາະທີ່ສໍາຄັນນີ້ແລະແບ່ງສ່ວນມູນຄ່າ accountId.

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

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

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

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

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

MirrorMaker ຕ້ອງເຂົ້າໃຈກະແຈຂອງຫົວຂໍ້ທີ່ເຮັດຊໍ້າຄືນເພື່ອຮັກສາຄວາມເປັນລະບຽບຮຽບຮ້ອຍລະຫວ່າງຂໍ້ຄວາມໃນເວລາທີ່ replicating ລະຫວ່າງ clusters, ເນື່ອງຈາກວ່າຈໍານວນຂອງ partitions ສໍາລັບຫົວຂໍ້ນັ້ນອາດຈະບໍ່ຄືກັນໃນສອງ clusters.

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

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

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

ສັນຍາຜູ້ຜະລິດ

ການແບ່ງສ່ວນບໍ່ແມ່ນສິ່ງດຽວທີ່ຈະພິຈາລະນາໃນເວລາສົ່ງຂໍ້ຄວາມ. ລອງເບິ່ງວິທີການ send() ຂອງຊັ້ນຜູ້ຜະລິດໃນ Java API:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

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

RecordMetadata metadata = producer.send(record).get();

ເພີ່ມເຕີມກ່ຽວກັບການອ່ານຂໍ້ຄວາມ

ການອ່ານຂໍ້ຄວາມມີຄວາມສັບສົນເພີ່ມເຕີມທີ່ຕ້ອງໄດ້ຮັບການຄາດຄະເນກ່ຽວກັບ. ບໍ່ເຫມືອນກັບ JMS API, ເຊິ່ງສາມາດເອີ້ນໃຊ້ຕົວຟັງຂໍ້ຄວາມເພື່ອຕອບສະຫນອງຂໍ້ຄວາມ, ຜູ້ບໍລິໂພກ Kafka ພຽງແຕ່ສໍາຫຼວດ. ຂໍໃຫ້ພິຈາລະນາວິທີການທີ່ໃກ້ຊິດ ແບບສຳຫຼວດ()ໃຊ້ເພື່ອຈຸດປະສົງນີ້:

ConsumerRecords < K, V > poll(long timeout);

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

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

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

ກັບຄືນໄປຫາຮູບແບບການອ່ານທີ່ໄດ້ສົນທະນາກ່ອນຫນ້ານີ້, ການປຸງແຕ່ງຂໍ້ຄວາມປະກອບດ້ວຍສາມຂັ້ນຕອນ:

1. ດຶງ​ຂໍ້​ຄວາມ​ສໍາ​ລັບ​ການ​ອ່ານ​.
2. ປະມວນຜົນຂໍ້ຄວາມ.
3. ຢືນຢັນຂໍ້ຄວາມ.

ຜູ້ບໍລິໂພກ Kafka ມາພ້ອມກັບຕົວເລືອກການຕັ້ງຄ່າ enable.auto.commit. ນີ້ແມ່ນການຕັ້ງຄ່າເລີ່ມຕົ້ນທີ່ໃຊ້ເລື້ອຍໆ, ເຊັ່ນດຽວກັນກັບການຕັ້ງຄ່າທີ່ມີຄໍາວ່າ "ອັດຕະໂນມັດ".

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

ໃນ Kafka 0.10, ລະຫັດລູກຄ້າໄດ້ຖືກປ່ຽນແປງເພື່ອໃຫ້ຄໍາຫມັ້ນສັນຍາຖືກກະຕຸ້ນເປັນແຕ່ລະໄລຍະໂດຍຫ້ອງສະຫມຸດລູກຄ້າ, ຕາມທີ່ໄດ້ກໍານົດໄວ້. auto.commit.interval.ms. ພຶດຕິກໍານີ້ແມ່ນຢູ່ບ່ອນໃດບ່ອນໜຶ່ງລະຫວ່າງໂໝດ JMS AUTO_ACKNOWLEDGE ແລະ DUPS_OK_ACKNOWLEDGE. ເມື່ອນໍາໃຊ້ autocommit, ຂໍ້ຄວາມສາມາດຖືກສັນຍາໂດຍບໍ່ຄໍານຶງເຖິງວ່າພວກມັນຖືກປຸງແຕ່ງຢ່າງແທ້ຈິງ - ນີ້ສາມາດເກີດຂື້ນໃນກໍລະນີຂອງຜູ້ບໍລິໂພກຊ້າ. ຖ້າຜູ້ບໍລິໂພກຍົກເລີກ, ຂໍ້ຄວາມຈະຖືກດຶງມາໂດຍຜູ້ບໍລິໂພກຕໍ່ໄປ, ເລີ່ມຕົ້ນຈາກຕໍາແຫນ່ງທີ່ຫມັ້ນສັນຍາ, ເຊິ່ງອາດຈະເຮັດໃຫ້ຂໍ້ຄວາມພາດໂອກາດ. ໃນກໍລະນີນີ້, Kafka ບໍ່ໄດ້ສູນເສຍຂໍ້ຄວາມ, ລະຫັດການອ່ານພຽງແຕ່ບໍ່ໄດ້ປະມວນຜົນພວກມັນ.

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

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

ໃນ Kafka, ມີສອງວິທີທີ່ຈະ commit (ຄໍາຫມັ້ນສັນຍາ) offset (offset): ອັດຕະໂນມັດແລະຄູ່ມື. ໃນທັງສອງກໍລະນີ, ຂໍ້ຄວາມສາມາດຖືກປະມວນຜົນຫຼາຍຄັ້ງຖ້າຂໍ້ຄວາມຖືກປະມວນຜົນແຕ່ລົ້ມເຫລວກ່ອນຄໍາຫມັ້ນສັນຍາ. ນອກນັ້ນທ່ານຍັງສາມາດເລືອກທີ່ຈະບໍ່ດໍາເນີນການຂໍ້ຄວາມທັງຫມົດຖ້າຫາກວ່າຄໍາຫມັ້ນສັນຍາເກີດຂຶ້ນໃນພື້ນຫລັງແລະລະຫັດຂອງທ່ານໄດ້ຖືກສໍາເລັດກ່ອນທີ່ຈະສາມາດດໍາເນີນການໄດ້ (ບາງທີອາດມີຢູ່ໃນ Kafka 0.9 ແລະກ່ອນຫນ້ານັ້ນ).

ທ່ານ​ສາ​ມາດ​ຄວບ​ຄຸມ​ຂະ​ບວນ​ການ offset commit ຄູ່​ມື​ໃນ Kafka consumer API ໂດຍ​ການ​ຕັ້ງ​ຄ່າ​ພາ​ລາ​ມິ​ເຕີ​ enable.auto.commit ຜິດ ແລະ ໂທຫາຢ່າງຈະແຈ້ງວິທີໜຶ່ງຕໍ່ໄປນີ້:

void commitSync();
void commitAsync();

ຖ້າທ່ານຕ້ອງການປະມວນຜົນຂໍ້ຄວາມ "ຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງ", ທ່ານຕ້ອງປະຕິບັດການຊົດເຊີຍດ້ວຍຕົນເອງ commitSync()ໂດຍການປະຕິບັດຄໍາສັ່ງນີ້ທັນທີຫຼັງຈາກການປະມວນຜົນຂໍ້ຄວາມ.

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

• ມ້ວນຄືນຂໍ້ຄວາມທີ່ຖືກປອມແປງໂດຍອັດຕະໂນມັດ. ຜູ້ບໍລິໂພກເອງຕ້ອງຈັດການກັບຂໍ້ຍົກເວັ້ນທີ່ເກີດຈາກການໂຫຼດທີ່ມີບັນຫາແລະ backend outages, ຍ້ອນວ່າພວກເຂົາບໍ່ສາມາດອີງໃສ່ນາຍຫນ້າເພື່ອສົ່ງຄືນຂໍ້ຄວາມ.
• ສົ່ງຂໍ້ຄວາມໄປຫາຫຼາຍຫົວຂໍ້ໃນການປະຕິບັດປະລໍາມະນູຫນຶ່ງ. ດັ່ງທີ່ພວກເຮົາຈະເຫັນໃນໄວໆນີ້, ການຄວບຄຸມຫົວຂໍ້ທີ່ແຕກຕ່າງກັນແລະການແບ່ງປັນສາມາດອາໄສຢູ່ໃນເຄື່ອງຈັກທີ່ແຕກຕ່າງກັນໃນກຸ່ມ Kafka ທີ່ບໍ່ປະສານງານການເຮັດທຸລະກໍາເມື່ອສົ່ງ. ໃນເວລາຂຽນນີ້, ບາງວຽກໄດ້ຖືກປະຕິບັດເພື່ອເຮັດໃຫ້ສິ່ງນີ້ເປັນໄປໄດ້ກັບ KIP-98.
• ເຊື່ອມໂຍງການອ່ານຂໍ້ຄວາມຫນຶ່ງຈາກຫົວຂໍ້ຫນຶ່ງກັບການສົ່ງຂໍ້ຄວາມອື່ນໄປຫາຫົວຂໍ້ອື່ນ. ອີກເທື່ອຫນຶ່ງ, ສະຖາປັດຕະຍະກໍາຂອງ Kafka ແມ່ນຂຶ້ນກັບເຄື່ອງຈັກເອກະລາດຈໍານວນຫຼາຍທີ່ແລ່ນເປັນລົດເມຫນຶ່ງແລະບໍ່ມີການພະຍາຍາມປິດບັງສິ່ງນີ້. ຕົວຢ່າງ, ບໍ່ມີອົງປະກອບ API ທີ່ອະນຸຍາດໃຫ້ທ່ານເຊື່ອມຕໍ່ ຜູ້ບໍລິໂພກ и ຜູ້ຜະລິດ ໃນທຸລະກໍາ. ໃນ JMS, ນີ້ແມ່ນສະຫນອງໃຫ້ໂດຍວັດຖຸ ກອງປະຊຸມຈາກທີ່ຖືກສ້າງຂຶ້ນ MessageProducers и MessageConsumers.

ຖ້າພວກເຮົາບໍ່ສາມາດອີງໃສ່ການເຮັດທຸລະກໍາ, ພວກເຮົາສາມາດສະຫນອງຄວາມຫມາຍທີ່ໃກ້ຊິດກັບສິ່ງທີ່ສະຫນອງໂດຍລະບົບການສົ່ງຂໍ້ຄວາມແບບດັ້ງເດີມໄດ້ແນວໃດ?

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

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

ວິທີການ ຊອກຫາ() ສາມາດນໍາໃຊ້ກັບວິທີການ
offsetsForTimes(ແຜນທີ່ timestampsToSearch) ເພື່ອກັບຄືນສູ່ສະຖານະໃນບາງຈຸດສະເພາະໃນອະດີດ.

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

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

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

ມີໃຫ້ສູງ

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

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

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

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

ໃນກໍລະນີພື້ນຖານ, ຫົວຂໍ້ຖືກສ້າງຢູ່ໃນກຸ່ມ Kafka ທີ່ມີຄຸນສົມບັດດັ່ງຕໍ່ໄປນີ້:

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

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

ໃນເວລາແລ່ນ ສໍາ​ລັບ​ການ​ແບ່ງ​ປັນ​ຫົວ​ຂໍ້​ແຕ່​ລະ​ຄົນ​ ຜູ້ຄວບຄຸມ ມອບໝາຍໜ້າທີ່ໃຫ້ນາຍໜ້າ ຜູ້ນໍາ (ຜູ້ນໍາ, ຕົ້ນສະບັບ, ຜູ້ນໍາສະເຫນີ) ແລະ ຜູ້ຕິດຕາມ (ຜູ້​ຕິດ​ຕາມ​, ສໍາ​ລອງ​, subordinates​)​. ນາຍຫນ້າ, ເຮັດຫນ້າທີ່ເປັນຜູ້ນໍາສໍາລັບການແບ່ງສ່ວນນີ້, ຮັບຜິດຊອບສໍາລັບການໄດ້ຮັບຂໍ້ຄວາມທັງຫມົດທີ່ສົ່ງໄປຫາມັນໂດຍຜູ້ຜະລິດແລະແຈກຢາຍຂໍ້ຄວາມໃຫ້ຜູ້ບໍລິໂພກ. ເມື່ອຂໍ້ຄວາມຖືກສົ່ງໄປຫາຫົວຂໍ້ແບ່ງສ່ວນ, ພວກມັນຖືກ replicated ກັບທຸກ nodes ນາຍຫນ້າເຮັດຫນ້າທີ່ເປັນຜູ້ຕິດຕາມສໍາລັບພາທິຊັນນັ້ນ. ແຕ່ລະ node ທີ່ມີບັນທຶກສໍາລັບການແບ່ງສ່ວນແມ່ນເອີ້ນວ່າ ແບບຈຳລອງ. ນາຍຫນ້າສາມາດເຮັດຫນ້າທີ່ເປັນຜູ້ນໍາສໍາລັບບາງສ່ວນແລະເປັນຜູ້ຕິດຕາມສໍາລັບຄົນອື່ນ.

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

ສ່ວນຫນຶ່ງຂອງການຕັ້ງຄ່າຜູ້ຜະລິດແມ່ນພາລາມິເຕີ acks, ເຊິ່ງກໍານົດຈໍານວນ replicas ຕ້ອງໄດ້ຮັບການຮັບຮູ້ (ຮັບຮູ້) ຂໍ້ຄວາມກ່ອນທີ່ກະທູ້ຄໍາຮ້ອງສະຫມັກຈະສືບຕໍ່ສົ່ງ: 0, 1, ຫຼືທັງຫມົດ. ຖ້າຕັ້ງເປັນ ທັງຫມົດ, ຫຼັງຈາກນັ້ນເມື່ອໄດ້ຮັບຂໍ້ຄວາມ, ຜູ້ນໍາຈະສົ່ງຄໍາຢືນຢັນກັບຄືນໄປບ່ອນຜູ້ຜະລິດທັນທີທີ່ມັນໄດ້ຮັບການຢືນຢັນ (ການຮັບຮູ້) ຂອງບັນທຶກຈາກຫຼາຍໆ cues (ລວມທັງຕົວມັນເອງ) ກໍານົດໂດຍຫົວຂໍ້ຕັ້ງ. min.insync.replicas (ຄ່າເລີ່ມຕົ້ນ 1). ຖ້າ​ຫາກ​ວ່າ​ຂໍ້​ຄວາມ​ບໍ່​ສາ​ມາດ replicated ສົບ​ຜົນ​ສໍາ​ເລັດ​, ຫຼັງ​ຈາກ​ນັ້ນ​ຜູ້​ຜະ​ລິດ​ຈະ​ຍົກ​ເວັ້ນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ (NotEnoughReplicas ຫຼື NotEnoughReplicasAfterAppend).

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

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

ໂດຍການນໍາໃຊ້ໂຄງການການຈໍາລອງນີ້, Kafka ສະຫລາດຫລີກລ່ຽງຄວາມຈໍາເປັນໃນການຂຽນຂໍ້ຄວາມແຕ່ລະຄົນໃສ່ແຜ່ນດິດດ້ວຍການດໍາເນີນງານ. sync(). ແຕ່ລະຂໍ້ຄວາມທີ່ຖືກສົ່ງໂດຍຜູ້ຜະລິດຈະຖືກຂຽນໃສ່ບັນທຶກການແບ່ງສ່ວນ, ແຕ່ດັ່ງທີ່ໄດ້ສົນທະນາໃນບົດທີ 2, ການຂຽນໄຟລ໌ແມ່ນເຮັດໃນເບື້ອງຕົ້ນໃນ buffer ຂອງລະບົບປະຕິບັດການ. ຖ້າຂໍ້ຄວາມນີ້ຖືກຈໍາລອງກັບຕົວຢ່າງ Kafka ອື່ນແລະຢູ່ໃນຄວາມຊົງຈໍາຂອງມັນ, ການສູນເສຍຜູ້ນໍາບໍ່ໄດ້ຫມາຍຄວາມວ່າຂໍ້ຄວາມຕົວມັນເອງໄດ້ສູນເສຍ - ມັນສາມາດຖືກນໍາໄປໂດຍ replica synchronized.
ການປະຕິເສດການປະຕິບັດການປະຕິບັດງານ sync() ຫມາຍຄວາມວ່າ Kafka ສາມາດໄດ້ຮັບຂໍ້ຄວາມໄວເທົ່າທີ່ມັນສາມາດຂຽນພວກມັນໄວ້ໃນຄວາມຊົງຈໍາ. ກົງກັນຂ້າມ, ຍິ່ງເຈົ້າສາມາດຫຼີກລ່ຽງການລ້າງໜ່ວຍຄວາມຈຳໄປໃສ່ແຜ່ນໄດ້ດົນເທົ່າໃດ, ກໍ່ຍິ່ງດີກວ່າ. ສໍາລັບເຫດຜົນນີ້, ມັນບໍ່ແມ່ນເລື່ອງແປກທີ່ນາຍຫນ້າ Kafka ຈະຖືກຈັດສັນຫນ່ວຍຄວາມຈໍາ 64 GB ຫຼືຫຼາຍກວ່ານັ້ນ. ການໃຊ້ຄວາມຊົງຈໍານີ້ຫມາຍຄວາມວ່າຕົວຢ່າງ Kafka ດຽວສາມາດດໍາເນີນການໄດ້ຢ່າງງ່າຍດາຍດ້ວຍຄວາມໄວຫຼາຍພັນເທື່ອໄວກ່ວານາຍຫນ້າຂໍ້ຄວາມແບບດັ້ງເດີມ.

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

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

ຜົນໄດ້ຮັບ

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

ພາກສ່ວນທີ່ແປຜ່ານມາ: ຄວາມເຂົ້າໃຈນາຍຫນ້າຂໍ້ຄວາມ. ການຮຽນຮູ້ກົນໄກການສົ່ງຂໍ້ຄວາມກັບ ActiveMQ ແລະ Kafka. ບົດທີ 1

ການແປສຳເລັດແລ້ວ: tele.gg/middle_java

ຕິດ​ຕາມ​ຕອນ​ຕໍ່​ໄປ…

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

Kafka ຖືກນໍາໃຊ້ໃນອົງການຈັດຕັ້ງຂອງທ່ານບໍ?

• ແມ່ນ​ແລ້ວ

• ບໍ່​ມີ

• ເມື່ອກ່ອນໃຊ້, ດຽວນີ້ບໍ່ໄດ້

• ພວກເຮົາວາງແຜນທີ່ຈະນໍາໃຊ້

38 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. 8 ຜູ້ໃຊ້ງົດ.

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