ຄວາມຫຼົງໄຫຼ: ຄວາມສົມບູນແບບ ແລະ... ຄວາມຂີ້ຄ້ານກຳລັງທຳລາຍພວກເຮົາ

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

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

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

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

Shtosh (c) ພວກເຮົາເອົາເວັບໄຊທ໌ທີສອງ, ສ້າງລະບົບທີ່ຄືກັນ ... ຄວາມສັບສົນຈະກາຍເປັນສອງເທົ່າ - ພວກເຮົາມີສອງຫນ່ວຍງານ. ພວກເຮົາຍັງອອກເຫດຜົນທີ່ແນ່ນອນສໍາລັບການໂອນຂໍ້ມູນຈາກເວັບໄຊທ໌ຫນຶ່ງໄປອີກ - ນັ້ນແມ່ນ, ການຈໍາລອງຂໍ້ມູນ, ການຄັດລອກຂໍ້ມູນແບບຄົງທີ່, ແລະອື່ນໆ. ດັ່ງນັ້ນ, ເຫດຜົນຂອງການຈໍາລອງແມ່ນປົກກະຕິແລ້ວສະລັບສັບຊ້ອນຫຼາຍ, ແລະດັ່ງນັ້ນ, ຄວາມສັບສົນທັງຫມົດຂອງລະບົບສາມາດບໍ່ແມ່ນ 2, ແຕ່ 3, 5, 10 ເທົ່າ.

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

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

ມັນເປັນເວລາສໍາລັບ "ເລື່ອງຈາກ w" ... ຈາກຊີວິດ, ແນ່ນອນ.

ຕົວຢ່າງທີ່ຫນຶ່ງ

ຈິນຕະນາການເວັບໄຊທ໌ນາມບັດສໍາລັບໂຮງງານມ້ວນທໍ່ເລກ 1 ໃນເມືອງ N. ມັນຂຽນເປັນຕົວອັກສອນໃຫຍ່ - PIPE ROLLING PLANT No 1 . ຂ້າງລຸ່ມນີ້ແມ່ນຄໍາຂວັນທີ່ວ່າ: "ທໍ່ຂອງພວກເຮົາແມ່ນທໍ່ກົມທີ່ສຸດໃນ N." ແລະຂ້າງລຸ່ມນີ້ແມ່ນເບີໂທລະສັບຂອງ CEO ແລະຊື່ຂອງລາວ. ພວກເຮົາເຂົ້າໃຈວ່າທ່ານຕ້ອງການຈອງ - ນີ້ແມ່ນສິ່ງທີ່ສໍາຄັນຫຼາຍ! ໃຫ້ເລີ່ມຕົ້ນທີ່ຈະຄິດອອກວ່າມັນປະກອບດ້ວຍຫຍັງ. Html-statics - ນັ້ນແມ່ນ, ສອງສາມຮູບພາບທີ່ຜູ້ຈັດການທົ່ວໄປ, ໃນຄວາມເປັນຈິງ, ກໍາລັງປຶກສາຫາລືບາງປະເພດຂອງການຈັດການຕໍ່ໄປຢູ່ໃນໂຕະໃນຫ້ອງອາບນ້ໍາກັບຄູ່ຮ່ວມງານຂອງລາວ. ພວກເຮົາເລີ່ມຄິດກ່ຽວກັບການຢຸດເຮັດວຽກ. ມັນມາຢູ່ໃນໃຈ: ທ່ານຈໍາເປັນຕ້ອງນອນຢູ່ບ່ອນນັ້ນເປັນເວລາຫ້ານາທີ, ບໍ່ມີອີກ. ແລະຫຼັງຈາກນັ້ນຄໍາຖາມທີ່ເກີດຂື້ນ: ມີການຂາຍຫຼາຍປານໃດຈາກເວັບໄຊທ໌ຂອງພວກເຮົາໂດຍທົ່ວໄປ? ຫຼາຍປານໃດ-ຫຼາຍປານໃດ? "ສູນ" ຫມາຍຄວາມວ່າແນວໃດ? ແລະນັ້ນຫມາຍຄວາມວ່າ: ເພາະວ່ານາຍພົນໄດ້ເຮັດທຸລະກໍາທັງຫມົດສີ່ຄັ້ງໃນປີກາຍນີ້ຢູ່ໃນໂຕະດຽວກັນ, ກັບຄົນດຽວກັນກັບຜູ້ທີ່ເຂົາເຈົ້າໄປອາບນໍ້າແລະນັ່ງຢູ່ໂຕະ. ແລະພວກເຮົາເຂົ້າໃຈວ່າເຖິງແມ່ນວ່າເວັບໄຊທ໌ນັ່ງສໍາລັບມື້ຫນຶ່ງ, ບໍ່ມີຫຍັງຮ້າຍແຮງຈະເກີດຂຶ້ນ.

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

