Một lượt đồng bộ bị giới hạn tốc độ không cần được gửi lại ngay. Điều cần quyết định là công việc còn bao nhiêu thời gian, được thử lại đến đâu và ai nhận phần chưa hoàn thành.
Phân biệt giới hạn tốc độ với lỗi nghiệp vụ
429 thường báo quá nhiều yêu cầu, nhưng cần đọc tài liệu của nhà cung cấp trước khi áp dụng một lịch chung. Lỗi quyền truy cập, dữ liệu sai hoặc tài khoản bị khóa không được chữa bằng cách tăng số lượt retry. Giữ mã phản hồi, request ID và thời điểm nhận; không lưu token vào sổ xử lý.
Bảng ngân sách retry cho từng công việc
Tạo phiếu gồm mã công việc, hạn hoàn thành, số lượt đã thử, thời điểm được thử tiếp, tổng thời gian chờ và người nhận cảnh báo. Nếu provider gửi Retry-After, đừng thử sớm hơn tín hiệu đó. Nếu thời gian chờ vượt hạn nghiệp vụ, chuyển trạng thái chờ xử lý thay vì cố hoàn thành bằng cách gửi dồn.
Ví dụ giả định: đồng bộ tồn kho trước giờ mở cửa
Một cửa hàng giả định cần bản cập nhật trước giờ mở cửa. Khi API bị giới hạn, nhóm vận hành đánh dấu dữ liệu chưa được xác nhận mới nhất và giữ lần cập nhật thành công gần nhất. Không hiển thị “đã đồng bộ” chỉ vì lịch retry đã được tạo. Các mặt hàng chưa xử lý được ghi riêng để tránh chạy lại toàn bộ danh mục.
| Tín hiệu | Điều phải ghi | Kết quả cần thấy |
|---|---|---|
| 429 có Retry-After | Mốc sớm nhất được thử | Không gửi sớm |
| Hạn công việc đã hết | Phần chưa hoàn thành | Chờ người xử lý |
| Lỗi quyền hoặc dữ liệu | Mã lỗi và owner | Không retry mù |
Giảm tốc ở đúng phạm vi
Nếu nhiều worker cùng dùng một hạn mức, mỗi worker tự chờ vẫn có thể tạo đợt gửi dồn. Cần điều phối theo phạm vi hạn mức đã xác minh: tài khoản, ứng dụng hoặc endpoint. Có thể giãn thời điểm thử lại, nhưng phải giữ hạn chót và khả năng hủy. Không tự tăng concurrency khi hàng chờ lớn.
Nghiệm thu trước khi mở chạy định kỳ
Mô phỏng phản hồi giới hạn, tín hiệu chờ dài hơn deadline và việc nhiều tác vụ thức dậy cùng lúc. Người duyệt cần thấy công việc thành công một lần, công việc hết ngân sách có trạng thái rõ và phần tồn có người nhận. Đây là tiêu chí đề xuất cho dự án, không phải cam kết mọi API xử lý giống nhau.
Quyết định triển khai
Nút thắt thường là thiếu chính sách chờ và bàn giao, không phải thiếu thêm một vòng lặp. Chỉ mở tự động chạy lại khi đội vận hành biết cách xem hàng chờ, dừng tác vụ và tiếp nhận ngoại lệ. Thống nhất ngân sách với người chịu trách nhiệm nghiệp vụ trước khi điều chỉnh thông số kỹ thuật.
Chuẩn bị gì khi trao đổi phạm vi triển khai?
Nếu hàng chờ đang tăng vì API giới hạn tốc độ, hãy chuẩn bị một lượt lỗi đã che thông tin nhạy cảm cùng hạn hoàn thành nghiệp vụ. Khi trao đổi điều chỉnh luồng kết nối phần mềm, bảng ngân sách retry giúp chốt điểm dừng trước khi sửa mã.
Dùng prompt thiết kế retry/backoff khi đã chốt chính sách chờ; công cụ soạn yêu cầu không thay thế việc xác nhận hành vi trên hệ thống thực tế.
Nguồn kiểm chứng và giới hạn áp dụng
Tài liệu chính thức: GitHub hướng dẫn tôn trọng Retry-After và giới hạn lượt thử lại. Đối chiếu ngày 12/10/2026. Các bảng và quy trình trong bài là đề xuất biên tập; ví dụ giả định không phải dự án hay kết quả khách hàng Onter.
