ການ​ນໍາ​ໃຊ້ mcouter ເພື່ອ​ຂະ​ຫຍາຍ memcached ຢຽດ​ຕາມ​ລວງ​ນອນ​

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

hero ຂອງໂອກາດແມ່ນຄໍາຮ້ອງສະຫມັກ PHP ໂດຍອີງໃສ່ກອບ symfony 2.3, ເຊິ່ງບໍ່ໄດ້ລວມຢູ່ໃນແຜນການທຸລະກິດທີ່ຈະປັບປຸງ. ນອກ ເໜືອ ໄປຈາກບ່ອນເກັບຂໍ້ມູນມາດຕະຖານທີ່ຂ້ອນຂ້າງ, ໂຄງການນີ້ໄດ້ ນຳ ໃຊ້ຢ່າງເຕັມທີ່ ນະໂຍບາຍ "ເກັບທຸກສິ່ງທຸກຢ່າງ". ໃນ memcached: ການຕອບສະຫນອງຕໍ່ການຮ້ອງຂໍກັບຖານຂໍ້ມູນແລະເຄື່ອງແມ່ຂ່າຍ API, ທຸງຕ່າງໆ, locks ສໍາລັບການ synchronizing ການປະຕິບັດລະຫັດແລະອື່ນໆ. ໃນສະຖານະການດັ່ງກ່າວ, ການແຕກແຍກຂອງ memcached ກາຍເປັນອັນຕະລາຍຕໍ່ການດໍາເນີນງານຂອງແອັບພລິເຄຊັນ. ນອກຈາກນັ້ນ, ການສູນເສຍ cache ນໍາໄປສູ່ຜົນສະທ້ອນທີ່ຮ້າຍແຮງ: DBMS ເລີ່ມລະເບີດຢູ່ seams, ບໍລິການ API ເລີ່ມຫ້າມການຮ້ອງຂໍ, ແລະອື່ນໆ. ສະຖຽນລະພາບສະຖານະການອາດຈະໃຊ້ເວລາຫຼາຍສິບນາທີ, ແລະໃນລະຫວ່າງເວລານີ້ການບໍລິການຈະຊ້າຫຼາຍຫຼືບໍ່ມີໃຫ້ຫມົດ.

ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ສະຫນອງ ຄວາມ​ສາ​ມາດ​ໃນ​ການ​ຂະ​ຫຍາຍ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຕາມ​ລວງ​ນອນ​ທີ່​ມີ​ຄວາມ​ພະ​ຍາ​ຍາມ​ພຽງ​ເລັກ​ນ້ອຍ​, i.e. ມີການປ່ຽນແປງຫນ້ອຍທີ່ສຸດກັບລະຫັດແຫຼ່ງແລະຫນ້າທີ່ເຕັມທີ່ເກັບຮັກສາໄວ້. ເຮັດໃຫ້ cache ບໍ່ພຽງແຕ່ທົນທານຕໍ່ກັບຄວາມລົ້ມເຫລວ, ແຕ່ຍັງພະຍາຍາມຫຼຸດຜ່ອນການສູນເສຍຂໍ້ມູນຈາກມັນ.

ມີຫຍັງຜິດພາດກັບ memcached ຕົວຂອງມັນເອງ?

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

