Lỗi HTTP 429: đọc Retry-After và lập kế hoạch thử lại an toàn

Xác định thành phần nào trả 429

Ghi thời điểm, endpoint, phương thức, trạng thái, request ID và các header liên quan đến thử lại. Không ghi thông tin xác thực hay dữ liệu cá nhân. Phân biệt API đích, reverse proxy và quy tắc CDN; giao diện trang lỗi không đủ xác định chính sách giới hạn.

Giới hạn có thể áp dụng cho IP, người dùng đã xác thực, ứng dụng hoặc tài nguyên. Nội dung phản hồi và bảng điều khiển có thể chỉ rõ quota đã chạm. Tốc độ mỗi phút, số yêu cầu đồng thời và hạn mức ngày cần cách xử lý khác nhau; giảm tốc không khôi phục quota ngày đã hết.

• Khối lượng thật tăng hay một công việc bắt đầu lặp lại liên tục?
• Nhiều dịch vụ, tab hoặc khóa API có cùng dùng hạn mức tài khoản không?
• Giới hạn tính theo số yêu cầu, yêu cầu đang chạy, token hay tài nguyên nào?
• Thời gian khôi phục có phù hợp thời hạn của thao tác này không?

Đọc Retry-After theo đúng đơn vị

Retry-After có thể là số nguyên không âm tính bằng giây hoặc ngày HTTP. Giá trị 12 yêu cầu chờ mười hai giây từ khi nhận, không phải mili giây. Với ngày, dùng đồng hồ đáng tin để tính phần thời gian còn lại. Ngày đã qua không cho phép vòng lặp thử lại dồn dập.

Nếu công việc chờ được, coi độ trễ hợp lệ của máy chủ là tối thiểu và thêm độ phân tán nhỏ khi nhiều worker cùng tiếp tục. Nếu thời gian chờ vượt deadline còn lại, dừng hoặc hẹn lại. Không âm thầm rút ngắn chỉ dẫn của máy chủ theo một ngưỡng cục bộ tùy ý.

Tính ngân sách cho cả hàng đợi

Giả sử tài khoản có 120 yêu cầu mỗi phút và công việc cần 600 yêu cầu. Chỉ xét số lượng đã cần ít nhất năm phút hạn mức nếu không có việc khác. Gửi cả 600 trong mười giây rồi nghỉ vẫn là một đợt dồn; dịch vụ có thể từ chối dù trung bình phút trông hợp lý.

Chọn mục tiêu 90 mỗi phút để chừa phần cho công việc khác:1.5 mỗi giây, khoảng cách danh nghĩa khoảng 667 mili giây.600 yêu cầu cần khoảng 400 giây, chưa gồm thời gian phản hồi và thử lại. Đây là phép tính lập kế hoạch, không bảo đảm khớp cửa sổ giới hạn của mọi nhà cung cấp.

Nếu phản hồi trung bình mất hai giây, định luật Little cho mức đang xử lý trung bình gần 1.5 × 2 = 3 khi tải ổn định. Semaphore giới hạn số đang chạy; bộ giới hạn tốc độ chung giãn thời điểm bắt đầu. Cần cả hai và phải tính cả lần thử lại vào cùng ngân sách.

Example workload assumptions:
Account allowance: 120 requests/minute
Operating target: 90 requests/minute = 1.5 requests/second
600 requests / 1.5 requests/second = 400 seconds
Average concurrency at 2 seconds/response: 1.5 × 2 = 3

Dùng backoff hữu hạn có jitter khi thiếu độ trễ

Khi lỗi lặp lại, mở rộng cửa sổ chờ và chọn thời gian thực ngẫu nhiên trong đó. Ví dụ các cửa sổ một, hai, bốn và tám giây, kèm thời hạn tổng riêng. Jitter ngăn các worker đồng loạt gửi lại ở cùng thời điểm.

Hàm dưới chỉ tính độ trễ, không gửi yêu cầu hay triển khai đầy đủ client. Bên gọi phải áp dụng deadline, số lần tối đa, hủy và tính an toàn của thao tác. Trình duyệt có thể cần máy chủ expose Retry-After qua CORS trước khi JavaScript đọc được.

function retryDelayMs(retryAfter, attempt, nowMs = Date.now()) {
  const text = String(retryAfter ?? "").trim();
  if (/^\d+$/.test(text)) {
    const milliseconds = Number(text) * 1000;
    return Number.isSafeInteger(milliseconds) ? milliseconds : Infinity;
  }
  if (/^(Mon|Tue|Wed|Thu|Fri|Sat|Sun), \d{2} (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d{4} \d{2}:\d{2}:\d{2} GMT$/.test(text)) {
    const dateMs = Date.parse(text);
    if (Number.isFinite(dateMs)) return Math.max(0, dateMs - nowMs);
  }
  const windowMs = Math.min(8000, 1000 * 2 ** attempt);
  return Math.floor(Math.random() * windowMs);
}
// Example policy: at most 4 retries and a 30-second total deadline.
// If the required wait exceeds the remaining deadline, stop.

Chỉ lặp thao tác khi an toàn

Đọc tài nguyên khác tạo thanh toán. Trước khi thử lại lệnh ghi, kiểm tra hợp đồng idempotency và khả năng lần trước đã có hiệu lực. Khi được hỗ trợ, giữ cùng idempotency key cho cùng thao tác logic; khóa mới mỗi lần có thể tạo nhiều thao tác riêng.

SDK có thể đã tự thử lại. Bọc thêm vòng lặp sẽ nhân lưu lượng. Ghi số lần gọi mạng tối đa qua mọi tầng. Với thao tác người dùng, hiển thị trạng thái thử lại sau rõ ràng thay vì giấu hàng đợi dài phía sau nút quay mãi.

• Đặt một deadline tổng và truyền lệnh hủy tới việc đang chờ.
• Giới hạn cả số đồng thời và tốc độ bắt đầu trong hạn mức chung.
• Giải phóng tài nguyên phản hồi trước khi ngủ hoặc thử lại.
• Dừng khi hết quota hoặc lỗi được mô tả là vĩnh viễn.
• Ghi lần thử và kết quả cuối để việc thử lại hiện trong giám sát.

Xác minh bằng lô nhỏ có kiểm soát

Bắt đầu bằng khối lượng đếm được, chẳng hạn hai mươi lượt đọc. Tách số lần đầu, thử lại, thành công và thất bại cuối. Đối chiếu khoảng cách thực tế cùng số đang chạy với kế hoạch. Mô phỏng 429 với Retry-After đã biết, tránh liên tục ép dịch vụ thật.

Dùng công cụ tốc độ yêu cầu để đổi giữa giây và phút, công cụ đồng thời để kiểm tra giả định độ trễ. So với hạn mức thực tế của nhà cung cấp. Nếu vẫn 429, kiểm tra các bên dùng chung quota và loại quota trước khi chỉ tăng thời gian chờ.