Rate Limit, Retry và Exponential Backoff khi dùng Proxy là ba khái niệm cốt lõi khi xây ứng dụng ổn định. Retry đúng giúp phục hồi lỗi tạm thời; retry sai có thể nhân tải, làm cạn băng thông và khiến hệ thống đích chặn lâu hơn.
Mục lục
- Không phải lỗi nào cũng nên retry
- Exponential backoff hoạt động thế nào?
- Tôn trọng Retry-After
- Idempotency quyết định an toàn
- Retry budget
- Chống retry storm
- Quan sát để điều chỉnh
Không phải lỗi nào cũng nên retry
- Timeout kết nối tạm thời có thể retry giới hạn.
- 502, 503 hoặc 504 có thể retry nếu thao tác an toàn.
- 400, 401, 403 thường cần sửa request hoặc quyền.
- 407 cần sửa xác thực Proxy, không retry liên tục.
- 429 phải tôn trọng Retry-After và giảm tốc độ.
Exponential backoff hoạt động thế nào?
Khoảng chờ tăng theo số lần thất bại, ví dụ 1 giây, 2 giây, 4 giây, 8 giây và dừng ở mức trần. Cách này cho hệ thống thời gian phục hồi và giảm dồn tải.
Thêm jitter ngẫu nhiên để nhiều worker không thức dậy cùng lúc. Không cần dùng chính xác cùng một công thức cho mọi tác vụ, nhưng phải có giới hạn.
Tôn trọng Retry-After
Khi server trả 429 hoặc 503 kèm Retry-After, client nên chờ theo hướng dẫn nếu giá trị hợp lệ. Không đổi IP chỉ để né rate limit; điều đó có thể vi phạm điều khoản và che giấu vấn đề thiết kế.
Giảm concurrency và request/giây cho host bị giới hạn, không nhất thiết làm chậm toàn hệ thống.
Idempotency quyết định an toàn
GET thường dễ retry hơn, nhưng POST có thể tạo giao dịch trùng nếu server đã xử lý trước khi kết nối đứt. Dùng idempotency key, trạng thái nghiệp vụ hoặc hàng đợi có exactly-once ở mức ứng dụng.
Không coi timeout là bằng chứng thao tác chưa xảy ra.
Retry budget
- Giới hạn số lần thử trên một request.
- Giới hạn tổng retry theo phút hoặc theo host.
- Dừng khi deadline nghiệp vụ đã hết.
- Không retry nếu lỗi xác thực hoặc dữ liệu không hợp lệ.
- Cảnh báo khi tỷ lệ retry vượt ngưỡng nền.
Chống retry storm
- Áp dụng jitter cho worker.
- Dùng circuit breaker khi lỗi tăng nhanh.
- Hạ concurrency theo phản hồi 429 và timeout.
- Cô lập host hoặc Proxy lỗi thay vì toàn hệ thống.
- Phục hồi từng bước bằng request thăm dò.
Quan sát để điều chỉnh
- Số lần retry theo mã lỗi.
- Thời gian chờ tích lũy.
- Tỷ lệ request thành công sau retry.
- Băng thông và chi phí do retry.
- Số thao tác trùng hoặc quá deadline.
Câu hỏi thường gặp
Có nên retry ngay lập tức?
Thường không. Lỗi tạm thời cần khoảng chờ; retry ngay dễ làm tình trạng quá tải nghiêm trọng hơn.
Đổi Proxy có xử lý được 429?
Không nên dùng đổi IP để né giới hạn. Hãy giảm tốc, tôn trọng Retry-After và điều khoản của dịch vụ.
Jitter để làm gì?
Phân tán thời điểm retry giữa nhiều worker, tránh chúng cùng gửi lại một lúc.
Kết luận
Retry có chọn lọc, backoff có jitter, tôn trọng Retry-After và giới hạn bằng retry budget. Kết hợp idempotency và circuit breaker để phục hồi mà không tạo dữ liệu trùng hoặc bão tải.
Bạn cần cấu hình Proxy phù hợp? Hãy xem các gói tại ProxySmart hoặc liên hệ hỗ trợ để được tư vấn theo vị trí IP, giao thức, băng thông và số phiên đồng thời. Chỉ sử dụng proxy cho mục đích hợp pháp, trên hệ thống bạn sở hữu hoặc được phép kiểm thử, đồng thời tuân thủ điều khoản của dịch vụ đích.