ວິວັດທະນາການຂອງສະຖາປັດຕະຍະກໍາຂອງລະບົບການຄ້າແລະການເກັບກູ້ຂອງ Moscow Exchange. ພາກທີ 1

ສະບາຍດີທຸກຄົນ! ຊື່ຂອງຂ້ອຍແມ່ນ Sergey Kostanbaev, ໃນການແລກປ່ຽນຂ້ອຍກໍາລັງພັດທະນາຫຼັກຂອງລະບົບການຄ້າ.

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

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

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

ປະຫວັດສາດເລັກນ້ອຍ

ໃນປີ 1994, ລະບົບ ASTS ຂອງອົດສະຕຣາລີໄດ້ເປີດຕົວໃນ Moscow Interbank Currency Exchange (MICEX), ແລະຈາກເວລານັ້ນ, ປະຫວັດສາດຂອງການຄ້າເອເລັກໂຕຣນິກຂອງລັດເຊຍສາມາດນັບໄດ້. ໃນປີ 1998, ສະຖາປັດຕະຍະກໍາການແລກປ່ຽນໄດ້ຮັບການປັບປຸງໃຫ້ທັນສະໄຫມເພື່ອແນະນໍາການຊື້ຂາຍທາງອິນເຕີເນັດ. ນັບຕັ້ງແຕ່ນັ້ນມາ, ຄວາມໄວຂອງການປະຕິບັດການແກ້ໄຂໃຫມ່ແລະການປ່ຽນແປງທາງສະຖາປັດຕະຍະກໍາໃນທຸກລະບົບແລະລະບົບຍ່ອຍພຽງແຕ່ໄດ້ຮັບການເພີ່ມຂຶ້ນ.

ໃນປີນັ້ນ, ລະບົບການແລກປ່ຽນເຮັດວຽກຢູ່ໃນຮາດແວຊັ້ນສູງ - ເຊີບເວີ HP Superdome 9000 ທີ່ເຊື່ອຖືໄດ້ສູງສຸດ (ສ້າງຢູ່ໃນ PA-RISC), ເຊິ່ງທຸກສິ່ງທຸກຢ່າງແມ່ນຊ້ໍາກັນ: ລະບົບຍ່ອຍຂາເຂົ້າ / ຜົນຜະລິດ, ເຄືອຂ່າຍ, RAM (ໃນຄວາມເປັນຈິງ, ມີ RAID array ຂອງ RAM), ໂປເຊດເຊີ (ຮ້ອນ-ແລກປ່ຽນ). ມັນເປັນໄປໄດ້ທີ່ຈະປ່ຽນອົງປະກອບຂອງເຄື່ອງແມ່ຂ່າຍໃດໆໂດຍບໍ່ຕ້ອງຢຸດເຄື່ອງ. ພວກເຮົາອາໄສອຸປະກອນເຫຼົ່ານີ້ ແລະຖືວ່າພວກມັນບໍ່ປອດໄພເກືອບໝົດ. ລະບົບປະຕິບັດການແມ່ນລະບົບ Unix ຄ້າຍຄື HP UX.

ແຕ່ນັບຕັ້ງແຕ່ປະມານປີ 2010, ປະກົດການຫນຶ່ງໄດ້ເກີດຂື້ນທີ່ເອີ້ນວ່າການຊື້ຂາຍຄວາມຖີ່ສູງ (HFT), ຫຼືການຊື້ຂາຍຄວາມຖີ່ສູງ - ເວົ້າງ່າຍໆ, ຫຸ່ນຍົນການແລກປ່ຽນຫຼັກຊັບ. ໃນເວລາພຽງແຕ່ 2,5 ປີ, ການໂຫຼດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາໄດ້ເພີ່ມຂຶ້ນ 140 ເທື່ອ.

ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະທົນຕໍ່ການໂຫຼດດັ່ງກ່າວກັບສະຖາປັດຕະຍະກໍາແລະອຸປະກອນເກົ່າ. ມັນ ຈຳ ເປັນທີ່ຈະປັບຕົວເຂົ້າກັນໄດ້.

Начало

ການຮ້ອງຂໍຕໍ່ລະບົບການແລກປ່ຽນສາມາດແບ່ງອອກເປັນສອງປະເພດ:

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

ໂດຍວິທີທາງການ, ຫຼັກຂອງລະບົບສາມາດແບ່ງອອກເປັນສາມລະດັບ:

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

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

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

