ນັກຮຽນຫ້າຄົນ ແລະສາມຮ້ານຂາຍກະແຈມູນຄ່າທີ່ແຈກຢາຍ

ຫຼືວິທີທີ່ພວກເຮົາຂຽນຫ້ອງສະຫມຸດ C ++ ລູກຄ້າສໍາລັບ ZooKeeper, etcd ແລະ Consul KV

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

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

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

ພວກເຮົາໄດ້ຈັດການເພື່ອສ້າງຫ້ອງສະຫມຸດທີ່ສະຫນອງການໂຕ້ຕອບທົ່ວໄປສໍາລັບການເຮັດວຽກກັບ ZooKeeper, etcd ແລະ Consul KV. ຫ້ອງສະຫມຸດແມ່ນຂຽນໃນ C ++, ແຕ່ມີແຜນການທີ່ຈະສົ່ງມັນໄປຫາພາສາອື່ນ.

ຕົວແບບຂໍ້ມູນ

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

ZooKeeper

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

ແລະອື່ນ

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

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

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

ກົງສຸນ K.V.

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

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

ເອົາມັນທັງຫມົດຮ່ວມກັນ

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

• ລໍາດັບ, container ແລະ TTL nodes ບໍ່​ສະ​ຫນັບ​ສະ​ຫນຸນ
• ບໍ່ຮອງຮັບ ACLs
• ວິທີການທີ່ກໍານົດໄວ້ຈະສ້າງລະຫັດຖ້າມັນບໍ່ມີ (ໃນ ZK setData ສົ່ງຄືນຂໍ້ຜິດພາດໃນກໍລະນີນີ້)
• ກໍານົດແລະ cas ວິທີການແມ່ນແຍກອອກ (ໃນ ZK ເຂົາເຈົ້າເປັນສິ່ງຈໍາເປັນສິ່ງດຽວກັນ)
• ວິ​ທີ​ການ​ລົບ​ລຶບ​ການ​ລົບ node ຄຽງ​ຄູ່​ກັບ subtree ຂອງ​ຕົນ (ໃນ ZK delete ຈະ​ກັບ​ຄືນ​ມາ​ຄວາມ​ຜິດ​ພາດ​ຖ້າ node ມີ​ລູກ​)
• ສໍາລັບແຕ່ລະຄີມີພຽງແຕ່ຫນຶ່ງສະບັບ - ສະບັບມູນຄ່າ (ໃນ ZK ມີສາມຂອງເຂົາເຈົ້າ)

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

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

subtleties ຂອງການປະຕິບັດ

ຂໍໃຫ້ພິຈາລະນາຢ່າງລະອຽດກ່ຽວກັບບາງດ້ານຂອງການປະຕິບັດການໂຕ້ຕອບຫ້ອງສະຫມຸດໃນລະບົບຕ່າງໆ.

ລໍາດັບຊັ້ນໃນແລະອື່ນໆ

ການຮັກສາທັດສະນະແບບລໍາດັບຊັ້ນໃນ etcd ໄດ້ກາຍເປັນຫນຶ່ງໃນວຽກງານທີ່ຫນ້າສົນໃຈຫຼາຍທີ່ສຸດ. Range queries ເຮັດໃຫ້ມັນງ່າຍທີ່ຈະດຶງລາຍຊື່ຂອງລະຫັດທີ່ມີຄໍານໍາຫນ້າທີ່ກໍານົດໄວ້. ຕົວຢ່າງ, ຖ້າທ່ານຕ້ອງການທຸກສິ່ງທຸກຢ່າງທີ່ເລີ່ມຕົ້ນດ້ວຍ "/foo", ທ່ານກໍາລັງຮ້ອງຂໍໃຫ້ມີຂອບເຂດ ["/foo", "/fop"). ແຕ່ນີ້ຈະສົ່ງຄືນຕົ້ນໄມ້ຍ່ອຍທັງໝົດຂອງກະແຈ, ເຊິ່ງອາດຈະບໍ່ຍອມຮັບໄດ້ຖ້າຕົ້ນໄມ້ຍ່ອຍໃຫຍ່. ໃນຕອນທໍາອິດພວກເຮົາໄດ້ວາງແຜນທີ່ຈະນໍາໃຊ້ກົນໄກການແປພາສາທີ່ສໍາຄັນ, ປະຕິບັດໃນ zetcd. ມັນກ່ຽວຂ້ອງກັບການເພີ່ມຫນຶ່ງ byte ໃນຕອນຕົ້ນຂອງຄີ, ເທົ່າກັບຄວາມເລິກຂອງ node ໃນຕົ້ນໄມ້. ໃຫ້ຂ້ອຍຍົກຕົວຢ່າງໃຫ້ເຈົ້າ.

"/foo" -> "u01/foo"
"/foo/bar" -> "u02/foo/bar"

ຫຼັງຈາກນັ້ນ, ໄດ້ຮັບການເດັກນ້ອຍທັນທີທັນໃດທັງຫມົດຂອງທີ່ສໍາຄັນ "/foo" ເປັນໄປໄດ້ໂດຍການຮ້ອງຂໍຂອບເຂດ ["u02/foo/", "u02/foo0"). ແມ່ນແລ້ວ, ໃນ ASCII "0" ຢືນຢູ່ທັນທີ "/".

ແຕ່ວິທີການປະຕິບັດການໂຍກຍ້າຍຂອງ vertex ໃນກໍລະນີນີ້? ມັນ turns ໃຫ້​ເຫັນ​ວ່າ​ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ລົບ​ໄລ​ຍະ​ທັງ​ຫມົດ​ຂອງ​ປະ​ເພດ​ ["uXX/foo/", "uXX/foo0") ສໍາລັບ XX ຈາກ 01 ຫາ FF. ແລະຫຼັງຈາກນັ້ນພວກເຮົາໄດ້ແລ່ນເຂົ້າໄປໃນ ຈໍາກັດຈໍານວນການດໍາເນີນງານ ພາຍໃນຫນຶ່ງທຸລະກໍາ.

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

"/very" -> "/u00very"
"/very/long" -> "/very/u00long"
"/very/long/path" -> "/very/long/u00path"

ຫຼັງຈາກນັ້ນ, ການລຶບຄີ "/very" ກາຍເປັນການລຶບ "/u00very" ແລະຂອບເຂດ ["/very/", "/very0"), ແລະໄດ້ຮັບເດັກນ້ອຍທັງຫມົດ - ໃນການຮ້ອງຂໍສໍາລັບຄີຈາກຂອບເຂດ ["/very/u00", "/very/u01").

ການຖອດກະແຈໃນ ZooKeeper

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

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

ຕັ້ງຢູ່ໃນ ZooKeeper

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

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

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

ລາຍລະອຽດດ້ານວິຊາການເພີ່ມເຕີມ

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

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

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

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

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

ຜົນໄດ້ຮັບ

ເບິ່ງສໍາລັບຕົວທ່ານເອງ: liboffkv.

ທີມ​ງານ​ຂອງ​ພວກ​ເຮົາ: Raed Romanov, Ivan Glushenkov, Dmitry Kamaldinov, Victor Krapivensky, Vitaly Ivanin.

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