🥇«ຮາໂດບ. ZooKeeper» ຈາກຊຸດ Technostrim Mail.Ru Group «ວິທີການແຈກຢາຍຂໍ້ມູນປະລິມານຂະຫນາດໃຫຍ່ໃນ Hadoop»

ຂ້າພະເຈົ້າແນະນໍາໃຫ້ທ່ານອ່ານບົດບັນທຶກຂອງການບັນຍາຍ "Hadoop. ZooKeeper" ຈາກຊຸດ "ວິທີການສໍາລັບການແຈກຢາຍປະລິມານຂະຫນາດໃຫຍ່ຂອງຂໍ້ມູນໃນ Hadoop".

ZooKeeper ແມ່ນຫຍັງ, ສະຖານທີ່ຂອງມັນຢູ່ໃນລະບົບນິເວດ Hadoop. ຄວາມບໍ່ຈິງກ່ຽວກັບການແຈກຢາຍຄອມພິວເຕີ້. ແຜນວາດຂອງລະບົບການແຈກຢາຍມາດຕະຖານ. ຄວາມຫຍຸ້ງຍາກໃນການປະສານງານລະບົບແຈກຢາຍ. ບັນຫາການປະສານງານແບບປົກກະຕິ. ຫຼັກການທີ່ຢູ່ເບື້ອງຫລັງການອອກແບບ ZooKeeper. ຮູບແບບຂໍ້ມູນ ZooKeeper. znode ທຸງ. ເຊດຊັນ. API ລູກຄ້າ. Primitives (ການຕັ້ງຄ່າ, ສະມາຊິກກຸ່ມ, locks ງ່າຍດາຍ, ການເລືອກຕັ້ງຜູ້ນໍາ, locking ໂດຍບໍ່ມີການ herd ຜົນກະທົບ). ສະຖາປັດຕະຍະກໍາ ZooKeeper. ZooKeeper DB. ZAB. ຮ້ອງຂໍຕົວຈັດການ.

"ຮາໂດບ. ZooKeeper" ຈາກ Mail.Ru Group Technostream ຊຸດ "ວິທີການສໍາລັບການແຈກຢາຍຂໍ້ມູນປະລິມານຂະຫນາດໃຫຍ່ໃນ Hadoop"

ມື້ນີ້ພວກເຮົາຈະເວົ້າກ່ຽວກັບ ZooKeeper. ສິ່ງນີ້ແມ່ນເປັນປະໂຫຍດຫຼາຍ. ມັນ, ຄືກັບຜະລິດຕະພັນ Apache Hadoop, ມີໂລໂກ້. ມັນພັນລະນາຜູ້ຊາຍ.

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

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

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

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

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

ໃນບັນດາສິ່ງອື່ນໆ, ໃນເວລາທີ່ການນໍາໃຊ້ເຄືອຂ່າຍ, ມີຄວາມສະເຫມີ latency ທີ່ແນ່ນອນ. ແຜ່ນຍັງມີມັນ, ແຕ່ເຄືອຂ່າຍມີຫຼາຍກວ່ານັ້ນ. Latency ແມ່ນເວລາຊັກຊ້າບາງອັນ, ເຊິ່ງອາດມີຂະໜາດນ້ອຍ ຫຼືຂ້ອນຂ້າງສຳຄັນ.

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

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

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

ມັນງ່າຍກວ່າທີ່ຈະຂຽນໂປຣແກມໜຶ່ງທີ່ເຮັດວຽກຢູ່ໃນຄອມພິວເຕີໜ່ວຍໜຶ່ງດ້ວຍໂປເຊດເຊີດຽວ.

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

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

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

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

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

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

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

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

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

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

ມັນເປັນການຍາກທີ່ຈະບອກວ່າໂຄງການໃດເຫຼົ່ານີ້ເຮັດວຽກດີກວ່າ. ແຕ່ລະຄົນມີຂໍ້ດີ ແລະຂໍ້ເສຍຂອງຕົນເອງ.

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

ແລະໂຄງການນີ້ (ຂ້າງເທິງ) ອາດຈະສັບສົນຫຼາຍ, ແຕ່ມີຄວາມຫນ້າເຊື່ອຖືຫຼາຍ.

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

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

ZooKeeper ສະເຫນີວິທີການຈັດການກັບການປະຕິເສດດັ່ງກ່າວ, ເຊິ່ງເຮັດໃຫ້ຊີວິດຂອງພວກເຮົາງ່າຍຂຶ້ນ.

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

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

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

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

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

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

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

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

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

ZooKeeper ອະນຸຍາດໃຫ້ທ່ານແກ້ໄຂບັນຫາເຫຼົ່ານີ້ທັງຫມົດໃນລະດັບຫນຶ່ງຫຼືອື່ນ. ແລະຂ້ອຍຈະສະແດງດ້ວຍຕົວຢ່າງວິທີທີ່ມັນອະນຸຍາດໃຫ້ທ່ານເຮັດສິ່ງນີ້.

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

ການຮ້ອງຂໍຂອງລູກຄ້າທັງຫມົດແມ່ນໄດ້ຖືກດໍາເນີນຕາມລໍາດັບຂອງແຖວທົ່ວໄປ.

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