ຕົວຢ່າງທີ່ສອງ

ບລັອກຂອງບໍລິສັດ: ຄົນທີ່ໄດ້ຮັບການຝຶກອົບຮົມເປັນພິເສດຂຽນຂ່າວຢູ່ທີ່ນັ້ນ, ພວກເຮົາໄດ້ເຂົ້າຮ່ວມໃນງານວາງສະແດງດັ່ງກ່າວ, ແຕ່ພວກເຮົາອອກຜະລິດຕະພັນໃຫມ່, ແລະອື່ນໆ. ໃຫ້ເວົ້າວ່ານີ້ແມ່ນມາດຕະຖານ PHP ກັບ WordPress, ຖານຂໍ້ມູນຂະຫນາດນ້ອຍແລະເລັກນ້ອຍຂອງ static. ແນ່ນອນ, ມັນມາຢູ່ໃນໃຈອີກເທື່ອຫນຶ່ງວ່າເຈົ້າບໍ່ຄວນນອນຢູ່ໃນສະຖານະການ - "ບໍ່ເກີນຫ້ານາທີ!" ນັ້ນແມ່ນທັງຫມົດ. ແຕ່ຂໍໃຫ້ຄິດຕື່ມອີກ. ບລັອກນີ້ເຮັດຫຍັງ? ປະຊາຊົນມາຈາກ Yandex, ຈາກ Google ໂດຍອີງໃສ່ບາງຄໍາຖາມ, ອິນຊີ. ຍິ່ງໃຫຍ່. ການຂາຍມີຫຍັງກ່ຽວຂ້ອງກັບມັນບໍ? Epiphany: ບໍ່ແມ່ນ. ການຈະລາຈອນໂຄສະນາໄປຫາເວັບໄຊທ໌ຕົ້ນຕໍ, ເຊິ່ງຢູ່ໃນເຄື່ອງຈັກທີ່ແຕກຕ່າງກັນ. ມາເລີ່ມຄິດກ່ຽວກັບໂຄງການຈອງ. ໃນທາງທີ່ດີ, ມັນຈໍາເປັນຕ້ອງໄດ້ຍົກຂຶ້ນມາໃນສອງສາມຊົ່ວໂມງ, ແລະມັນຈະເປັນການດີທີ່ຈະກະກຽມສໍາລັບເລື່ອງນີ້. ມັນຈະສົມເຫດສົມຜົນທີ່ຈະເອົາເຄື່ອງຈັກຈາກສູນຂໍ້ມູນອື່ນ, ມ້ວນສະພາບແວດລ້ອມໃສ່ມັນ, ນັ້ນແມ່ນ, ເຄື່ອງແມ່ຂ່າຍເວັບ, PHP, WordPress, MySQL, ແລະປ່ອຍໃຫ້ມັນຢູ່ທີ່ນັ້ນ. ໃນປັດຈຸບັນໃນເວລາທີ່ພວກເຮົາເຂົ້າໃຈວ່າທຸກສິ່ງທຸກຢ່າງຖືກທໍາລາຍ, ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດສອງຢ່າງ - ມ້ວນ mysql dump 50 ແມັດ, ມັນຈະບິນຢູ່ທີ່ນັ້ນໃນຫນຶ່ງນາທີ, ແລະມ້ວນຮູບພາບຈໍານວນຫນຶ່ງຈາກການສໍາຮອງຢູ່ທີ່ນັ້ນ. ນີ້ຍັງບໍ່ມີສໍາລັບພຣະເຈົ້າຮູ້ວ່າດົນປານໃດ. ດັ່ງນັ້ນ, ໃນເຄິ່ງຊົ່ວໂມງ, ສິ່ງທັງຫມົດເພີ່ມຂຶ້ນ. ບໍ່ມີການຈໍາລອງ, ຫຼືພຣະເຈົ້າໃຫ້ອະໄພຂ້ອຍ, ຄວາມລົ້ມເຫຼວອັດຕະໂນມັດ. ສະ​ຫຼຸບ​: ສິ່ງ​ທີ່​ພວກ​ເຮົາ​ໄດ້​ຢ່າງ​ວ່ອງ​ໄວ​ສາ​ມາດ​ມ້ວນ​ອອກ​ຈາກ​ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ບໍ່​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​.

