HTTP 429 Quá Nhiều Yêu Cầu: Nguyên Nhân và Ngăn Ngừa cho Web Scraping

TL;DR:

• HTTP 429 Quá Nhiều Yêu Cầu có nghĩa là một khách hàng đã vượt qua giới hạn yêu cầu được chọn bởi máy chủ trong một khoảng thời gian. Giới hạn có thể được xác định theo tài khoản, thông tin đăng nhập, địa chỉ IP, điểm cuối, khu vực, hoặc hoạt động có trọng số.
• Phản hồi đầu tiên là ngừng thêm công việc. Bảo tồn phản hồi, xác định phạm vi giới hạn, và giữ lại các công việc mới theo một ngân sách yêu cầu chia sẻ.
• Ngăn chặn đến từ sự phối hợp. Kiểm soát đồng thời trung tâm, bộ đệm, loại bỏ trùng lặp, lập lịch thích ứng, và các điều kiện dừng rõ ràng giảm thiểu các yêu cầu lãng phí.
• Trình duyệt Scrapeless Scraping có thể tập trung vào độ đồng thời của trình duyệt và quản lý phiên. Nó nên được vận hành trong các quy tắc mục tiêu, các khoản cho phép tài khoản, và một ngân sách thu thập rõ ràng.

HTTP 429 Quá Nhiều Yêu Cầu là một tín hiệu kiểm soát luồng: máy chủ liên kết một yêu cầu với một người gọi hoặc phạm vi tài nguyên, đếm đủ công việc để vượt qua một chính sách, và từ chối yêu cầu mới. Một lỗi 429 trong việc thu thập dữ liệu web do đó nên được chẩn đoán ở lớp kiểm soát lưu lượng.

Một ngân sách yêu cầu thu thập dữ liệu web được chia sẻ bởi mọi bộ lập lịch và công nhân cung cấp giải pháp bền vững. Hướng dẫn này giải thích cách tìm phạm vi giới hạn, ngăn chặn các lỗi 429 do áp lực tình cờ, và vận hành một quy trình một cách có trách nhiệm.

HTTP 429 có nghĩa là gì?

Tiêu chuẩn xác định là RFC 6585, Phần 4. Nó nói rằng trạng thái 429 chỉ ra rằng người dùng đã gửi quá nhiều yêu cầu trong một khoảng thời gian nhất định — giới hạn tốc độ. Tiêu chuẩn để lại không gian cho các máy chủ lựa chọn cách họ xác định một người dùng và cách họ đếm các yêu cầu.

Sự linh hoạt đó giải thích tại sao chỉ trạng thái một mình không thể tiết lộ quy tắc đầy đủ. Một dịch vụ có thể đếm các yêu cầu theo khóa API, dịch vụ khác theo tài khoản và điểm cuối, và dịch vụ khác theo chi phí có trọng số. Đọc nội dung phản hồi, tiêu đề đã được tài liệu hóa, bảng điều khiển dịch vụ, và hướng dẫn từ nhà cung cấp trước khi thay đổi lưu lượng.

HTTP 429 so với 403 so với 503

RFC 9110 định nghĩa 403 là một sự từ chối và 503 Dịch vụ không khả dụng là một sự bất khả thi xử lý yêu cầu do quá tải hoặc bảo trì. Một nền tảng có thể triển khai hành vi tùy chỉnh, vì vậy hãy bảo tồn nội dung và ID yêu cầu thay vì phân loại từ một con số đơn lẻ.

Cách Giới Hạn Tốc Độ Được Áp Dụng

Một cổng hoặc ứng dụng trước tiên xác định một phạm vi, sau đó tính toán công việc bên trong một khung thời gian hoặc mô hình năng lực.

Xác định mọi nhà sản xuất chia sẻ bộ đếm. Một công nhân cục bộ có thể có vẻ bảo thủ trong khi một đội tàu cùng nhau vượt quá cùng một hạn mức tài khoản.

Nguyên Nhân Phổ Biến Trong Các Quy Trình Thu Thập Dữ Liệu

Những nguyên nhân phổ biến nhất là kiến trúc:

