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

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

ໃຫ້ພະຍາຍາມກັ່ນຕອງຂໍ້ມູນແລະຂຽນສູດພື້ນຖານ. ພວກ​ເຮົາ​ຈະ​ປັບ​ຂະ​ຫນາດ​ເວັບ​ໄຊ​ການ​ແບ່ງ​ປັນ​ຮູບ​ພາບ​ໃຫມ່​ຂອງ​ພວກ​ເຮົາ Graminsta ຂັ້ນ​ຕອນ​ທີ​ຈາກ 1 ເປັນ 100 ຜູ້​ຊົມ​ໃຊ້.

ຂໍໃຫ້ຂຽນສິ່ງທີ່ປະຕິບັດສະເພາະທີ່ຈະຕ້ອງປະຕິບັດເມື່ອຜູ້ຊົມເພີ່ມຂຶ້ນເປັນ 10, 100, 1000, 10 ແລະ 000 ຄົນ.

ຜູ້ໃຊ້ 1 ຄົນ: 1 ເຄື່ອງ

ເກືອບທຸກຄໍາຮ້ອງສະຫມັກ, ບໍ່ວ່າຈະເປັນເວັບໄຊທ໌ຫຼືຄໍາຮ້ອງສະຫມັກໂທລະສັບມືຖື, ມີສາມອົງປະກອບທີ່ສໍາຄັນ:

• API
• ຖານຂໍ້ມູນ
• ລູກຄ້າ (ແອັບພລິເຄຊັນມືຖືເອງ ຫຼືເວັບໄຊທ໌)

ຖານຂໍ້ມູນເກັບຮັກສາຂໍ້ມູນຄົງທີ່. API ໃຫ້ບໍລິການການຮ້ອງຂໍຕໍ່ຂໍ້ມູນນີ້. ລູກຄ້າສົ່ງຂໍ້ມູນໄປຫາຜູ້ໃຊ້.

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

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

ໃນທາງທິດສະດີ, ພວກເຮົາສາມາດນໍາໄປໃຊ້ໃນຄລາວໃນຕົວຢ່າງ DigitalOcean Droplet ຫຼື AWS EC2, ດັ່ງທີ່ສະແດງຢູ່ຂ້າງລຸ່ມນີ້:

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

10 ຜູ້ໃຊ້: ການເຄື່ອນຍ້າຍຖານຂໍ້ມູນໃນລະດັບແຍກຕ່າງຫາກ

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

ນີ້ແມ່ນສິ່ງທີ່ລະບົບເບິ່ງຄືວ່າໃນປັດຈຸບັນ:

100 ຜູ້ໃຊ້: ການເຄື່ອນຍ້າຍລູກຄ້າໄປສູ່ລະດັບແຍກຕ່າງຫາກ

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

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

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

ນີ້ແມ່ນສິ່ງທີ່ລະບົບດັ່ງກ່າວເບິ່ງຄືວ່າ:

1000 ຜູ້ໃຊ້: ເພີ່ມການດຸ່ນດ່ຽງການໂຫຼດ

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

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

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

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

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

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

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

10 ຜູ້ໃຊ້: CDN

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

ໃນຂັ້ນຕອນນີ້, ທ່ານຈໍາເປັນຕ້ອງໃຊ້ບໍລິການຟັງສໍາລັບການເກັບຮັກສາເນື້ອຫາຄົງທີ່ - ຮູບພາບ, ວິດີໂອແລະອື່ນໆອີກ (AWS S3 ຫຼື Digital Ocean Spaces). ໂດຍທົ່ວໄປແລ້ວ, API ຂອງພວກເຮົາຄວນຫຼີກລ່ຽງການຈັດການສິ່ງຕ່າງໆເຊັ່ນການຮັບໃຊ້ຮູບພາບແລະການອັບໂຫລດຮູບພາບໃສ່ເຄື່ອງແມ່ຂ່າຍ.