ຕົວຢ່າງທີ່ສາມ, ສັບສົນຫຼາຍ

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

ທັງຫມົດນີ້ສາມາດສະຫງວນໄດ້ແນວໃດ? ທ່ານຕ້ອງການລົດໃນກໍລະນີໃດກໍ່ຕາມ: ເວລາຫນຶ່ງຊົ່ວໂມງແມ່ນຂ້ອນຂ້າງຫນ້ອຍ. Mysql: ໃນທີ່ນີ້ພວກເຮົາຕ້ອງການການຈໍາລອງ, ການຈໍາລອງແບບສົດໆ, ເພາະວ່າໃນຫນຶ່ງຊົ່ວໂມງ 100 GB ສ່ວນຫຼາຍຈະບໍ່ຖືກເພີ່ມໃສ່ບ່ອນຖິ້ມຂີ້ເຫຍື້ອ. ສະຖິຕິ, ຮູບພາບ: ອີກເທື່ອຫນຶ່ງ, ໃນຫນຶ່ງຊົ່ວໂມງ 500 GB ອາດຈະບໍ່ມີເວລາທີ່ຈະເພີ່ມ. ດັ່ງນັ້ນ, ມັນດີກວ່າທີ່ຈະຄັດລອກຮູບພາບທັນທີ. Redis: ນີ້ແມ່ນບ່ອນທີ່ສິ່ງທີ່ຫນ້າສົນໃຈ. ໃນ Redis, ເຊດຊັນຖືກເກັບໄວ້ - ພວກເຮົາບໍ່ສາມາດພຽງແຕ່ເອົາມັນແລະຝັງມັນ. ເນື່ອງຈາກວ່ານີ້ຈະບໍ່ດີຫຼາຍ: ຜູ້ໃຊ້ທັງຫມົດຈະຖືກອອກຈາກລະບົບ, ກະຕ່າຂອງພວກເຂົາຈະຫວ່າງເປົ່າ, ແລະອື່ນໆ. ປະຊາຊົນຈະຖືກບັງຄັບໃຫ້ໃສ່ຊື່ຜູ້ໃຊ້ແລະລະຫັດຜ່ານຂອງພວກເຂົາຄືນໃຫມ່, ແລະຫຼາຍຄົນອາດຈະແຕກແຍກແລະບໍ່ສໍາເລັດການຊື້. ອີກເທື່ອຫນຶ່ງ, ການປ່ຽນແປງຈະຫຼຸດລົງ. ໃນທາງກົງກັນຂ້າມ, Redis ແມ່ນທັນສະ ໄໝ ໂດຍກົງ, ກັບຜູ້ໃຊ້ທີ່ເຂົ້າສູ່ລະບົບຄັ້ງສຸດທ້າຍອາດຈະບໍ່ຕ້ອງການ. ແລະການປະນີປະນອມທີ່ດີແມ່ນເອົາ Redis ແລະຟື້ນຟູມັນຈາກການສໍາຮອງຂໍ້ມູນຈາກມື້ວານນີ້, ຫຼື, ຖ້າທ່ານເຮັດມັນທຸກໆຊົ່ວໂມງ, ຈາກຫນຶ່ງຊົ່ວໂມງກ່ອນຫນ້ານີ້. ໂຊກດີ, ການຟື້ນຟູມັນຈາກການສໍາຮອງຂໍ້ມູນຫມາຍຄວາມວ່າການຄັດລອກໄຟລ໌ຫນຶ່ງ. ແລະເລື່ອງທີ່ຫນ້າສົນໃຈຫຼາຍທີ່ສຸດແມ່ນ Elasticsearch. ໃຜເຄີຍເກັບ MySQL replication? ໃຜເຄີຍເກັບ Elasticsearch replication? ແລະມັນເຮັດວຽກຕາມປົກກະຕິສໍາລັບໃຜ? ສິ່ງທີ່ຂ້ອຍຫມາຍເຖິງແມ່ນວ່າພວກເຮົາເຫັນຫນ່ວຍງານສະເພາະໃດຫນຶ່ງໃນລະບົບຂອງພວກເຮົາ. ມັນເບິ່ງຄືວ່າເປັນປະໂຫຍດ - ແຕ່ມັນສັບສົນ.
ຊັບຊ້ອນໃນຄວາມຮູ້ສຶກທີ່ເພື່ອນວິສະວະກອນຂອງພວກເຮົາບໍ່ມີປະສົບການເຮັດວຽກກັບມັນ. ຫຼືມີປະສົບການທາງລົບ. ຫຼືພວກເຮົາເຂົ້າໃຈວ່ານີ້ຍັງເປັນເທກໂນໂລຍີໃຫມ່ທີ່ຂ້ອນຂ້າງມີ nuances ຫຼືວັດຖຸດິບ. ພວກເຮົາຄິດວ່າ ... Damn, elastic ຍັງມີສຸຂະພາບດີ, ມັນຍັງໃຊ້ເວລາດົນທີ່ຈະຟື້ນຟູມັນຈາກການສໍາຮອງຂໍ້ມູນ, ຂ້ອຍຄວນເຮັດແນວໃດ? ພວກເຮົາເຂົ້າໃຈວ່າ elastic ໃນກໍລະນີຂອງພວກເຮົາຖືກນໍາໃຊ້ສໍາລັບການຊອກຫາ. ຮ້ານຄ້າອອນໄລນ໌ຂອງພວກເຮົາຂາຍແນວໃດ? ພວກເຮົາໄປຫານັກກາລະຕະຫຼາດແລະຖາມວ່າປະຊາຊົນມາຈາກໃສໂດຍທົ່ວໄປ. ພວກເຂົາຕອບວ່າ: "90% ຈາກຕະຫຼາດ Yandex ມາໂດຍກົງກັບບັດຜະລິດຕະພັນ." ແລະພວກເຂົາຊື້ມັນຫຼືພວກເຂົາບໍ່. ດັ່ງນັ້ນ, ການຄົ້ນຫາແມ່ນຕ້ອງການໂດຍ 10% ຂອງຜູ້ໃຊ້. ແລະການຮັກສາ replication elastic, ໂດຍສະເພາະແມ່ນລະຫວ່າງສູນຂໍ້ມູນທີ່ແຕກຕ່າງກັນໃນເຂດທີ່ແຕກຕ່າງກັນ, ກໍ່ມີຫຼາຍ nuances. ທາງອອກໃດ? ພວກເຮົາເອົາ elastic ຈາກສະຖານທີ່ສະຫງວນແລະບໍ່ເຮັດຫຍັງກັບມັນ. ຖ້າເລື່ອງດັ່ງກ່າວສືບຕໍ່ໄປ, ພວກເຮົາອາດຈະຍົກມັນຂຶ້ນໃນມື້ຫນຶ່ງ, ແຕ່ນີ້ບໍ່ແນ່ນອນ. ຕົວຈິງແລ້ວ, ສະຫຼຸບແມ່ນຄືກັນ, ບວກຫຼືລົບ: ພວກເຮົາ, ອີກເທື່ອຫນຶ່ງ, ບໍ່ໄດ້ຈອງບໍລິການທີ່ບໍ່ມີຜົນກະທົບຕໍ່ເງິນ. ເພື່ອຮັກສາແຜນວາດໃຫ້ງ່າຍກວ່າ.

ຕົວຢ່າງຕົວເລກສີ່, ເຖິງແມ່ນວ່າມີຄວາມຫຍຸ້ງຍາກຫຼາຍ

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

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

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

ຕົວຢ່າງທີ່ຫ້າ, ຍາກທີ່ສົມບູນ

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

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

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

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