• mỗi công nhân duy trì một bộ đếm tốc độ độc lập;
• một bộ lập lịch phát ra URL trùng lặp sau khi fan-out;
• việc truy xuất vẫn tiếp tục ngay cả khi một trang chưa thay đổi;
• phân trang không có mục, trang, hoặc ranh giới thời gian;
• phát triển và sản xuất chia sẻ thông tin đăng nhập;
• độ đồng thời tự động gia tăng mà không có giới hạn cấp mục tiêu;
• một lỗi của người tiêu dùng khiến công việc thượng nguồn tích lũy;
• các khóa cache bỏ qua chi tiết địa phương, danh tính hoặc sơ đồ và tạo ra các điểm thiếu không cần thiết.

Lưu lượng cũng có thể vượt quá kế hoạch sản phẩm hoặc chính sách tài liệu của mục tiêu ngay cả khi mã đang hoạt động theo thiết kế. Kế hoạch năng lực phải bao gồm cả giới hạn nền tảng trình duyệt của bạn và các quy tắc của dịch vụ đang được truy cập.

Bắt đầu thu thập dữ liệu với Scrapeless

Nâng cao quy trình thu thập dữ liệu web và tự động hóa của bạn với Scrapeless!
Đăng ký hôm nay và nhận $5 tín dụng miễn phí — không yêu cầu thẻ tín dụng.

Nhận tín dụng miễn phí của bạn ngay bây giờ trong Bảng điều khiển Scrapeless.

Chẩn Đoán Phạm Vi Giới Hạn

Khi một lỗi 429 xuất hiện, tạm dừng việc tiếp nhận cho mục tiêu bị ảnh hưởng và bảo tồn bằng chứng. Ghi lại:

• dấu thời gian với múi giờ;
• mẫu URL và phương thức HTTP;
• thông tin xác thực hoặc định danh tài khoản ở dạng đã được sửa đổi;
• môi trường nguồn và nhóm egress;
• độ đồng thời hoạt động và độ sâu hàng đợi;
• tiêu đề phản hồi, nội dung giới hạn, và ID yêu cầu;
• số lượng yêu cầu gần đây theo phạm vi khả thi;
• liệu một ứng dụng khác có chia sẻ cùng một danh tính hay không.

Nhóm các quan sát 429 theo tài khoản, khóa, điểm cuối, máy chủ mục tiêu, và mạng nguồn. Một cụm sắc nét dưới một chiều thường phơi bày bộ đếm. So sánh bằng chứng với tài liệu về hạn ngạch chính thức của nhà cung cấp hoặc yêu cầu chủ sở hữu dịch vụ xác định ID yêu cầu.

Đừng kiểm tra ngưỡng chính xác bằng cách tăng lưu lượng. Việc đó tạo thêm áp lực và có thể vi phạm chính sách hoạt động của mục tiêu.

Ngăn Chặn 429 Với Ngân Sách Yêu Cầu

Ngân sách yêu cầu là một quy tắc nhập viện áp dụng trước khi công việc đến mạng. Định nghĩa nó theo từng mục tiêu và theo từng phạm vi danh tính đã biết, sau đó để mỗi nhà sản xuất dự trữ từ cùng một ngân sách.

Biến bảng tính thành một chính sách hàng đợi trung tâm. Hàng đợi nên biết mục tiêu, phạm vi danh tính, ưu tiên, thời hạn, khóa loại bỏ trùng lặp, và chi phí đơn vị dự kiến. Nó nên từ chối các công việc cũ hoặc trùng lặp trước khi chúng chiếm dụng dung lượng trình duyệt.

Độ Đồng Thời, Bộ Nhớ Đệm, và Loại Bỏ Trùng Lặp

Độ đồng thời kiểm soát bao nhiêu hoạt động đang hoạt động, không phải bao nhiêu hoạt động được phép trong một khoảng thời gian dài hơn. Sử dụng cả giới hạn phiên hoạt động và ngân sách yêu cầu. Đặt các điều khiển trên các công nhân cá nhân để việc mở rộng theo chiều ngang không thể nhân đôi lưu lượng âm thầm.

Bộ nhớ đệm loại bỏ các đọc tương đương khi cửa sổ độ tươi mới của doanh nghiệp cho phép tái sử dụng. RFC 9111 giải thích rằng bộ đệm HTTP giảm thời gian phản hồi và băng thông mạng và đặt các điều kiện để tái sử dụng các phản hồi đã lưu. Bộ nhớ đệm ở cấp độ ứng dụng cần các khóa cẩn thận tương đương: URL mục tiêu, tiêu đề liên quan, vị trí, danh tính được ủy quyền, và phiên bản sơ đồ có thể ảnh hưởng đến tính tương đương.