ສິ່ງທີ່ດີກວ່າເລັກນ້ອຍກັບການເກັບຮັກສາເຊດຊັນ: ທ່ານສາມາດຕັ້ງຄ່າໄດ້ memcached.sess_number_of_replicas, ເປັນຜົນມາຈາກການທີ່ຂໍ້ມູນຈະຖືກເກັບໄວ້ໃນເຄື່ອງແມ່ຂ່າຍຫຼາຍຄັ້ງ, ແລະໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວຂອງຫນຶ່ງ memcached instance, ຂໍ້ມູນຈະຖືກໂອນຈາກຄົນອື່ນ. ຢ່າງໃດກໍຕາມ, ຖ້າເຄື່ອງແມ່ຂ່າຍກັບມາອອນໄລນ໌ໂດຍບໍ່ມີຂໍ້ມູນ (ຕາມປົກກະຕິຈະເກີດຂຶ້ນຫຼັງຈາກການເລີ່ມຕົ້ນໃຫມ່), ບາງກະແຈຈະຖືກແຈກຢາຍຄືນໃຫມ່. ໃນຄວາມເປັນຈິງ, ນີ້ຈະຫມາຍຄວາມວ່າ ການສູນເສຍຂໍ້ມູນເຊດຊັນ, ເນື່ອງຈາກວ່າບໍ່ມີທາງທີ່ຈະ "ໄປ" ກັບ replica ອື່ນໃນກໍລະນີຂອງການພາດ.

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

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

mcouter

ນີ້ແມ່ນ router memcached ທີ່ພັດທະນາໂດຍ Facebook ເພື່ອແກ້ໄຂບັນຫາຂອງມັນ. ມັນສະຫນັບສະຫນູນອະນຸສັນຍາຂໍ້ຄວາມ memcached, ເຊິ່ງອະນຸຍາດໃຫ້ ການ​ຕິດ​ຕັ້ງ memcached ຂະ​ຫນາດ​ ກັບອັດຕາສ່ວນບ້າ. ລາຍລະອຽດຂອງ mcouter ສາມາດພົບໄດ້ໃນ ປະກາດນີ້. ໃນ​ບັນ​ດາ​ສິ່ງ​ອື່ນໆ ຟັງຊັນກວ້າງ ມັນສາມາດເຮັດສິ່ງທີ່ພວກເຮົາຕ້ອງການ:

• replicate ບັນທຶກ;
• ກັບຄືນໄປຫາເຄື່ອງແມ່ຂ່າຍອື່ນໃນກຸ່ມຖ້າມີຂໍ້ຜິດພາດເກີດຂື້ນ.

ໄປ​ເຮັດ​ວຽກ!

ການຕັ້ງຄ່າ mcouter

ຂ້ອຍຈະໄປກົງກັບການຕັ້ງຄ່າ:

{
 "pools": {
   "pool00": {
     "servers": [
       "mc-0.mc:11211",
       "mc-1.mc:11211",
       "mc-2.mc:11211"
   },
   "pool01": {
     "servers": [
       "mc-1.mc:11211",
       "mc-2.mc:11211",
       "mc-0.mc:11211"
   },
   "pool02": {
     "servers": [
       "mc-2.mc:11211",
       "mc-0.mc:11211",
       "mc-1.mc:11211"
 },
 "route": {
   "type": "OperationSelectorRoute",
   "default_policy": "AllMajorityRoute|Pool|pool00",
   "operation_policies": {
     "get": {
       "type": "RandomRoute",
       "children": [
         "MissFailoverRoute|Pool|pool02",
         "MissFailoverRoute|Pool|pool00",
         "MissFailoverRoute|Pool|pool01"
       ]
     }
   }
 }
}

ເປັນຫຍັງສາມສະນຸກເກີ? ເປັນຫຍັງເຄື່ອງແມ່ຂ່າຍຈຶ່ງຊ້ໍາກັນ? ໃຫ້ຄິດອອກວ່າມັນເຮັດວຽກແນວໃດ.

• ໃນການຕັ້ງຄ່ານີ້, mcouter ເລືອກເສັ້ນທາງທີ່ຈະສົ່ງຄໍາຮ້ອງຂໍໂດຍອີງໃສ່ຄໍາສັ່ງການຮ້ອງຂໍ. ຜູ້ຊາຍບອກລາວນີ້ OperationSelectorRoute.
• ເອົາຄໍາຮ້ອງຂໍໄປຫາຕົວຈັດການ RandomRouteເຊິ່ງເລືອກສະນຸກເກີຫຼືເສັ້ນທາງລະຫວ່າງວັດຖຸ array ແບບສຸ່ມ children. ແຕ່ລະອົງປະກອບຂອງອາເຣນີ້ແມ່ນຕົວຈັດການ MissFailoverRoute, ເຊິ່ງຈະຜ່ານແຕ່ລະເຄື່ອງແມ່ຂ່າຍໃນສະນຸກເກີຈົນກ່ວາມັນໄດ້ຮັບການຕອບສະຫນອງກັບຂໍ້ມູນ, ເຊິ່ງຈະຖືກສົ່ງກັບລູກຄ້າ.
• ຖ້າພວກເຮົາໃຊ້ສະເພາະ MissFailoverRoute ດ້ວຍສະນຸກເກີຂອງສາມເຊີຟເວີ, ຫຼັງຈາກນັ້ນການຮ້ອງຂໍທັງຫມົດຈະມາທໍາອິດກັບຕົວຢ່າງ memcached ທໍາອິດ, ແລະສ່ວນທີ່ເຫຼືອຈະໄດ້ຮັບການຮ້ອງຂໍບົນພື້ນຖານທີ່ຍັງເຫຼືອໃນເວລາທີ່ບໍ່ມີຂໍ້ມູນ. ວິທີການດັ່ງກ່າວຈະນໍາໄປສູ່ ການໂຫຼດຫຼາຍເກີນໄປໃນເຄື່ອງແມ່ຂ່າຍທໍາອິດໃນບັນຊີລາຍຊື່, ສະນັ້ນມັນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະສ້າງສາມສະນຸກເກີທີ່ມີທີ່ຢູ່ໃນລໍາດັບທີ່ແຕກຕ່າງກັນແລະເລືອກເອົາພວກມັນແບບສຸ່ມ.
• ການຮ້ອງຂໍອື່ນໆທັງຫມົດ (ແລະນີ້ແມ່ນບັນທຶກ) ແມ່ນດໍາເນີນການໂດຍໃຊ້ AllMajorityRoute. ຕົວຈັດການນີ້ສົ່ງຄໍາຮ້ອງຂໍໄປຫາເຄື່ອງແມ່ຂ່າຍທັງຫມົດໃນສະນຸກເກີແລະລໍຖ້າຄໍາຕອບຈາກຢ່າງຫນ້ອຍ N/2 + 1 ຂອງພວກເຂົາ. ຈາກ​ການ​ນໍາ​ໃຊ້​ AllSyncRoute ສໍາ​ລັບ​ການ​ດໍາ​ເນີນ​ງານ​ການ​ຂຽນ​ໄດ້​ຖືກ​ປະ​ຖິ້ມ​ໄວ້​, ນັບ​ຕັ້ງ​ແຕ່​ວິ​ທີ​ການ​ນີ້​ຮຽກ​ຮ້ອງ​ໃຫ້​ມີ​ການ​ຕອບ​ສະ​ຫນອງ​ໃນ​ທາງ​ບວກ​ຈາກ​ всех ເຄື່ອງແມ່ຂ່າຍໃນກຸ່ມ - ຖ້າບໍ່ດັ່ງນັ້ນມັນຈະກັບຄືນມາ SERVER_ERROR. ເຖິງແມ່ນວ່າ mcouter ຈະເພີ່ມຂໍ້ມູນໃສ່ຖານຄວາມຈໍາທີ່ມີຢູ່, ຫນ້າທີ່ເອີ້ນ PHP ຈະສົ່ງຄືນຂໍ້ຜິດພາດ ແລະຈະສ້າງແຈ້ງການ. AllMajorityRoute ແມ່ນບໍ່ເຂັ້ມງວດແລະອະນຸຍາດໃຫ້ເຖິງເຄິ່ງຫນຶ່ງຂອງຫນ່ວຍງານທີ່ຈະເອົາອອກຈາກການບໍລິການໂດຍບໍ່ມີບັນຫາທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ.

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

NB: ທ່ານອາດຈະຊອກຫາການເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດສໍາລັບການຮຽນຮູ້ mcouter ເອກະສານກ່ຽວກັບ wiki и ບັນຫາໂຄງການ (ລວມທັງປິດ), ເປັນຕົວແທນຂອງ storehouse ທັງຫມົດຂອງການຕັ້ງຄ່າຕ່າງໆ.

ການກໍ່ສ້າງແລະແລ່ນ mcouter

ແອັບພລິເຄຊັນຂອງພວກເຮົາ (ແລະ memcached ຕົວຂອງມັນເອງ) ແລ່ນຢູ່ໃນ Kubernetes - ຕາມຄວາມເຫມາະສົມ, mcrouter ກໍ່ຕັ້ງຢູ່ທີ່ນັ້ນ. ສໍາລັບ ການປະກອບພາຊະນະ ພວກເຮົາໃຊ້ werf, config ທີ່​ຈະ​ເບິ່ງ​ຄື​ນີ້​:

NB: ລາຍຊື່ທີ່ໃຫ້ຢູ່ໃນບົດຄວາມໄດ້ຖືກຈັດພີມມາຢູ່ໃນ repository Flant/mcouter.

configVersion: 1
project: mcrouter
deploy:
 namespace: '[[ env ]]'
 helmRelease: '[[ project ]]-[[ env ]]'
---
image: mcrouter
from: ubuntu:16.04
mount:
- from: tmp_dir
 to: /var/lib/apt/lists
- from: build_dir
 to: /var/cache/apt
ansible:
 beforeInstall:
 - name: Install prerequisites
   apt:
     name: [ 'apt-transport-https', 'tzdata', 'locales' ]
     update_cache: yes
 - name: Add mcrouter APT key
   apt_key:
     url: https://facebook.github.io/mcrouter/debrepo/xenial/PUBLIC.KEY
 - name: Add mcrouter Repo
   apt_repository:
     repo: deb https://facebook.github.io/mcrouter/debrepo/xenial xenial contrib
     filename: mcrouter
     update_cache: yes
 - name: Set timezone
   timezone:
     name: "Europe/Moscow"
 - name: Ensure a locale exists
   locale_gen:
     name: en_US.UTF-8
     state: present
 install:
 - name: Install mcrouter
   apt:
     name: [ 'mcrouter' ]

(werf.yaml)

... ແລະແຕ້ມມັນອອກ ຕາຕະລາງຫມວກກັນກະທົບ. ສິ່ງທີ່ຫນ້າສົນໃຈແມ່ນວ່າມີພຽງແຕ່ config generator ໂດຍອີງໃສ່ຈໍານວນຂອງ replicas (ຖ້າໃຜມີທາງເລືອກ laconic ແລະ elegant ຫຼາຍ, ແບ່ງປັນມັນໃນຄໍາເຫັນ):

{{- $count := (pluck .Values.global.env .Values.memcached.replicas | first | default .Values.memcached.replicas._default | int) -}}
{{- $pools := dict -}}
{{- $servers := list -}}
{{- /* Заполняем  массив двумя копиями серверов: "0 1 2 0 1 2" */ -}}
{{- range until 2 -}}
 {{- range $i, $_ := until $count -}}
   {{- $servers = append $servers (printf "mc-%d.mc:11211" $i) -}}
 {{- end -}}
{{- end -}}
{{- /* Смещаясь по массиву, получаем N срезов: "[0 1 2] [1 2 0] [2 0 1]" */ -}}
{{- range $i, $_ := until $count -}}
 {{- $pool := dict "servers" (slice $servers $i (add $i $count)) -}}
 {{- $_ := set $pools (printf "MissFailoverRoute|Pool|pool%02d" $i) $pool -}}
{{- end -}}
---
apiVersion: v1
kind: ConfigMap
metadata:
 name: mcrouter
data:
 config.json: |
   {
     "pools": {{- $pools | toJson | replace "MissFailoverRoute|Pool|" "" -}},
     "route": {
       "type": "OperationSelectorRoute",
       "default_policy": "AllMajorityRoute|Pool|pool00",
       "operation_policies": {
         "get": {
           "type": "RandomRoute",
           "children": {{- keys $pools | toJson }}
         }
       }
     }
   }

(10-mcrouter.yaml)

ພວກເຮົາມ້ວນມັນອອກໄປໃນສະພາບແວດລ້ອມການທົດສອບແລະກວດເບິ່ງ:

# php -a
Interactive mode enabled

php > # Проверяем запись и чтение
php > $m = new Memcached();
php > $m->addServer('mcrouter', 11211);
php > var_dump($m->set('test', 'value'));
bool(true)
php > var_dump($m->get('test'));
string(5) "value"
php > # Работает! Тестируем работу сессий:
php > ini_set('session.save_handler', 'memcached');
php > ini_set('session.save_path', 'mcrouter:11211');
php > var_dump(session_start());
PHP Warning:  Uncaught Error: Failed to create session ID: memcached (path: mcrouter:11211) in php shell code:1
Stack trace:
#0 php shell code(1): session_start()
#1 {main}
  thrown in php shell code on line 1
php > # Не заводится… Попробуем задать session_id:
php > session_id("zzz");
php > var_dump(session_start());
PHP Warning:  session_start(): Cannot send session cookie - headers already sent by (output started at php shell code:1) in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Unable to clear session lock record in php shell code on line 1
PHP Warning:  session_start(): Failed to read session data: memcached (path: mcrouter:11211) in php shell code on line 1
bool(false)
php >

ການຊອກຫາຂໍ້ຄວາມຂອງຄວາມຜິດພາດບໍ່ໄດ້ໃຫ້ຜົນໄດ້ຮັບໃດໆ, ແຕ່ສໍາລັບການສອບຖາມ "mcouter php"ໃນແຖວຫນ້າແມ່ນບັນຫາເກົ່າແກ່ທີ່ສຸດທີ່ບໍ່ໄດ້ຮັບການແກ້ໄຂຂອງໂຄງການ - ຂາດການສະຫນັບສະຫນູນ memcached ອະນຸສັນຍາຄູ່.

NB: ໂປຣໂຕຄໍ ASCII ໃນ memcached ແມ່ນຊ້າກວ່າ binary one, ແລະມາດຕະຖານວິທີການ hashing key ທີ່ສອດຄ່ອງພຽງແຕ່ເຮັດວຽກກັບ binary protocol. ແຕ່ນີ້ບໍ່ໄດ້ສ້າງບັນຫາສໍາລັບກໍລະນີສະເພາະໃດຫນຶ່ງ.

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

ແມ່ນແລ້ວ, ຊື່ທາງເລືອກທີ່ຖືກຕ້ອງແມ່ນ memcached.sess_binary_protocol. ມັນຕ້ອງຖືກປິດໃຊ້ງານ, ຫຼັງຈາກນັ້ນກອງປະຊຸມຈະເລີ່ມເຮັດວຽກ. ສິ່ງທີ່ຍັງເຫຼືອແມ່ນເອົາຖັງໃສ່ກັບ mcouter ເຂົ້າໄປໃນຝັກດ້ວຍ PHP!

ສະຫລຸບ

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

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• "ປະຕິບັດກັບ dapp" (ໃຊ້ symfony-demo ເປັນຕົວຢ່າງ): ພາກ​ທີ 1 (ການ​ກໍ່​ສ້າງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ງ່າຍ​ດາຍ​) и ພາກ​ທີ 2 (ການ​ນໍາ​ໃຊ້​ຮູບ​ພາບ Docker ກັບ Kubernetes ການ​ນໍາ​ໃຊ້ Helm​);
• «ຈາກຊີວິດກັບ Kubernetes: ວິທີທີ່ເຄື່ອງແມ່ຂ່າຍ HTTP ບໍ່ມັກຊາວສະເປນ".

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