ຮຸ່ນທໍາອິດຂອງລະບົບມີສອງລະດັບຂອງ Gateway ແລະເຄື່ອງແມ່ຂ່າຍກາງຂອງລະບົບການຄ້າ. ຂະບວນການເຮັດວຽກເປັນແບບນີ້:

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

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

ເນື່ອງຈາກລະຫັດແມ່ນກະທູ້ດຽວ, ໂຄງການຄລາສສິກທີ່ມີສ້ອມຂະບວນການໄດ້ຖືກນໍາໃຊ້ເພື່ອຮັບໃຊ້ລູກຄ້າຈໍານວນຫຼາຍ. ຢ່າງໃດກໍ່ຕາມ, ມັນມີລາຄາແພງຫຼາຍທີ່ຈະຕັດຖານຂໍ້ມູນທັງຫມົດ, ດັ່ງນັ້ນຂະບວນການບໍລິການທີ່ມີນ້ໍາຫນັກເບົາໄດ້ຖືກນໍາໃຊ້ທີ່ລວບລວມແພັກເກັດຈາກກອງປະຊຸມ TCP ແລະໂອນໃຫ້ພວກເຂົາຢູ່ໃນແຖວດຽວ (SystemV Message Queue). Gateway ແລະເຄື່ອງຈັກການຄ້າເຮັດວຽກພຽງແຕ່ກັບແຖວນີ້, ເອົາທຸລະກໍາຈາກບ່ອນນັ້ນເພື່ອປະຕິບັດ. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະສົ່ງຄໍາຕອບໄປຫາມັນ, ເພາະວ່າມັນບໍ່ຊັດເຈນວ່າຂະບວນການບໍລິການໃດຄວນອ່ານມັນ. ດັ່ງນັ້ນພວກເຮົາໄດ້ໃຊ້ວິທີການຫຼອກລວງ: ແຕ່ລະຂະບວນການ forked ໄດ້ສ້າງແຖວຕອບສະຫນອງສໍາລັບຕົວມັນເອງ, ແລະເມື່ອຄໍາຮ້ອງຂໍເຂົ້າມາໃນແຖວທີ່ເຂົ້າມາ, tag ສໍາລັບແຖວຕອບສະຫນອງຈະຖືກເພີ່ມໃສ່ມັນທັນທີ.

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

SystemV IPC ປະ​ກອບ​ມີ​ອຸ​ປະ​ກອນ​ສໍາ​ລັບ​ການ​ເບິ່ງ​ສະ​ຖາ​ນະ​ຂອງ​ແຖວ​, ຄວາມ​ຊົງ​ຈໍາ​, ແລະ​ວັດ​ຖຸ semaphore​. ພວກເຮົາໃຊ້ສິ່ງນີ້ຢ່າງຈິງຈັງເພື່ອເຂົ້າໃຈສິ່ງທີ່ເກີດຂຶ້ນໃນລະບົບໃນຊ່ວງເວລາສະເພາະ, ບ່ອນທີ່ແພັກເກັດສະສົມ, ສິ່ງທີ່ຖືກບລັອກ, ແລະອື່ນໆ.

ຄວາມທັນສະ ໄໝ ທຳ ອິດ

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

ຜົນກະທົບຂອງການຊື້ຂາຍຄວາມຖີ່ສູງ

ສະບັບຂ້າງເທິງຂອງສະຖາປັດຕະຍະກໍາມີຢູ່ຈົນກ່ວາ 2010. ໃນຂະນະດຽວກັນ, ພວກເຮົາບໍ່ພໍໃຈກັບປະສິດທິພາບຂອງເຊີບເວີ HP Superdome ອີກຕໍ່ໄປ. ນອກຈາກນັ້ນ, ສະຖາປັດຕະຍະກໍາ PA-RISC ແມ່ນເກືອບຕາຍ; ຜູ້ຂາຍບໍ່ໄດ້ສະເຫນີການປັບປຸງທີ່ສໍາຄັນໃດໆ. ດັ່ງນັ້ນ, ພວກເຮົາເລີ່ມຍ້າຍຈາກ HP UX/PA RISC ໄປ Linux/x86. ການປ່ຽນແປງໄດ້ເລີ່ມຕົ້ນດ້ວຍການປັບຕົວຂອງເຄື່ອງແມ່ຂ່າຍການເຂົ້າເຖິງ.

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

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

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

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

ຮອບໃໝ່ຂອງວິວັດທະນາການ

