یک استخر پروکسی می‌تواند یک قطعی ساده را به حلقۀ مشغول تبدیل کند. آدرسی انتخاب کنید، شکست بخورید، آدرس دیگری انتخاب کنید، باز شکست بخورید. اگر همه نقاط پایانی دسترس‌ناپذیر باشند چون شبکۀ خودتان قطع است، تغییر آدرس هرگز علت را برطرف نمی‌کند.

پیش از انتخاب اولین پروکسی از استخر یا فهرست پروکسی رایگان، به عملیات بودجه بدهید: تعداد محدودی تلاش، انتظارهای محدود اتصال و خواندن، و مهلتی برای کل کار. timeout کتابخانۀ Requests رفتار مستند اتصال یا خواندن را کنترل می‌کند؛ به‌تنهایی حلقه‌ای را که مدام درخواست تازه می‌فرستد محدود نمی‌کند.

تصمیم بگیرید چه چیزی مستحق تلاش دیگر است

  • اتصال پروکسی ردشده می‌تواند امتحان نقطۀ پایانی دیگر را توجیه کند.
  • پاسخ مقصد تفسیر خودش را می‌خواهد. دریافت خطای HTTP ثابت می‌کند که مسیر درخواستی کامل شده است.
  • شکست احراز هویت پروکسی نیازمند بررسی نقطۀ پایانی و حساب است، نه کوبیدن همان اعتبارنامه‌ها از فهرستی که مدام بزرگ‌تر می‌شود.

استثنا یا وضعیت اصلی را همراه سابقۀ تلاش نگه دارید. پیام پایانی‌ای که فقط «همه پروکسی‌ها شکست خوردند» دارد پنهان می‌کند که آیا شکست‌ها حتی علت یکسانی داشتند.

بررسی سلامت هر پروکسی پیش از هر درخواست واقعی یک درخواست دیگر اضافه می‌کند و باز هم تضمین نمی‌کند درخواست بعدی موفق شود. اطلاعات سلامت تازه را جایی که به کار می‌آید دوباره استفاده کنید و بگذارید عملیات واقعی نتیجۀ خودش را گزارش کند.

تلاش دوباره می‌تواند کار را تکرار کند

برای یک واکشی فقط‌خواندنی، رفتن به پروکسی دیگر معمولاً ساده‌تر از دوباره فرستادن یک ارسال است. اگر اتصال پس از فرستادن خرید یا فرم قطع شود، ممکن است مقصد آن را قبلاً پردازش کرده باشد. پیش از تکرار کار، سازوکار idempotency سرویس و قواعد تلاش دوبارۀ HTTP را دنبال کنید.

وقتی بودجه تمام شد، شکستی سودمند برگردانید. کاری که با شواهد متوقف می‌شود آسان‌تر از کاری تعمیر می‌شود که بی‌صدا می‌چرخد تا کسی متوجه شود.

مقالات مرتبط