Bioyino - ແຈກຢາຍ, ຂະຫຍາຍການລວບລວມຕົວຊີ້ວັດ

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

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

ຮຽກຮ້ອງ 1. Github, ຜູ້ພັດທະນາໂຄງການ, ຢຸດເຊົາການສະຫນັບສະຫນູນມັນ: ເຜີຍແຜ່ patches ແລະການແກ້ໄຂ, ຍອມຮັບຂອງພວກເຮົາແລະ (ບໍ່ພຽງແຕ່ຂອງພວກເຮົາ) PR. ໃນສອງສາມເດືອນຜ່ານມາ (ບາງບ່ອນແຕ່ເດືອນກຸມພາ-ມີນາ 2018), ກິດຈະກໍາໄດ້ກັບຄືນມາ, ແຕ່ກ່ອນນັ້ນເກືອບ 2 ປີຂອງຄວາມສະຫງົບຢ່າງສົມບູນ. ນອກຈາກນັ້ນ, ໂຄງການແມ່ນໄດ້ຖືກພັດທະນາ ສໍາລັບຄວາມຕ້ອງການຂອງ Gihub ພາຍໃນ, ເຊິ່ງສາມາດກາຍເປັນອຸປະສັກທີ່ຮ້າຍແຮງຕໍ່ການນໍາສະເຫນີລັກສະນະໃຫມ່.

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

ດັ່ງທີ່ເຄີຍເປັນ

ມັນຄວນຈະເປັນແນວໃດ

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

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

ປະການທໍາອິດ, ຄວາມອົດທົນຄວາມຜິດ, ດັ່ງນັ້ນບັນຫາກະທັນຫັນໃນເຄື່ອງແມ່ຂ່າຍບໍ່ເຮັດໃຫ້ເປັນ apocalypse zombie psychiatric ໃນຫ້ອງການ. ອັນທີສອງ, ການຂະຫຍາຍຂະຫນາດເພື່ອໃຫ້ສາມາດຍອມຮັບໄດ້ຫຼາຍກວ່າ 4 ລ້ານ MPS, ໂດຍບໍ່ມີການຂຸດຄົ້ນເລິກເຂົ້າໄປໃນ stack ເຄືອຂ່າຍ Linux ແລະການຂະຫຍາຍຕົວຢ່າງສະຫງົບ "ກວ້າງ" ກັບຂະຫນາດທີ່ຕ້ອງການ.

ເນື່ອງຈາກພວກເຮົາມີພື້ນທີ່ສໍາລັບການປັບຂະຫນາດ, ພວກເຮົາຕັດສິນໃຈເລີ່ມຕົ້ນດ້ວຍຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ. "ກ່ຽວກັບ! ຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​! ມັນງ່າຍດາຍ, ພວກເຮົາສາມາດເຮັດໄດ້,” ພວກເຮົາຄິດແລະເປີດຕົວ 2 ເຊີຟເວີ, ຍົກສໍາເນົາຂອງ brubeck ໃນແຕ່ລະ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຕ້ອງຄັດລອກການຈະລາຈອນທີ່ມີ metrics ກັບເຄື່ອງແມ່ຂ່າຍທັງສອງແລະແມ້ກະທັ້ງຂຽນສໍາລັບການນີ້ ຜົນປະໂຫຍດຂະຫນາດນ້ອຍ. ພວກ​ເຮົາ​ໄດ້​ແກ້​ໄຂ​ບັນ​ຫາ​ຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​ກັບ​ນີ້​, ແຕ່ ... ບໍ່​ໄດ້​ດີ​ຫຼາຍ​. ໃນຕອນທໍາອິດທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າດີ: ແຕ່ລະ brubeck ລວບລວມສະບັບຂອງຕົນເອງ, ຂຽນຂໍ້ມູນໃສ່ Graphite ທຸກໆ 30 ວິນາທີ, ຂຽນທັບໄລຍະເກົ່າ (ອັນນີ້ແມ່ນເຮັດຢູ່ດ້ານ Graphite). ຖ້າເຄື່ອງແມ່ຂ່າຍຫນຶ່ງລົ້ມເຫລວຢ່າງກະທັນຫັນ, ພວກເຮົາສະເຫມີມີອັນທີສອງທີ່ມີສໍາເນົາຂອງຕົນເອງຂອງຂໍ້ມູນລວມ. ແຕ່ນີ້ແມ່ນບັນຫາ: ຖ້າເຄື່ອງແມ່ຂ່າຍລົ້ມເຫລວ, "saw" ປາກົດຢູ່ໃນກາຟ. ນີ້ແມ່ນເນື່ອງມາຈາກຄວາມຈິງທີ່ວ່າຊ່ວງເວລາ 30 ວິນາທີຂອງ brubeck ບໍ່ໄດ້ຖືກ synchronized, ແລະໃນເວລາທີ່ເກີດອຸປະຕິເຫດຫນຶ່ງໃນນັ້ນບໍ່ໄດ້ຖືກຂຽນທັບ. ເມື່ອເຄື່ອງແມ່ຂ່າຍທີສອງເລີ່ມຕົ້ນ, ສິ່ງດຽວກັນເກີດຂຶ້ນ. ຂ້ອນຂ້າງທົນທານ, ແຕ່ຂ້ອຍຕ້ອງການທີ່ດີກວ່າ! ບັນຫາ​ການ​ຂະ​ຫຍາຍ​ຕົວ​ຍັງ​ບໍ່​ທັນ​ໝົດ​ໄປ. metrics ທັງຫມົດຍັງ "ບິນ" ກັບເຄື່ອງແມ່ຂ່າຍດຽວ, ແລະດັ່ງນັ້ນພວກເຮົາໄດ້ຖືກຈໍາກັດພຽງແຕ່ 2-4 ລ້ານ MPS, ຂຶ້ນກັບລະດັບເຄືອຂ່າຍ.

