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

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

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

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

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

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

ການຟື້ນຟູຝ່າຍລູກຄ້າກໍສຳຄັນ. ຄຳຮ້ອງບຣາວເຊີໃໝ່ອາດເຊື່ອມຕໍ່ຄືນໄດ້ງ່າຍ; ການອັບໂຫຼດທີ່ມີ ບອດີທີ່ໃຊ້ໄປແລ້ວ ຫຼື ການເຮັດວຽກ API ທີ່ບໍ່ແບບ idempotent ອາດຕ້ອງການການຈັດການສະເພາະແອັບພລິເຄຊັນ. ຢ່າສັນຍາການສະຫຼັບທີ່ເບິ່ງບໍ່ເຫັນ ພຽງເພາະຄຳຮ້ອງໃໝ່ສຳເລັດຜ່ານເຄື່ອງສຳຮອງ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