ການກໍ່ສ້າງຕັນຂອງຄໍາຮ້ອງສະຫມັກແຈກຢາຍ. ການ​ປະ​ມານ​ຄັ້ງ​ທີ​ສອງ​

ແຈ້ງການ

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

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

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

ການຈັດຕັ້ງການບໍລິການ

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

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

1. ດຽວນີ້ການບໍລິການຄວນປະມວນຜົນການຮ້ອງຂໍຢູ່ໃນ 5 nodes cluster,
2. ສາມາດປະຕິບັດວຽກງານການປຸງແຕ່ງພື້ນຖານ,
3. ແລະຍັງສາມາດຈັດການລາຍການສະໝັກສະມາຊິກແບບໄດນາມິກສຳລັບການອັບເດດໂປຣໄຟລ໌.

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

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

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

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

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

ການຄັດເລືອກຜູ້ນໍາ

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

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

ຫຼັງຈາກເລີ່ມຕົ້ນແລະເຊື່ອມຕໍ່ກັບຈຸດແລກປ່ຽນ, ບໍລິການທັງຫມົດໄດ້ຮັບຂໍ້ຄວາມລະບົບ #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. ຖ້າ LeaderPid ກົງກັບ pid ຂະບວນການປະຈຸບັນ, ມັນໄດ້ຖືກແຕ່ງຕັ້ງເປັນຜູ້ນໍາ, ແລະບັນຊີລາຍຊື່ Servers ປະກອບມີ nodes ທັງຫມົດແລະຕົວກໍານົດການຂອງເຂົາເຈົ້າ.
ໃນປັດຈຸບັນອັນໃຫມ່ປະກົດຂຶ້ນແລະ node cluster ທີ່ເຮັດວຽກຖືກຕັດການເຊື່ອມຕໍ່, ຜູ້ຄວບຄຸມການບໍລິການທັງຫມົດໄດ້ຮັບ #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} respectively

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

ຜູ້ໄກ່ເກ່ຍ

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

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

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

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

ໃຫ້ພວກເຮົາເປີດຕົວພຣັອກຊີນີ້ຢູ່ໃນເຊີບເວີຊັ້ນການເຂົ້າເຖິງ, ແລະທຸກຂະບວນການຂອງພວກເຮົາທີ່ໃຫ້ບໍລິການ websocket api ຈະສະໝັກໃຊ້ມັນ, ແລະບໍ່ແມ່ນຈຸດແລກປ່ຽນ pub-sub ຕົ້ນສະບັບໃນ kernel. ພຣັອກຊີສະໝັກໃຊ້ຫຼັກພຽງແຕ່ໃນກໍລະນີຂອງການສະຫມັກທີ່ເປັນເອກະລັກແລະ replicates ຂໍ້ຄວາມທີ່ເຂົ້າມາໃຫ້ກັບຜູ້ຈອງທັງຫມົດ.
ດັ່ງນັ້ນ, 5 ຂໍ້ຄວາມຈະຖືກສົ່ງລະຫວ່າງ kernel ແລະການເຂົ້າເຖິງເຄື່ອງແມ່ຂ່າຍ, ແທນທີ່ຈະ 50000.

ເສັ້ນທາງແລະການດຸ່ນດ່ຽງ

Req-Resp

ໃນການປະຕິບັດການສົ່ງຂໍ້ຄວາມໃນປະຈຸບັນ, ມີ 7 ຍຸດທະສາດການແຈກຢາຍຄໍາຮ້ອງຂໍ:

• default. ຄໍາຮ້ອງຂໍຖືກສົ່ງໄປຫາຜູ້ຄວບຄຸມທັງຫມົດ.
• round-robin. ການຮ້ອງຂໍແມ່ນໄດ້ຖືກນັບແລະແຈກຢາຍຮອບວຽນລະຫວ່າງຕົວຄວບຄຸມ.
• consensus. ຜູ້ຄວບຄຸມທີ່ໃຫ້ບໍລິການແມ່ນແບ່ງອອກເປັນຜູ້ນໍາແລະສໍາລອງ. ການຮ້ອງຂໍແມ່ນຖືກສົ່ງໄປຫາຜູ້ນໍາເທົ່ານັ້ນ.
• consensus & round-robin. ກຸ່ມມີຜູ້ນໍາ, ແຕ່ຄໍາຮ້ອງຂໍໄດ້ຖືກແຈກຢາຍໃນບັນດາສະມາຊິກທັງຫມົດ.
• sticky. ຟັງຊັນ hash ຖືກຄິດໄລ່ແລະມອບຫມາຍໃຫ້ຕົວຈັດການສະເພາະ. ການຮ້ອງຂໍຕໍ່ໄປທີ່ມີລາຍເຊັນນີ້ໄປຫາຕົວຈັດການດຽວກັນ.
• sticky-fun. ເມື່ອເລີ່ມຕົ້ນຈຸດແລກປ່ຽນ, ຟັງຊັນການຄິດໄລ່ hash ສໍາລັບ sticky ການດຸ່ນດ່ຽງ.
• fun. ຄ້າຍຄືກັນກັບ sticky-fun, ພຽງແຕ່ທ່ານສາມາດເພີ່ມການປ່ຽນເສັ້ນທາງ, ປະຕິເສດຫຼື pre-process ມັນ.

