Một pool proxy có thể biến sự cố đơn giản thành vòng lặp bận rộn. Chọn một địa chỉ, thất bại, chọn địa chỉ khác, lại thất bại. Nếu mọi endpoint đều không truy cập được vì chính mạng của bạn đang hỏng, thì đổi địa chỉ không bao giờ khắc phục nguyên nhân.

Hãy cấp cho thao tác một ngân sách trước khi chọn proxy đầu tiên từ pool hoặc danh sách proxy miễn phí: số lần thử hữu hạn, thời gian chờ kết nối và đọc có giới hạn, và một hạn chót cho toàn bộ tác vụ. Timeout của Requests kiểm soát hành vi kết nối hoặc đọc được tài liệu hóa; bản thân nó không giới hạn một vòng lặp liên tục phát sinh yêu cầu mới.

Quyết định điều gì xứng đáng được thử thêm

  • Một kết nối proxy bị từ chối có thể biện minh cho việc thử endpoint khác.
  • Phản hồi từ đích cần cách diễn giải riêng. Nhận được lỗi HTTP chứng minh rằng một đường đi yêu cầu nào đó đã hoàn tất.
  • Lỗi xác thực proxy đòi hỏi kiểm tra endpoint và tài khoản thay vì liên tục đập cùng thông tin đăng nhập qua danh sách ngày càng dài.

Giữ ngoại lệ hoặc trạng thái gốc cùng bản ghi lần thử. Một thông báo cuối chỉ có “mọi proxy đều thất bại” che giấu việc các lỗi có cùng nguyên nhân hay không.

Kiểm tra sức khỏe từng proxy trước mỗi yêu cầu thật sẽ thêm một yêu cầu nữa và vẫn không thể bảo đảm lần sau thành công. Hãy tái sử dụng thông tin sức khỏe gần đây khi phù hợp với tác vụ, rồi để thao tác thật tự báo cáo kết quả của nó.

Thử lại có thể lặp lại công việc

Với thao tác chỉ đọc, chuyển sang proxy khác thường đơn giản hơn phát lại một lần gửi. Nếu kết nối rớt sau khi gửi giao dịch mua hoặc biểu mẫu, đích có thể đã xử lý nó. Hãy tuân theo cơ chế idempotency của dịch vụ và quy tắc thử lại HTTP trước khi phát lại công việc.

Khi ngân sách cạn, hãy trả về một lỗi hữu ích. Một tác vụ dừng lại với bằng chứng dễ sửa hơn tác vụ âm thầm xoay mãi cho đến khi có người nhận ra.

Bài viết liên quan