HTTP 429 Quá nhiều yêu cầu: Điều đó có nghĩa là gì và cách khắc phục

API Scraping không có rác xử lý HTTP 429 cho các tác vụ đã xác thực khi tần suất yêu cầu vượt quá mức dịch vụ có sẵn.

Định nghĩa và Câu trả lời ngắn gọn

HTTP 429 Quá nhiều yêu cầu có nghĩa là khách hàng đã vượt quá chính sách tỷ lệ yêu cầu được chọn bởi máy chủ. Chính sách này có thể áp dụng cho một người dùng, tài khoản, chứng chỉ, địa chỉ IP, điểm cuối, tổ chức, nhóm tài nguyên, hoặc một hệ thống đơn vị trọng số. Mã này không tiết lộ đầy đủ chính sách một mình, vì vậy nội dung phản hồi, tiêu đề, tài liệu dịch vụ, bảng điều khiển tài khoản và hướng dẫn hỗ trợ hình thành hợp đồng vận hành.

Một mã 429 khác với 403 và 503. Một mã 403 là sự từ chối quyền hoặc chính sách mà thường vẫn tồn tại cho đến khi danh tính, quyền truy cập, hoặc bối cảnh yêu cầu thay đổi. Một mã 503 có nghĩa là dịch vụ không khả dụng hoặc không thể xử lý công việc vào thời điểm đó, bất kể liệu người gọi này có vượt quá hạn định cá nhân hay không. Một mã 429 liên kết cụ thể việc từ chối với khối lượng yêu cầu của người gọi dưới một quy tắc tỷ lệ, mặc dù các cổng và dịch vụ có thể thực hiện quy tắc đó ở các lớp khác nhau.

Cách khắc phục ngay lập tức là kiểm soát tốc độ: ngừng tạo áp lực, đọc chỉ dẫn chờ của dịch vụ và tiếp tục với tốc độ thấp hơn. Nếu nhiều quy trình chia sẻ một chứng chỉ, họ cần một hạn ngạch phối hợp thay vì các bộ đếm cục bộ độc lập. Một khách hàng không nên khởi động một đội đồng bộ ngay khi một ranh giới thời gian vượt qua, vì điều đó có thể tái tạo cùng một cấu trúc bùng nổ.

Cách khắc phục bền vững phụ thuộc vào nguyên nhân. Các vòng lặp tình cờ cần công việc có giới hạn và khả năng quan sát. Các hệ thống lô cần hàng đợi và lập lịch tập trung. Nhu cầu hợp pháp cao có thể cần điều chỉnh hạn ngạch, phân tán khối lượng công việc, bộ nhớ đệm, kích thước trang lớn hơn, webhook, điểm cuối số lượng lớn, hoặc một kế hoạch khác. Các chủ sở hữu máy chủ cần chính sách được tài liệu hóa, thực thi ổn định, nội dung lỗi hữu ích và bảng điều khiển cho thấy phạm vi nào đã bị vượt quá.

Tại sao một dịch vụ trả về 429

1. Một phạm vi chính sách đã được chọn. Cổng hoặc ứng dụng xác định người gọi và điểm cuối, sau đó chọn giới hạn tài khoản, người dùng, chứng chỉ, mạng, tài nguyên, vùng miền hoặc giới hạn trọng số.
2. Sự sử dụng gần đây được đo lường. Một cửa sổ cố định, bộ đếm cuộn, xô token, hoặc một thuật toán khác so sánh chi phí hoạt động gần đây với dung lượng có sẵn. Các thuật toán khác nhau cho phép các hình dạng bùng nổ khác nhau.
3. Yêu cầu bị từ chối trước khi công việc tốn kém diễn ra. Việc thực thi thường xảy ra sớm để lưu lượng bị từ chối không tiêu tốn cơ sở dữ liệu được bảo vệ, nhóm trình duyệt, API hạ lưu hoặc ngân sách tính toán.
4. Hướng dẫn được trả về. Phản hồi có thể nêu rõ một khoảng thời gian chờ, lý do giới hạn, hạn ngạch kế hoạch, hoặc đường dẫn hỗ trợ. Khách hàng nên coi các trường cụ thể của nhà cung cấp như chính thống cho API đó.

HTTP 429 Quá nhiều yêu cầu trong các hệ thống thực

Triệu chứng 429, Nguyên nhân có thể và Hành động khắc phục

Một cái nhìn bên cạnh nhau ngăn chặn các khái niệm gần nhau bị coi như là thay thế cho nhau. Sử dụng so sánh để xác định hợp đồng nào đang hoạt động trước khi thay đổi hành vi của khách hàng hoặc máy chủ.

HTTP 429 Có quá nhiều yêu cầu Chẩn đoán và Thiết kế hoạt động

Ghi lại phản hồi 429 đầy đủ và liên kết nó với thời gian của khách hàng và máy chủ. Ghi lại tài khoản, nhãn thông tin xác thực, điểm cuối, trọng số hoạt động, công nhân, khu vực, và định danh yêu cầu mà không ghi lại bí mật. Sau đó tổng hợp qua toàn bộ phạm vi. Nhìn vào một công nhân riêng lẻ có thể che giấu lưu lượng kết hợp thực sự vượt qua chính sách.