Loại bỏ trùng lặp sắp xếp nhu cầu cùng thời. Nếu nhiều người tiêu dùng yêu cầu cùng một sản phẩm và cửa sổ quan sát, hãy xuất bản một sự kiện thu thập cho tất cả các người đăng ký. Giữ một mã nội dung hoặc phiên bản nguồn để các quan sát không thay đổi không kích hoạt công việc đắt đỏ ở phía dưới.

Ví dụ địa phương sau đây chấp nhận công việc độc nhất trong một ngân sách cố định và dừng lại khi dung lượng đã được sử dụng:

jobs = ["/a", "/a", "/b", "/c", "/d", "/e"]
request_budget = 4
seen = set()
admitted = []

for path in jobs:
    if path in seen:
        continue
    if len(admitted) >= request_budget:
        break
    seen.add(path)
    admitted.append(path)

print({"admitted": admitted, "remaining": len(jobs) - len(admitted)})

Kết quả chấp nhận /a, /b, /c, và /d, trong khi /a trùng lặp không tiêu tốn bất kỳ dung lượng mạng nào. Trong sản xuất, duy trì bộ đếm chia sẻ trong hạ tầng mà tất cả các công nhân sử dụng.

Giám Sát và Điều Kiện Dừng

Giám sát hệ thống trước khi nó đạt đến từ chối. Các phép đo hữu ích bao gồm công việc được chấp nhận, trùng lặp bị подавленные, hit bộ nhớ đệm, phiên hoạt động, tuổi hàng đợi, đơn vị yêu cầu, số lượng 429 theo phạm vi, và độ tươi mới dữ liệu.

OpenTelemetry mô tả các chỉ số như là các phép đo thời gian thực với dấu thời gian và siêu dữ liệu. Hướng dẫn metrics guidance của nó hỗ trợ các bộ đếm và biểu đồ phù hợp với ngân sách yêu cầu, độ trễ hàng đợi, và độ đồng thời.

Định nghĩa các điều kiện dừng trong cấu hình, không phải trong bộ nhớ của một nhà điều hành:

• bất kỳ 429 nào cho một mục tiêu sẽ đóng cửa nhập viện mới cho phạm vi đó;
• một giới hạn không được ghi lại đóng cửa thu thập tự động chờ xem xét;
• tuổi hàng đợi vượt quá thời hạn doanh nghiệp sẽ loại bỏ công việc cũ;
• tỷ lệ lỗi tăng lên giảm hoặc đóng cửa nhập viện;
• thiếu ủy quyền, xung đột điều khoản, hoặc chính sách robot sẽ dừng thu thập;
• một trần chi phí sẽ dừng các công việc tùy chọn trước khi các công việc thiết yếu.

Mục tiêu là giảm áp lực ngay lập tức và bảo tồn bằng chứng cho một quyết định có kiểm soát. Một 429 không bao giờ nên bắt đầu một vòng lặp tạo ra một yêu cầu khác tự động.

Nơi Scrapeless Scraping Browser Vừa Vặn

Scrapeless Scraping Browser cung cấp việc thực thi trình duyệt được quản lý cho các mục tiêu động, được ủy quyền. Tạo phiên trung tâm làm cho độ đồng thời của trình duyệt có thể nhìn thấy và quản lý, trong khi các đầu vào vị trí và phiên cho phép ứng dụng xác định ngữ cảnh quan sát.

Scrapeless không thay thế chính sách tỷ lệ của mục tiêu. Đặt kết nối trình duyệt phía sau hàng đợi nhập viện chia sẻ của bạn, giới hạn các phiên đồng thời, và đóng công việc khi mục tiêu hoặc ngân sách của bạn nói dừng lại. Tham khảo tài liệu API Scraping Browser để biết chi tiết kết nối hiện tại.

Danh Sách Kiểm Tra Quét Có Trách Nhiệm