ຖ້າທ່ານຄິດເລັກນ້ອຍກ່ຽວກັບບັນຫາແລະໃນເວລາດຽວກັນຂຸດຫິມະດ້ວຍຊ້ວນ, ຄວາມຄິດທີ່ຊັດເຈນຕໍ່ໄປນີ້ອາດຈະມາຮອດໃຈ: ທ່ານຕ້ອງການ statsd ທີ່ສາມາດເຮັດວຽກໃນຮູບແບບແຈກຢາຍ. ນັ້ນແມ່ນ, ຫນຶ່ງທີ່ປະຕິບັດ synchronization ລະຫວ່າງ nodes ໃນເວລາແລະ metrics. "ແນ່ນອນ, ການແກ້ໄຂດັ່ງກ່າວອາດຈະມີຢູ່ແລ້ວ," ພວກເຮົາເວົ້າແລະໄປຫາ Google…. ແລະພວກເຂົາບໍ່ພົບຫຍັງເລີຍ. ຫຼັງຈາກຜ່ານເອກະສານສໍາລັບ statsd ທີ່ແຕກຕ່າງກັນ (https://github.com/etsy/statsd/wiki#server-implementations ມາຮອດວັນທີ 11.12.2017 ທັນວາ XNUMX), ພວກເຮົາພົບວ່າບໍ່ມີຫຍັງແທ້ໆ. ປາກົດຂື້ນ, ທັງນັກພັດທະນາແລະຜູ້ໃຊ້ຂອງວິທີແກ້ໄຂເຫຼົ່ານີ້ຍັງບໍ່ທັນໄດ້ພົບກັບ metrics ຫຼາຍດັ່ງນັ້ນ, ຖ້າບໍ່ດັ່ງນັ້ນພວກເຂົາຈະມາກັບບາງສິ່ງບາງຢ່າງແນ່ນອນ.

ແລະຫຼັງຈາກນັ້ນພວກເຮົາຈື່ຈໍາກ່ຽວກັບ "toy" statsd - bioyino, ເຊິ່ງໄດ້ຖືກຂຽນຢູ່ທີ່ Just for Fun hackathon (ຊື່ຂອງໂຄງການແມ່ນສ້າງຂຶ້ນໂດຍ script ກ່ອນທີ່ຈະເລີ່ມຕົ້ນຂອງ hackathon) ແລະຮັບຮູ້ວ່າພວກເຮົາຕ້ອງການ statsd ຂອງພວກເຮົາດ່ວນ. ເພື່ອ​ຫຍັງ?

• ເນື່ອງຈາກວ່າມີ statsd clones ຫນ້ອຍເກີນໄປໃນໂລກ,
• ເນື່ອງຈາກວ່າມັນເປັນໄປໄດ້ທີ່ຈະສະຫນອງຄວາມຕ້ອງການຫຼືໃກ້ຊິດກັບຄວາມທົນທານແລະຄວາມຜິດທີ່ຕ້ອງການ (ລວມທັງ synchronizing metrics ລວມລະຫວ່າງເຄື່ອງແມ່ຂ່າຍແລະການແກ້ໄຂບັນຫາການສົ່ງຂໍ້ຂັດແຍ່ງ),
• ເນື່ອງຈາກວ່າມັນເປັນໄປໄດ້ທີ່ຈະຄິດໄລ່ metrics ໄດ້ຢ່າງຖືກຕ້ອງກ່ວາ brubeck,
• ເພາະວ່າເຈົ້າສາມາດເກັບກຳສະຖິຕິທີ່ລະອຽດກວ່ານັ້ນເອງ, ເຊິ່ງຕົວຈິງແລ້ວ brubeck ບໍ່ໄດ້ສະໜອງໃຫ້ພວກເຮົາ,
• ຍ້ອນວ່າຂ້ອຍມີໂອກາດທີ່ຈະຂຽນໂປແກຼມຫ້ອງທົດລອງທີ່ມີຂະ ໜາດ ທີ່ແຈກຢາຍຂອງ hyperperformance ຂອງຂ້ອຍເອງ, ເຊິ່ງຈະບໍ່ສົມບູນແບບສະຖາປັດຕະຍະ ກຳ ຂອງ hyperfor ທີ່ຄ້າຍຄືກັນອື່ນ ... ດີ, ນັ້ນແມ່ນມັນ.

ຈະຂຽນຫຍັງແດ່? ແນ່ນອນ, ໃນ Rust. ເປັນຫຍັງ?

• ເນື່ອງຈາກວ່າມີການແກ້ໄຂຕົ້ນແບບແລ້ວ,
• ເນື່ອງຈາກວ່າຜູ້ຂຽນຂອງບົດຄວາມໄດ້ຮູ້ຈັກ Rust ໃນເວລານັ້ນແລະມີຄວາມກະຕືລືລົ້ນທີ່ຈະຂຽນບາງສິ່ງບາງຢ່າງໃນມັນເພື່ອການຜະລິດໂດຍມີໂອກາດທີ່ຈະເອົາມັນຢູ່ໃນແຫຼ່ງເປີດ,
• ເນື່ອງຈາກວ່າພາສາທີ່ມີ GC ບໍ່ເຫມາະສົມສໍາລັບພວກເຮົາເນື່ອງຈາກລັກສະນະຂອງການຈະລາຈອນທີ່ໄດ້ຮັບ (ເກືອບໃນເວລາທີ່ແທ້ຈິງ) ແລະການຢຸດ GC ແມ່ນບໍ່ສາມາດຍອມຮັບໄດ້,
• ເພາະວ່າທ່ານຕ້ອງການປະສິດທິພາບສູງສຸດທຽບກັບ C
• ເນື່ອງຈາກວ່າ Rust ໃຫ້ພວກເຮົາມີຄວາມບໍ່ຫນ້າຢ້ານກົວ, ແລະຖ້າພວກເຮົາເລີ່ມຂຽນມັນຢູ່ໃນ C / C ++, ພວກເຮົາຈະມີຈຸດອ່ອນຫຼາຍ, buffer overflows, ສະພາບເຊື້ອຊາດແລະຄໍາສັບຕ່າງໆທີ່ຫນ້າຢ້ານກວ່າ brubeck.

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

ເວລາຜ່ານໄປ...

ສຸດທ້າຍ, ຫຼັງຈາກຄວາມພະຍາຍາມທີ່ລົ້ມເຫລວຫຼາຍຄັ້ງ, ຮຸ່ນທໍາອິດທີ່ເຮັດວຽກແມ່ນກຽມພ້ອມ. ເກີດ​ຫຍັງ​ຂຶ້ນ? ນີ້ແມ່ນສິ່ງທີ່ເກີດຂຶ້ນ.

ແຕ່ລະ node ໄດ້ຮັບຊຸດ metrics ຂອງຕົນເອງແລະສະສົມໃຫ້ເຂົາເຈົ້າ, ແລະບໍ່ລວມ metrics ສໍາລັບປະເພດທີ່ຊຸດເຕັມຂອງພວກເຂົາແມ່ນຕ້ອງການສໍາລັບການລວບລວມສຸດທ້າຍ. ໂຫນດແມ່ນເຊື່ອມຕໍ່ກັນໂດຍບາງປະເພດຂອງໂປໂຕຄອນລັອກທີ່ແຈກຢາຍ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດເລືອກເອົາຫນຶ່ງໃນພວກມັນພຽງແຕ່ຫນຶ່ງ (ທີ່ນີ້ພວກເຮົາຮ້ອງໄຫ້) ທີ່ສົມຄວນທີ່ຈະສົ່ງ metrics ໄປຫາຜູ້ຍິ່ງໃຫຍ່. ບັນຫານີ້ກຳລັງຖືກແກ້ໄຂໂດຍ ກົງສຸນ, ແຕ່ໃນອະນາຄົດຄວາມທະເຍີທະຍານຂອງຜູ້ຂຽນຂະຫຍາຍໄປ ເປັນເຈົ້າຂອງ ການຈັດຕັ້ງປະຕິບັດ Raft, ບ່ອນທີ່ມີຄ່າຄວນທີ່ສຸດ, ແນ່ນອນ, ເປັນຈຸດຜູ້ນໍາທີ່ເຫັນດີນໍາ. ນອກເຫນືອຈາກການເປັນເອກະສັນກັນ, nodes ຂ້ອນຂ້າງເລື້ອຍໆ (ຫນຶ່ງຄັ້ງຕໍ່ວິນາທີໂດຍຄ່າເລີ່ມຕົ້ນ) ສົ່ງໄປຫາປະເທດເພື່ອນບ້ານຂອງພວກເຂົາພາກສ່ວນເຫຼົ່ານັ້ນຂອງ metrics ທີ່ລວບລວມລ່ວງຫນ້າທີ່ພວກເຂົາຈັດການເກັບກໍາໃນວິນາທີນັ້ນ. ມັນສະແດງໃຫ້ເຫັນວ່າການປັບຂະຫນາດແລະຄວາມທົນທານຕໍ່ຄວາມຜິດຖືກຮັກສາໄວ້ - ແຕ່ລະ node ຍັງຖືຊຸດ metrics ເຕັມ, ແຕ່ metrics ໄດ້ຖືກສົ່ງໄປລວມແລ້ວ, ຜ່ານ TCP ແລະເຂົ້າລະຫັດເປັນ binary protocol, ດັ່ງນັ້ນຄ່າໃຊ້ຈ່າຍໃນການຊ້ໍາກັນແມ່ນຫຼຸດລົງຢ່າງຫຼວງຫຼາຍເມື່ອທຽບກັບ UDP. ເຖິງວ່າຈະມີຈໍານວນຂະຫນາດໃຫຍ່ພໍສົມຄວນຂອງ metrics ຂາເຂົ້າ, ການສະສົມຮຽກຮ້ອງໃຫ້ມີຫນ່ວຍຄວາມຈໍາຫນ້ອຍຫຼາຍແລະແມ້ກະທັ້ງ CPU ຫນ້ອຍ. ສໍາລັບ mertics ທີ່ສາມາດບີບອັດໄດ້ສູງຂອງພວກເຮົາ, ນີ້ແມ່ນພຽງແຕ່ສອງສາມສິບ megabytes ຂອງຂໍ້ມູນ. ເປັນໂບນັດເພີ່ມເຕີມ, ພວກເຮົາບໍ່ໄດ້ຮັບຂໍ້ມູນທີ່ບໍ່ຈໍາເປັນ rewrites ໃນ Graphite, ເຊັ່ນດຽວກັນກັບກໍລະນີຂອງ burbeck.

ຊຸດ UDP ທີ່ມີ metrics ແມ່ນບໍ່ສົມດຸນລະຫວ່າງ nodes ໃນອຸປະກອນເຄືອຂ່າຍໂດຍຜ່ານ Round Robin ງ່າຍດາຍ. ແນ່ນອນ, ຮາດແວເຄືອຂ່າຍບໍ່ໄດ້ວິເຄາະເນື້ອໃນຂອງແພັກເກັດແລະດັ່ງນັ້ນຈຶ່ງສາມາດດຶງຫຼາຍກ່ວາ 4M ແພັກເກັດຕໍ່ວິນາທີ, ບໍ່ໃຫ້ເວົ້າເຖິງ metrics ທີ່ມັນບໍ່ຮູ້ຫຍັງເລີຍ. ຖ້າພວກເຮົາຄໍານຶງເຖິງວ່າ metrics ບໍ່ໄດ້ມາເທື່ອລະອັນໃນແຕ່ລະຊອງ, ຫຼັງຈາກນັ້ນພວກເຮົາບໍ່ໄດ້ຄາດຄະເນບັນຫາການປະຕິບັດໃດໆໃນສະຖານທີ່ນີ້. ຖ້າເຄື່ອງແມ່ຂ່າຍຂັດຂ້ອງ, ອຸປະກອນເຄືອຂ່າຍຢ່າງໄວວາ (ພາຍໃນ 1-2 ວິນາທີ) ກວດພົບຄວາມຈິງນີ້ແລະເອົາເຄື່ອງແມ່ຂ່າຍທີ່ລົ້ມລົງຈາກການຫມຸນ. ດ້ວຍເຫດນີ້, ໂນດຕົວຕັ້ງຕົວຕີ (i.e. ທີ່ບໍ່ແມ່ນຜູ້ນໍາ) ສາມາດເປີດແລະປິດໄດ້ໂດຍການປະຕິບັດໂດຍບໍ່ມີການສັງເກດເຫັນການ drawdowns ໃນຕາຕະລາງ. ສູງສຸດທີ່ພວກເຮົາສູນເສຍແມ່ນສ່ວນຫນຶ່ງຂອງ metrics ທີ່ເຂົ້າມາໃນວິນາທີສຸດທ້າຍ. ການສູນເສຍ/ປິດ/ສະວິດຂອງຜູ້ນໍາຢ່າງກະທັນຫັນຍັງຈະສ້າງຄວາມຜິດປົກກະຕິເລັກນ້ອຍ (ໄລຍະ 30 ວິນາທີຍັງບໍ່ຖືກຊິງຄ໌), ແຕ່ຖ້າມີການສື່ສານລະຫວ່າງ nodes, ບັນຫາເຫຼົ່ານີ້ສາມາດຖືກຫຼຸດໜ້ອຍລົງໄດ້, ຕົວຢ່າງ, ດ້ວຍການສົ່ງແພັກເກັດການຊິ້ງຂໍ້ມູນອອກ. .

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

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

ບັນຫາຫຼາຍໃນລະຫວ່າງການພັດທະນາແມ່ນເກີດມາຈາກພາກສ່ວນເຄືອຂ່າຍທີ່ຮັບຜິດຊອບສໍາລັບການໄດ້ຮັບ metrics. ເປົ້າຫມາຍຕົ້ນຕໍຂອງການແຍກກະແສເຄືອຂ່າຍເຂົ້າໄປໃນຫນ່ວຍງານແຍກຕ່າງຫາກແມ່ນຄວາມປາຖະຫນາທີ່ຈະຫຼຸດຜ່ອນເວລາທີ່ການໄຫຼເຂົ້າ ບໍ່ ເພື່ອອ່ານຂໍ້ມູນຈາກເຕົ້າຮັບ. ທາງເລືອກທີ່ໃຊ້ asynchronous UDP ແລະ recvmsg ປົກກະຕິຈະຫາຍໄປຢ່າງໄວວາ: ທໍາອິດໃຊ້ CPU ພື້ນທີ່ຜູ້ໃຊ້ຫຼາຍເກີນໄປສໍາລັບການປະມວນຜົນເຫດການ, ທີສອງຕ້ອງການສະຫຼັບສະພາບການຫຼາຍເກີນໄປ. ເພາະສະນັ້ນ, ມັນຖືກນໍາໃຊ້ໃນປັດຈຸບັນ recvmmsg ກັບ buffers ໃຫຍ່ (ແລະ buffers, ເຈົ້າຫນ້າທີ່ສຸພາບບຸລຸດ, ບໍ່ມີຫຍັງສໍາລັບທ່ານ!). ການສະຫນັບສະຫນູນ UDP ປົກກະຕິແມ່ນສະຫງວນໄວ້ສໍາລັບກໍລະນີແສງສະຫວ່າງທີ່ recvmmsg ແມ່ນບໍ່ຈໍາເປັນ. ໃນໂຫມດ multimessage, ມັນເປັນໄປໄດ້ທີ່ຈະບັນລຸສິ່ງຕົ້ນຕໍ: ສ່ວນໃຫຍ່ຂອງເວລາ, ກະທູ້ເຄືອຂ່າຍ rakes ແຖວ OS - ອ່ານຂໍ້ມູນຈາກເຕົ້າຮັບແລະໂອນມັນໄປຫາບ່ອນເກັບຂໍ້ມູນຜູ້ໃຊ້, ພຽງແຕ່ບາງຄັ້ງປ່ຽນໄປໃຫ້ buffer ເຕັມໄປ. ຕົວລວບລວມ. ແຖວຢູ່ໃນເຕົ້າຮັບການປະຕິບັດບໍ່ໄດ້ສະສົມ, ຈໍານວນຂອງຊອງທີ່ຫຼຸດລົງປະຕິບັດບໍ່ໄດ້ຂະຫຍາຍຕົວ.

Примечание

ໃນການຕັ້ງຄ່າເລີ່ມຕົ້ນ, ຂະຫນາດຂອງ buffer ຖືກກໍານົດໃຫ້ຂ້ອນຂ້າງໃຫຍ່. ຖ້າຫາກວ່າທ່ານທັນທີທັນໃດຕັດສິນໃຈທີ່ຈະພະຍາຍາມເຄື່ອງແມ່ຂ່າຍຂອງຕົວທ່ານເອງ, ທ່ານອາດຈະພົບກັບຄວາມຈິງທີ່ວ່າຫຼັງຈາກການສົ່ງຈໍານວນຂະຫນາດນ້ອຍຂອງ metrics, ພວກເຂົາເຈົ້າຈະບໍ່ມາຮອດ Graphite, ຍັງຢູ່ໃນ buffer stream ເຄືອຂ່າຍ. ເພື່ອເຮັດວຽກກັບຈໍານວນ metrics ຈໍານວນຫນ້ອຍ, ທ່ານຈໍາເປັນຕ້ອງກໍານົດ bufsize ແລະ task-queue-size ກັບຄ່າຂະຫນາດນ້ອຍກວ່າໃນ config.

ສຸດທ້າຍ, ບາງຕາຕະລາງສໍາລັບ lovers ຕາຕະລາງ.

ສະຖິຕິກ່ຽວກັບຈໍານວນຂອງ metrics ຂາເຂົ້າສໍາລັບແຕ່ລະເຄື່ອງແມ່ຂ່າຍ: ຫຼາຍກ່ວາ 2 ລ້ານ MPS.

ການປິດການທໍາງານຫນຶ່ງຂອງ nodes ແລະ redistributing metrics ຂາເຂົ້າ.

ສະຖິຕິກ່ຽວກັບ metrics ຂາອອກ: ມີພຽງແຕ່ຫນຶ່ງ node ສະເຫມີສົ່ງ - ນາຍຈ້າງການໂຈມຕີ.

ສະຖິຕິການເຮັດວຽກຂອງແຕ່ລະ node, ຄໍານຶງເຖິງຄວາມຜິດພາດໃນໂມດູນລະບົບຕ່າງໆ.

ລາຍ​ລະ​ອຽດ​ຂອງ​ການ​ວັດ​ແທກ​ຂາ​ເຂົ້າ (ຊື່ metric ຖືກ​ເຊື່ອງ​ໄວ້​)​.

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

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

ດ້ວຍ​ວ່າ​ຈະ​ເວົ້າ​ວ່າ, ຄົນ​ທັງ​ປວງ, ຊື້​ຊ້າງ​ຂອງ​ພວກ​ເຮົາ!

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