Giảm tần suất trước khi thay đổi độ đồng thời hoặc thêm máy. Nhiều công nhân thường làm trầm trọng thêm hạn chế trên toàn tài khoản. Đặt các nhiệm vụ vào hàng đợi, để một bộ lập lịch chia sẻ phát hành chúng với tốc độ đo lường, và giới hạn công việc đang tiến hành riêng biệt. Lưu trữ phản hồi ổn định, yêu cầu các trang lớn hơn được hỗ trợ, kết hợp các hoạt động khi có một điểm cuối dạng khối, và dừng việc truy vấn khi một sự kiện hoặc webhook có thể chỉ ra hoàn thành.

Nếu khối lượng công việc là hợp pháp và được tối ưu hóa, so sánh nhu cầu đo lường với hạn mức đã công bố và liên hệ với nhà cung cấp về khả năng hoặc thay đổi kế hoạch. Bao gồm các định danh yêu cầu và tổng hợp tỷ lệ, không phải một đống vé trùng lặp. Các nhóm máy chủ nên làm cho cuộc trò chuyện đó dễ dàng hơn bằng cách công khai tên giới hạn, khả năng còn lại nếu phù hợp và cái nhìn tổng quát về sử dụng cấp tài khoản.

Danh sách kiểm tra HTTP 429 Có quá nhiều yêu cầu

Danh sách kiểm tra dưới đây biến khái niệm thành công việc kỹ thuật có thể xác minh. Chỉ áp dụng các mục phù hợp với giao thức và hợp đồng sản phẩm hiện tại, nhưng giữ bằng chứng cùng nhau để một kỹ sư khác có thể tái tạo quyết định.

• Tạm dừng các bài nộp mới và giữ lại phản hồi 429 đầy đủ cộng với định danh yêu cầu.
• Xác định xem chính sách có áp dụng cho IP, khóa, tài khoản, người dùng, điểm cuối, khu vực, hay đơn vị trọng số hay không.
• Tổng hợp lưu lượng từ mọi công nhân và dịch vụ chia sẻ phạm vi đó.
• Tập trung nhịp độ và tách biệt tỷ lệ yêu cầu khỏi độ đồng thời và tổng hạn ngạch.
• Phân tán các khởi đầu đã lập lịch, ràng buộc vòng lặp, lưu bộ kết quả ổn định, và ưu tiên các luồng dạng khối hoặc theo sự kiện.
• Tôn trọng khoảng thời gian chờ đã được dịch vụ nêu rõ trước khi gửi thêm công việc.
• Yêu cầu điều chỉnh khả năng chỉ sau khi đo lường và tối ưu hóa nhu cầu hợp lý.

Sau khi triển khai, kiểm tra hành vi bình thường, ranh giới, đầu vào không hợp lệ, tình trạng thiếu, hoạt động đồng thời, và từ chối truy cập cố ý trong một môi trường được kiểm soát. Ghi lại trạng thái mong đợi, hình dáng nội dung, điều kiện kết thúc, và sự chuyển giao trạng thái cho mỗi trường hợp. Giám sát sản xuất nên báo cáo cùng các kích thước được sử dụng trong thử nghiệm để một sự cố có thể được so sánh với một mức chuẩn đã biết.

Tài liệu nên xác định trách nhiệm ở mỗi bên giao diện. Khách hàng cần các trường bắt buộc, định danh ổn định, quy tắc sắp xếp, giới hạn, tín hiệu kết thúc, và ý nghĩa lỗi. Nhân viên vận hành cần chính sách nội bộ, quyết định lưu trữ hoặc định tuyến, các trường quan sát, và phản hồi công khai an toàn. Các hợp đồng mơ hồ khiến các nhóm sửa chữa triệu chứng nhìn thấy trong lớp sai.

Những sai lầm phổ biến với HTTP 429 Có quá nhiều yêu cầu

Đừng suy ra thành công, sự vắng mặt, quyền hạn, sắp xếp, hoặc hoàn thành từ một trường mà không có hợp đồng xung quanh. Mã trạng thái, token, kích thước trang, và tiêu đề vận chuyển mỗi cái trả lời một câu hỏi hẹp. Nội dung phản hồi, phương thức, danh tính, bộ lọc, phiên bản giao thức, và tài liệu máy chủ cung cấp phần còn lại của ý nghĩa.

Đừng loại bỏ ngữ cảnh chẩn đoán dưới cái tên đơn giản. Một dòng nhật ký ngắn bỏ qua định danh yêu cầu, mục tiêu, phiên bản, phạm vi, hoặc ranh giới có thể biến một khiếm khuyết nhỏ thành hàng giờ suy đoán. Đồng thời, khả năng quan sát phải xóa bỏ thông tin xác thực, bí mật phiên, URL đã ký, và các trường tải trọng nhạy cảm.

Đừng biến một giải pháp tạm thời thành hợp đồng vĩnh viễn. Sửa chữa vấn đề sắp xếp, quyền hạn, định tuyến, nhịp độ, định dạng, hoặc ánh xạ lỗi cơ bản và thêm kiểm tra hồi quy. Một hệ thống trở nên đáng tin cậy khi sự thất bại được chỉ rõ và giới hạn, không phải khi một chạy thủ công tình cờ hoàn thành.

Kết luận

HTTP 429 là tín hiệu điều khiển lưu lượng gắn với khối lượng người gọi. Sửa chữa nó bằng cách xác định phạm vi chính sách thực sự, điều phối tất cả lưu lượng chia sẻ phạm vi đó, tôn trọng hướng dẫn của máy chủ, và giảm công việc có thể tránh được. Nếu nhu cầu đã tối ưu vẫn vượt quá hạn mức, hãy sử dụng kế hoạch hoặc kênh hỗ trợ đã được tài liệu thay vì cố gắng lách luật thi hành.