ZooKeeper ສາມາດເຮັດວຽກໄດ້ສອງໂໝດ. ໂໝດທຳອິດແມ່ນເຮັດວຽກແບບ standalone, ຢູ່ໃນ node ດຽວ. ນີ້ແມ່ນສະດວກສຳລັບການທົດສອບ. ມັນຍັງສາມາດເຮັດວຽກໃນໂໝດ cluster, ໃນຈຳນວນ node ໃດກໍໄດ້. ເຄື່ອງແມ່ຂ່າຍຖ້າພວກເຮົາມີກຸ່ມເຄື່ອງ 100 ເຄື່ອງ, ມັນບໍ່ຈຳເປັນຕ້ອງແລ່ນຢູ່ໃນເຄື່ອງ 100 ເຄື່ອງ. ມັນພຽງພໍທີ່ຈະຈັດສັນເຄື່ອງສອງສາມເຄື່ອງທີ່ ZooKeeper ສາມາດແລ່ນໄດ້. ແລະມັນຍຶດໝັ້ນຫຼັກການຂອງຄວາມພ້ອມສູງ. ZooKeeper ເກັບຮັກສາສຳເນົາຂໍ້ມູນທີ່ສົມບູນໃນແຕ່ລະ instance ທີ່ແລ່ນ. ຂ້ອຍຈະອະທິບາຍວິທີທີ່ມັນເຮັດໃນພາຍຫຼັງ. ມັນບໍ່ແບ່ງ ຫຼື ແບ່ງປັນຂໍ້ມູນ. ໃນດ້ານໜຶ່ງ, ນີ້ແມ່ນຂໍ້ເສຍປຽບເພາະວ່າພວກເຮົາບໍ່ສາມາດເກັບຮັກສາໄດ້ຫຼາຍ, ແຕ່ໃນທາງກັບກັນ, ມັນບໍ່ຈຳເປັນ. ມັນບໍ່ໄດ້ຖືກອອກແບບມາສຳລັບສິ່ງນັ້ນ; ມັນບໍ່ແມ່ນຖານຂໍ້ມູນ.

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

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

ລູກຄ້າແມ່ນຜູ້ໃຊ້ທີ່ໃຊ້ ZooKeeper.

ເຊີບເວີແມ່ນຂະບວນການ ZooKeeper ຕົວຂອງມັນເອງ.

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

ມີສອງປະເພດຂອງການດໍາເນີນງານ. ທໍາອິດແມ່ນການປັບປຸງ / ຂຽນ, ເມື່ອການດໍາເນີນງານບາງຢ່າງປ່ຽນແປງສະຖານະຂອງຕົ້ນໄມ້ຂອງພວກເຮົາ. ຕົ້ນໄມ້ແມ່ນທົ່ວໄປ.

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

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

ແຕ່ລະ znode ສາມາດເກັບຂໍ້ມູນບາງຢ່າງ, ປົກກະຕິແລ້ວບໍ່ໃຫຍ່ຫຼາຍ, ຕົວຢ່າງ, 10 ກິໂລໄບ. ແລະແຕ່ລະ znode ສາມາດມີຈໍານວນທີ່ແນ່ນອນຂອງເດັກນ້ອຍ.

Znodes ມາໃນຫຼາຍປະເພດ. ພວກເຂົາສາມາດສ້າງໄດ້. ແລະໃນເວລາທີ່ສ້າງ znode, ພວກເຮົາກໍານົດປະເພດທີ່ມັນຄວນຈະເປັນ.

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

ປະເພດທີສອງແມ່ນທຸງຕາມລໍາດັບ. ມັນເພີ່ມເຄົາເຕີໃນທາງກັບ znode. ຕົວຢ່າງ, ພວກເຮົາມີໄດເລກະທໍລີທີ່ມີແອັບພລິເຄຊັນ 1_5. ແລະໃນເວລາທີ່ພວກເຮົາສ້າງ node ທໍາອິດ, ມັນໄດ້ຮັບ p_1, ທີສອງ - p_2 . ແລະໃນເວລາທີ່ພວກເຮົາໂທຫາວິທີການນີ້ແຕ່ລະຄັ້ງ, ພວກເຮົາຜ່ານເສັ້ນທາງເຕັມ, ຊີ້ໃຫ້ເຫັນພຽງແຕ່ສ່ວນຫນຶ່ງຂອງເສັ້ນທາງ, ແລະຕົວເລກນີ້ແມ່ນເພີ່ມຂຶ້ນໂດຍອັດຕະໂນມັດເພາະວ່າພວກເຮົາຊີ້ບອກປະເພດ node - sequential.

znode ປົກກະຕິ. ນາງສະເຫມີຈະມີຊີວິດຢູ່ແລະມີຊື່ທີ່ພວກເຮົາບອກນາງ.

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

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

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

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

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

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

ຖ້າພວກເຮົາບໍ່ຕ້ອງການກວດສອບສະບັບນີ້, ພວກເຮົາພຽງແຕ່ຜ່ານ "-1" argument.