• Xác nhận rằng mục tiêu, tài khoản và dữ liệu được ủy quyền cho tự động hóa.
• Đọc các điều khoản của mục tiêu, hướng dẫn API chính thức và các hạn mức đã được tài liệu.
• Lấy và tuân theo các quy tắc có thể phân tích robots.txt khi áp dụng. RFC 9309 định nghĩa hành vi truy cập và phân tích tiêu chuẩn hóa cho các quy tắc của bot.
• Sử dụng một ngân sách yêu cầu cấp mục tiêu được chia sẻ giữa các dịch vụ.
• Loại bỏ các URL trùng lặp và lưu trữ các quan sát tương đương trong khoảng thời gian tươi mới.
• Giới hạn phân trang, số lượng mục, thời gian đã trôi qua và chi tiêu.
• Tách biệt thông tin xác thực và ngân sách cho phát triển, staging và sản xuất.
• Ghi lại ID yêu cầu và phạm vi chính sách mà không lưu trữ bí mật.
• Dừng công việc mới khi xuất hiện xung đột 429 hoặc ủy quyền.
• Liên hệ với chủ sở hữu dịch vụ khi nhu cầu chính đáng vượt quá hạn mức đã được tài liệu.

Kết Luận

HTTP 429 Too Many Requests được xử lý tốt nhất như một vấn đề về năng lực và quản trị. Xác định bộ đếm, phối hợp mọi nhà sản xuất bên dưới một ngân sách yêu cầu, loại bỏ công việc trùng lặp, tái sử dụng các kết quả đã lưu trữ phù hợp, giới hạn độ đồng thời và làm cho các điều kiện dừng trở nên tự động.

Trình duyệt không có rác Scrapeless có thể là lớp thực thi được kiểm soát cho việc thu thập phụ thuộc vào trình duyệt, trong khi lớp hàng đợi và chính sách xác định những gì được chấp nhận. Xem giá cả Scrapeless khi xác định dung lượng phiên.

Đặt Công Việc Trình Duyệt Sau Một Ngân Sách

Sử dụng Bảng điều khiển Scrapeless để đánh giá các phiên trình duyệt được quản lý, và xem cách xử lý phân trang trong web scraping mà không cần duyệt trang không giới hạn. Tham gia cộng đồng trên Discord hoặc Telegram.

Câu Hỏi Thường Gặp

H: Nguyên nhân nào gây ra lỗi 429 trong web scraping?

Máy chủ phát ra 429 khi nó liên kết khách hàng với phạm vi yêu cầu và quyết định rằng phạm vi đó đã vượt quá chính sách tỷ lệ. Các công việc trùng lặp, thông tin xác thực được chia sẻ, công nhân không phối hợp, và độ đồng thời quá mức là những nguyên nhân phổ biến trong quy trình.

H: HTTP 429 có giống như 503 không?

Không. Một 429 liên quan đến việc từ chối khối lượng yêu cầu của người gọi theo một chính sách đã chọn. Một 503 chỉ ra rằng dịch vụ hiện không thể xử lý yêu cầu vì quá tải hoặc bảo trì.

H: Liệu việc xoay proxy có thể ngăn chặn lỗi 429 không?

Xoay proxy không nên được sử dụng để trốn tránh hạn mức hoặc chính sách lưu lượng của mục tiêu. Chẩn đoán phạm vi đã được tài liệu, giảm công việc, phối hợp hạn mức hợp pháp, và yêu cầu thêm dung lượng từ chủ sở hữu dịch vụ khi cần thiết.

H: Làm thế nào mà việc lưu cache ngăn chặn lỗi 429?

Lưu cache cho phép nhu cầu tương đương tái sử dụng một quan sát phù hợp thay vì tạo ra một yêu cầu mạng khác. Khóa cache và khoảng thời gian tươi mới phải phản ánh URL, vị trí, danh tính, sơ đồ và chính sách nguồn.

H: Làm thế nào để kiểm soát độ đồng thời của trình duyệt?

Đặt việc tạo phiên phía sau một hàng đợi tập trung. Thực thi một mức giới hạn cấp mục tiêu, dự trữ dung lượng cho công việc quý giá, đo lường tuổi của hàng đợi, và ngăn chặn các công nhân cá nhân tăng cường đội ngũ độc lập.

H: Thực sự nên xảy ra điều gì ngay khi xuất hiện lỗi 429?

Dừng việc tiếp nhận công việc mới cho phạm vi bị ảnh hưởng, bảo toàn phản hồi và ID yêu cầu, xác định bộ đếm chia sẻ, và tham gia chủ sở hữu dịch vụ hoặc đội ngũ nền tảng nội bộ trước khi thu thập tiếp tục.