ຍຸດທະສາດການແຈກຢາຍຖືກກໍານົດເມື່ອຈຸດແລກປ່ຽນເລີ່ມຕົ້ນ.

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

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

ຮ້ານຍ່ອຍ

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

ຄວາມ​ສາ​ມາດ​ຂະ​ຫຍາຍ​ຕົວ​ແລະ​ຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​ພາດ​

ຄວາມ​ສາ​ມາດ​ຂະ​ຫຍາຍ​ຕົວ​ຂອງ​ລະ​ບົບ​ທັງ​ຫມົດ​ແມ່ນ​ຂຶ້ນ​ກັບ​ລະ​ດັບ​ຂອງ​ການ​ຂະ​ຫຍາຍ​ຕົວ​ຂອງ​ຊັ້ນ​ແລະ​ອົງ​ປະ​ກອບ​ຂອງ​ລະ​ບົບ​:

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

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

ການຈອງ

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

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

ຜະລິດຕະພັນ

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

ໃນວັກທີ 6.14.1.2.1.2.2. ເອກະສານຕົ້ນສະບັບສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບຂອງ RPC CAST:

ພວກເຮົາຈະບໍ່ເຮັດການຕັ້ງຄ່າເພີ່ມເຕີມຕໍ່ກັບ OS kernel ຫຼື erlang VM ລ່ວງໜ້າ. ເງື່ອນ​ໄຂ​ສໍາ​ລັບ​ການ​ທົດ​ສອບ​:

• erl opts: +A1 +sbtu.
• ການທົດສອບພາຍໃນ node erlang ດຽວແມ່ນດໍາເນີນການໃນຄອມພິວເຕີໂນດບຸກທີ່ມີ i7 ເກົ່າໃນສະບັບມືຖື.
• ການທົດສອບກຸ່ມແມ່ນດໍາເນີນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍທີ່ມີເຄືອຂ່າຍ 10G.
• ລະຫັດດໍາເນີນການຢູ່ໃນ docker containers. ເຄືອຂ່າຍໃນໂໝດ NAT.

ລະຫັດການທົດສອບ:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

ສະຖານະການ 1: ການ​ທົດ​ສອບ​ແມ່ນ​ດໍາ​ເນີນ​ການ​ໃນ​ຄອມ​ພິວ​ເຕີ​ທີ່​ມີ​ສະ​ບັບ​ມື​ຖື i7 ເກົ່າ​. ການທົດສອບ, ການສົ່ງຂໍ້ຄວາມແລະການບໍລິການແມ່ນປະຕິບັດຢູ່ໃນຫນຶ່ງ node ໃນຫນຶ່ງ Docker container:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

ສະຖານະການ 2: 3 nodes ແລ່ນຢູ່ໃນເຄື່ອງທີ່ແຕກຕ່າງກັນພາຍໃຕ້ docker (NAT).

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

ໃນທຸກກໍລະນີ, ການໃຊ້ CPU ບໍ່ໄດ້ເກີນ 250%

ຜົນໄດ້ຮັບ

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

ການ​ຖ່າຍ​ຮູບ @chuttersnap

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

ຫົວຂໍ້ໃດແດ່ທີ່ຂ້ອຍຄວນກວມເອົາໃນລາຍລະອຽດເພີ່ມເຕີມເປັນສ່ວນຫນຶ່ງຂອງຊຸດການທົດລອງ VTrade?

• ທິດສະດີ: ຕະຫຼາດ, ຄໍາສັ່ງແລະເວລາຂອງພວກເຂົາ: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC

• ປື້ມ​ບັນ​ທຶກ​ຂອງ​ຄໍາ​ສັ່ງ​. ທິດສະດີແລະການປະຕິບັດການປະຕິບັດປື້ມທີ່ມີກຸ່ມ

• Visualization of trading: Ticks, bars, ການແກ້ໄຂ. ວິທີການເກັບຮັກສາແລະວິທີການກາວ

• ຫ້ອງການຫຼັງ. ການວາງແຜນ ແລະການພັດທະນາ. ການ​ຕິດ​ຕາມ​ກວດ​ກາ​ພະ​ນັກ​ງານ​ແລະ​ການ​ສືບ​ສວນ​ເຫດ​ການ​

• API. ໃຫ້ພວກເຮົາຄິດອອກສິ່ງທີ່ຕ້ອງການການໂຕ້ຕອບແລະວິທີການປະຕິບັດພວກມັນ

• ການເກັບຮັກສາຂໍ້ມູນ: PostgreSQL, Timescale, Tarantool ໃນລະບົບການຄ້າ

• ປະຕິກິລິຍາໃນລະບົບການຄ້າ

• ອື່ນໆ. ຂ້ອຍຈະຂຽນໃນຄໍາເຫັນ

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

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