ອັນທີສາມ, ມັນກວດເບິ່ງການມີຢູ່ຂອງ znode. ໃຫ້ຜົນເປັນ true ຖ້າມີ node, false ຖ້າບໍ່ດັ່ງນັ້ນ.

ແລະຫຼັງຈາກນັ້ນໂມງທຸງປະກົດຂຶ້ນ, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສາມາດຕິດຕາມກວດກາ node ນີ້.

ທ່ານສາມາດຕັ້ງທຸງນີ້ເຖິງແມ່ນວ່າຢູ່ໃນ node ທີ່ບໍ່ມີຢູ່ແລ້ວແລະໄດ້ຮັບການແຈ້ງເຕືອນເມື່ອມັນປາກົດ. ນີ້ຍັງສາມາດເປັນປະໂຫຍດ.

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

ຍັງມີ SetData. ທີ່ນີ້ພວກເຮົາຜ່ານສະບັບ. ແລະຖ້າພວກເຮົາຜ່ານມັນ, ຂໍ້ມູນໃນ znode ຂອງສະບັບທີ່ແນ່ນອນຈະຖືກປັບປຸງ.

ທ່ານຍັງສາມາດລະບຸ "-1" ເພື່ອຍົກເວັ້ນການກວດສອບນີ້.

ອີກວິທີຫນຶ່ງທີ່ເປັນປະໂຫຍດແມ່ນ ໄດ້ຮັບເດັກນ້ອຍ. ພວກເຮົາຍັງສາມາດໄດ້ຮັບບັນຊີລາຍຊື່ຂອງ znodes ທັງຫມົດທີ່ຂຶ້ນກັບມັນ. ພວກເຮົາສາມາດຕິດຕາມສິ່ງນີ້ໂດຍການຕັ້ງໂມງທຸງ.

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

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

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

ສອງການດໍາເນີນງານທີ່ພວກເຮົາສົນທະນາແມ່ນການປັບປຸງ / ຂຽນ, ເຊິ່ງປ່ຽນຂໍ້ມູນ. ເຫຼົ່ານີ້ແມ່ນສ້າງ, setData, sync, ລຶບ. ແລະອ່ານແມ່ນມີຢູ່, getData, getChildren.

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

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

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

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

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

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

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

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

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

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

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

ໃນທີ່ນີ້ອັນທີ່ເອີ້ນວ່າຜົນກະທົບຝູງສັດເກີດຂື້ນ, ເຊັ່ນ: ຜົນກະທົບຂອງຝູງສັດ, ເພາະວ່າເມື່ອຜູ້ ນຳ ຕາຍ, ຜູ້ ທຳ ອິດໃນເວລາຕໍ່ມາຈະກາຍເປັນຜູ້ ນຳ.

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

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

ZooKeeper ປະກອບດ້ວຍຫຍັງ? ມີ 4 ສິ່ງຕົ້ນຕໍ. ນີ້ແມ່ນຂະບວນການປຸງແຕ່ງ - ຮ້ອງຂໍ. ແລະຍັງ ZooKeeper Atomic Broadcast. ມີບັນທຶກຄໍາຫມັ້ນສັນຍາທີ່ການດໍາເນີນງານທັງຫມົດຖືກບັນທຶກໄວ້. ແລະ In-memory Replicated DB ຕົວຂອງມັນເອງ, i.e. ຖານຂໍ້ມູນຂອງມັນເອງທີ່ຕົ້ນໄມ້ທັງຫມົດນີ້ຖືກເກັບໄວ້.

ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າການປະຕິບັດການຂຽນທັງຫມົດຜ່ານຕົວປະມວນຜົນການຮ້ອງຂໍ. ແລະການອ່ານການດໍາເນີນການໂດຍກົງກັບຖານຂໍ້ມູນ In-memory.

ຖານຂໍ້ມູນຕົວມັນເອງໄດ້ຖືກ replicated ຢ່າງເຕັມສ່ວນ. ຕົວຢ່າງທັງໝົດຂອງ ZooKeeper ເກັບສຳເນົາຂໍ້ມູນຄົບຖ້ວນ.

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

ZooKeeper Atomic Broadcast ແມ່ນສິ່ງທີ່ຖືກນໍາໃຊ້ເພື່ອຮັກສາຂໍ້ມູນຈໍາລອງ.

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

"ຮາໂດບ. ZooKeeper" ຈາກ Mail.Ru Group Technostream ຊຸດ "ວິທີການສໍາລັບການແຈກຢາຍຂໍ້ມູນປະລິມານຂະຫນາດໃຫຍ່ໃນ Hadoop" ມັນພຽງແຕ່ດໍາເນີນການຂຽນຄໍາຮ້ອງຂໍ. ວຽກງານຕົ້ນຕໍຂອງມັນແມ່ນວ່າມັນຫັນປ່ຽນການດໍາເນີນງານໄປສູ່ການປັບປຸງການເຮັດທຸລະກໍາ. ນີ້ແມ່ນຄຳຮ້ອງຂໍທີ່ສ້າງຂຶ້ນສະເພາະ.

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