ຫຼັງຈາກການທົດສອບແລະການຄົ້ນຄວ້າຢ່າງກວ້າງຂວາງ, ພວກເຮົາໄດ້ປ່ຽນໄປຫາ kernel ລະບົບປະຕິບັດການໃນເວລາທີ່ແທ້ຈິງ. ສໍາລັບນີ້ພວກເຮົາໄດ້ເລືອກ RedHat Enterprise MRG Linux, ບ່ອນທີ່ MRG ຫຍໍ້ມາຈາກການສົ່ງຂໍ້ຄວາມຕາມເວລາຈິງ. ຂໍ້ໄດ້ປຽບຂອງ patches ໃນເວລາທີ່ແທ້ຈິງແມ່ນວ່າພວກເຂົາເພີ່ມປະສິດທິພາບຂອງລະບົບສໍາລັບການປະຕິບັດທີ່ໄວທີ່ສຸດ: ຂະບວນການທັງຫມົດແມ່ນຖືກຈັດໃສ່ໃນແຖວ FIFO, ແກນສາມາດຖືກແຍກອອກ, ບໍ່ມີການຖອດອອກ, ການເຮັດທຸລະກໍາທັງຫມົດຖືກດໍາເນີນຕາມລໍາດັບທີ່ເຄັ່ງຄັດ.

ສີແດງ - ເຮັດວຽກກັບແຖວໃນ kernel ປົກກະຕິ, ສີຂຽວ - ເຮັດວຽກຢູ່ໃນ kernel ໃນເວລາທີ່ແທ້ຈິງ.

ແຕ່ການບັນລຸເວລາ latency ຕໍ່າໃນເຄື່ອງແມ່ຂ່າຍປົກກະຕິບໍ່ແມ່ນເລື່ອງງ່າຍ:

• ໂຫມດ SMI, ເຊິ່ງໃນສະຖາປັດຕະຍະກໍາ x86 ເປັນພື້ນຖານສໍາລັບການເຮັດວຽກກັບອຸປະກອນເສີມທີ່ສໍາຄັນ, ແຊກແຊງຢ່າງຫຼວງຫຼາຍ. ການປຸງແຕ່ງທຸກປະເພດຂອງເຫດການຮາດແວແລະການຄຸ້ມຄອງອົງປະກອບແລະອຸປະກອນແມ່ນປະຕິບັດໂດຍເຟີມແວໃນອັນທີ່ເອີ້ນວ່າໂຫມດ SMI ໂປ່ງໃສ, ເຊິ່ງໃນລະບົບປະຕິບັດການບໍ່ໄດ້ເຫັນວ່າເຟີມແວກໍາລັງເຮັດຫຍັງເລີຍ. ຕາມກົດລະບຽບ, ຜູ້ຂາຍໃຫຍ່ທັງຫມົດສະເຫນີການຂະຫຍາຍພິເສດສໍາລັບເຄື່ອງແມ່ຂ່າຍເຟີມແວທີ່ອະນຸຍາດໃຫ້ຫຼຸດຜ່ອນການປຸງແຕ່ງ SMI.
• ບໍ່ຄວນມີການຄວບຄຸມແບບເຄື່ອນໄຫວຂອງຄວາມຖີ່ຂອງໂປເຊດເຊີ, ນີ້ນໍາໄປສູ່ການຢຸດເວລາເພີ່ມເຕີມ.
• ເມື່ອບັນທຶກຂອງລະບົບໄຟລ໌ຖືກລ້າງ, ຂະບວນການບາງຢ່າງເກີດຂື້ນໃນ kernel ທີ່ເຮັດໃຫ້ເກີດຄວາມລ່າຊ້າທີ່ບໍ່ສາມາດຄາດເດົາໄດ້.
• ທ່ານຈໍາເປັນຕ້ອງເອົາໃຈໃສ່ກັບສິ່ງຕ່າງໆເຊັ່ນ CPU Affinity, Interrupt affinity, NUMA.

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

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

ຫຼັງຈາກປ່ຽນເປັນ x86, ການປະຕິບັດເພີ່ມຂຶ້ນເກືອບສາມເທົ່າ, ເວລາການປຸງແຕ່ງທຸລະກໍາສະເລ່ຍຫຼຸດລົງເຖິງ 60 μs.

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

epic ສະຫງວນຮ້ອນ

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

ນອກຈາກນັ້ນ, ຍັງມີຄວາມຕ້ອງການອື່ນໆ:

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

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

ດັ່ງນັ້ນ, ພວກເຮົາມາຮອດໂຄງການດັ່ງຕໍ່ໄປນີ້:

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

  

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

ໂຄງການໄດ້ເຮັດວຽກດັ່ງຕໍ່ໄປນີ້.

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

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

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

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