ການຊອກຫາ proxy pool ແບບບລັອກອາດເຮັດໃຫ້ Scrapy ຢຸດ
ເອົາການເອີ້ນ API proxy pool ແບບ synchronous ອອກຈາກເສັ້ນທາງ event-loop ຂອງ Scrapy ແລະ ໃຫ້ການຄົ້ນຫາ endpoint ມີນະໂຍບາຍຄວາມລົ້ມເຫຼວຂອງຕົນເອງ.
ຕົວຄລາວເວີມີຄຳຮ້ອງພ້ອມກັນພຽງພໍແລ້ວ. ແຕ່ມັນຍັງຢຸດທຸກຄັ້ງທີ່ມັນຂໍທີ່ຢູ່ອື່ນຈາກ proxy pool. ການເພີ່ມ proxy ຫຼາຍຂຶ້ນບໍ່ໄດ້ປ່ຽນການຢຸດນັ້ນ.
ຮູບແບບ middleware ທົ່ວໄປເອີ້ນ requests.get(pool_url) ຢູ່ໃນ process_request(). ນີ້ແມ່ນການດຳເນີນການເຄືອຂ່າຍແບບ synchronous ຢູ່ເສັ້ນທາງທີ່ຄາດວ່າຈະຮ່ວມມືກັບເຄື່ອງຈັກ asynchronous ຂອງ Scrapy. ໃນຂະນະທີ່ການເອີ້ນລໍຖ້າ, ມັນອາດກັກວຽກທີ່ບໍ່ກ່ຽວຂ້ອງໄວ້ໃນ thread ຂອງ event-loop ດຽວກັນ.
ມີສອງຄຳຮ້ອງໃນວຽກ
ຄຳຮ້ອງໜຶ່ງໄດ້ endpoint ຈາກບໍລິການ pool. ອີກອັນໜຶ່ງໃຊ້ endpoint ນັ້ນເພື່ອຕິດຕໍ່ປາຍທາງ. ວັດແລະລາຍງານພວກມັນແຍກກັນ. API pool ທີ່ຊ້າອາດເຮັດໃຫ້ proxy ທີ່ເລືອກທຸກອັນເບິ່ງຊ້າ ກ່ອນທີ່ແອັບຯຈະເຊື່ອມຕໍ່ກັບມັນເລີຍ.
ໃຊ້ການຮວມການຄົ້ນຫາແບບ asynchronous ທີ່ເວີຊັນ Scrapy ທີ່ຕິດຕັ້ງຮອງຮັບ, ຫຼື ໄດ້ມາແລະ ອັບເດດຊຸດ endpoint ທ້ອງຖິ່ນທີ່ຈຳກັດ ຢູ່ນອກເສັ້ນທາງສຳຄັນຂອງແຕ່ລະຄຳຮ້ອງ. ຖ້າຕ້ອງຍ້າຍວຽກທີ່ກັກອອກ, ໃຫ້ຕົວປະຕິບັດນັ້ນມີຂີດຈຳກັດແລະ ການຈັດການເວລາໝົດຂອງຕົນເອງ; ຄິວທີ່ບໍ່ຈຳກັດພຽງແຕ່ຍ້າຍຄວາມຊ້າ.
ຢ່າສົ່ງການເອີ້ນຄົ້ນຫາອີກອັນໜຶ່ງໂດຍອັດຕະໂນມັດສຳລັບທຸກຄຳຮ້ອງ. ແຄຊອາຍຸສັ້ນ ຫຼື ຊຸດທີ່ເຊົ່າສາມາດຫຼຸດການເພິ່ງພາບໍລິການ pool ໄດ້ ຖ້າອາຍຸຂອງມັນເໝາະກັບນະໂຍບາຍ endpoint ຕົວຈິງຂອງບໍລິການ.
ກຳນົດຄວາມໝາຍຂອງການຊອກຫາທີ່ລົ້ມເຫຼວ
ການຕອບກັບຫວ່າງເປົ່າ ຫຼື ລົ້ມເຫຼວຈາກ pool ບໍ່ຄວນລຶບ metadata ຂອງ proxy ຢ່າງງຽບໆ ແລະ ອະນຸຍາດຄຳຮ້ອງໂດຍກົງ. ເລືອກຜົນທີ່ຊັດເຈນ: ລໍຖ້າພາຍໃນງົບປະມານວຽກ, ລົ້ມເຫຼວ, ຫຼື ໃຊ້ endpoint ທີ່ເກັບໄວ້ໃນແຄຊທີ່ໄດ້ຮັບອະນຸມັດ.
ຮັກສາເສັ້ນທາງຂອງ API pool ເອງໃຫ້ວ່າງດ້ວຍ. ຖ້າມັນເປັນບໍລິການພາຍໃນ, ການສົ່ງ hostname ສ່ວນຕົວຂອງມັນຜ່ານ proxy ທີ່ຊ່ວຍເລືອກມັນອາດສ້າງການເພິ່ງພາເປັນວົງກົມ.
ເມື່ອການຄົ້ນຫາເຮັດວຽກໂດຍບໍ່ກັກວຽກທີ່ບໍ່ກ່ຽວຂ້ອງ, ກວດເບິ່ງທຸລະກຳ proxy ປົກກະຕິ. ເຫຼົ່ານັ້ນເປັນການສ້ອມແປງແຍກຕ່າງຫາກ, ແລະ ເວລາຂອງພວກມັນສົມຄວນໄດ້ຮັບຊ່ອງແຍກໃນ log.