ປະໂຫຍດອີກອັນຫນຶ່ງຂອງ cloud hosting ແມ່ນ CDN (AWS ເອີ້ນວ່າ add-on Cloudfront ນີ້, ແຕ່ຜູ້ໃຫ້ບໍລິການເກັບຮັກສາຟັງຫຼາຍສະເຫນີໃຫ້ມັນອອກຈາກກ່ອງ). CDN ອັດ​ຕະ​ໂນ​ມັດ​ເກັບ​ຮູບ​ພາບ​ຂອງ​ພວກ​ເຮົາ​ໃນ​ສູນ​ຂໍ້​ມູນ​ຕ່າງໆ​ໃນ​ທົ່ວ​ໂລກ​.

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

100 ຜູ້ໃຊ້: ຂະຫຍາຍຊັ້ນຂໍ້ມູນ

CDN ໄດ້ຊ່ວຍຫຼາຍ: ການຈະລາຈອນກໍາລັງເຕີບໂຕເຕັມໄວ. blogger ວິດີໂອທີ່ມີຊື່ສຽງ Mavid Mobrick ພຽງແຕ່ລົງທະບຽນກັບພວກເຮົາແລະປະກາດ "ເລື່ອງລາວ", ຍ້ອນວ່າພວກເຂົາເວົ້າ. ຂໍຂອບໃຈກັບຕົວດຸ່ນດ່ຽງການໂຫຼດ, ການໃຊ້ CPU ແລະຫນ່ວຍຄວາມຈໍາໃນເຊີບເວີ API ແມ່ນຖືກຮັກສາໄວ້ຕ່ໍາ (ສິບ API ແລ່ນ), ແຕ່ພວກເຮົາກໍາລັງເລີ່ມໃຊ້ເວລາຫຼາຍຕາມຄໍາຮ້ອງຂໍ ... ຄວາມຊັກຊ້າເຫຼົ່ານີ້ມາຈາກໃສ?

ການຂຸດຂຸມເລັກນ້ອຍເຂົ້າໄປໃນ metrics, ພວກເຮົາເຫັນວ່າ CPU ໃນເຄື່ອງແມ່ຂ່າຍຂອງຖານຂໍ້ມູນແມ່ນການໂຫຼດ 80-90%. ພວກເຮົາຢູ່ໃນຂອບເຂດຈໍາກັດ.

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

ການເກັບຂໍ້ມູນ

ຫນຶ່ງໃນວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະເພີ່ມປະສິດທິພາບຂອງຖານຂໍ້ມູນຂອງພວກເຮົາແມ່ນເພື່ອແນະນໍາອົງປະກອບໃຫມ່: cache layer. ວິທີການຈັດເກັບຂໍ້ມູນທົ່ວໄປທີ່ສຸດແມ່ນເກັບຮັກສາບັນທຶກຂໍ້ມູນທີ່ມີຄ່າໃນໜ່ວຍຄວາມຈຳ, ເຊັ່ນ Redis ຫຼື Memcached. cloud ສ່ວນໃຫຍ່ມີເວີຊັນທີ່ຄຸ້ມຄອງຂອງບໍລິການເຫຼົ່ານີ້: Elasticache ໃນ AWS ແລະ Memorystore ໃນ Google Cloud.

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

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

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

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

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

ອ່ານ Replicas

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

ນີ້ແມ່ນລະບົບຂອງພວກເຮົາດຽວນີ້:

ການກະ ທຳ ຕໍ່ໄປ

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

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

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

ແຫຼ່ງຂໍ້ມູນ

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

ໝາຍ ເຫດ

1. ເຖິງແມ່ນວ່າຄ້າຍຄືກັນໃນແງ່ຂອງການແຈກຢາຍການໂຫຼດໃນທົ່ວຫຼາຍໆຕົວຢ່າງ, ການປະຕິບັດພື້ນຖານຂອງກຸ່ມ Redis ແມ່ນແຕກຕ່າງກັນຫຼາຍຈາກຕົວດຸ່ນດ່ຽງການໂຫຼດ. [ກັບຄືນ]

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