Thử lại và Xử lý Lỗi trong Các Trình thu thập Dữ liệu Sản xuất
TL;DR
Một trình thu thập dữ liệu sản xuất cần kết quả cuối cùng cho mọi URL: được chấp nhận, bị từ chối, hoãn lại, hoặc thất bại với lý do. Một HTTP 200 đơn thuần không phải là thành công.
Thử lại các lỗi mạng tạm thời và các trạng thái được chọn như 408, 429, và 5xx; không tự động thử lại 401, 403, hoặc một sự không khớp với trình phân tích.
Tôn trọng Retry-After, sử dụng phương pháp lùi thời gian với jitter giới hạn, và giữ một ngân sách yêu cầu cụ thể cho nguồn để các lần thử lại không làm tệ đi tình trạng quá tải.
Làm cho các hoạt động ghi là idempotent và lưu trữ số lần cố gắng, thời gian đủ điều kiện tiếp theo, và lỗi cuối cùng; các lần khởi động lại quy trình không nên làm mất hoặc trùng lặp các hồ sơ đã được chấp nhận.
Nstdata Crawl cung cấp trạng thái nhiệm vụ được quản lý và phục hồi cho việc thu thập, trong khi ứng dụng của bạn vẫn xác thực ý nghĩa trang và kiểm soát các lần thử lại phía dưới.
Tại Sao Các Trình Thu Thập Dữ Liệu Cần Hơn Một Vòng Lặp Thử Lại?
Một vòng lặp thử lại giải quyết một loại thất bại: một yêu cầu mà có thể thành công sau này. Một trình thu thập dữ liệu sản xuất cũng cần biết liệu nó đã đến trang mong muốn, liệu việc trích xuất có tạo ra một hồ sơ hợp lệ, và liệu kết quả có được lưu trữ. Một phản hồi 200 có thể là một màn hình đồng ý, lời nhắc đăng nhập, shell JavaScript trống, hoặc trang chủ dự phòng. Thử lại phản hồi đó vô hạn lãng phí yêu cầu và có thể làm quá tải nguồn.
Nstdata Crawl có thể xử lý việc hiển thị trình duyệt và thu thập, nhưng ứng dụng vẫn cần chính sách ghi nhận và thử lại của riêng nó.
Trải nghiệm Nstproxy Crawl - Bắt Đầu Dùng Thử Miễn Phí Hôm Nay
Tách bốn ranh giới: vận chuyển, phản hồi HTTP, nội dung, và lưu trữ. Các lỗi vận chuyển bao gồm DNS, kết nối, và thất bại thời gian chờ. Trạng thái HTTP mô tả phản hồi của máy chủ nhưng không phải là nội dung ngữ nghĩa của nó. Xác thực nội dung quyết định liệu trang có thể sử dụng được. Lưu trữ xác nhận hồ sơ đã được chấp nhận là bền vững. Cung cấp cho mỗi ranh giới một mã lỗi và chủ sở hữu khác biệt. Nstdata Crawl có thể đơn giản hóa ranh giới thu thập, nhưng nó không biết liệu một giá trích xuất có khớp với biến thể sản phẩm của bạn.
Những Lỗi Nào Nên Thử Lại?
Chỉ thử lại khi sự cố có khả năng là tạm thời và nguồn cho phép một yêu cầu khác. Tài liệu Scrapy RetryMiddleware hiện tại bao gồm 408, 429, 500, 502, 503, 504, 522, và 524 trong các trạng thái thử lại mặc định của nó. Đây là một tài liệu tham khảo hữu ích, không phải là quy tắc để sao chép một cách mù quáng: hành vi cụ thể của nguồn và Retry-After là quan trọng.
Triệu chứng
Quyết định khả thi
Lý do
Kết nối bị thiết lập lại hoặc thời gian chờ
Thử lại có giới hạn
Có thể là tạm thời; ghi lại nguyên nhân
429
Hoãn lại sử dụng Retry-After và giảm tỷ lệ
Nguồn đang giới hạn yêu cầu
503
Giảm tốc; thử lại trong ngân sách
Tình trạng không khả dụng tạm thời là khả thi
401 hoặc 403
Dừng lại và xem xét quyền truy cập
Các cố gắng lặp lại không cấp quyền
404
Xác minh URL hoặc đánh dấu bị thiếu
Thường không được sửa bằng cách thử lại nhanh chóng
200 với màn hình đồng ý/đăng nhập
Từ chối và điều tra
Vận chuyển đã hoạt động; nội dung không đúng
Trường bị thiếu
Xem lại trình phân tích hoặc nguồn
Các yêu cầu giống hệt nhau có thể không sửa được markup
Không bao giờ thay đổi danh tính, thay đổi tiêu đề, hoặc loại bỏ các hạn chế nguồn chỉ để buộc một yêu cầu bị từ chối thông qua. Xem xét đường dẫn truy cập đã được phê duyệt hoặc sử dụng một API chính thức. Tài liệu HTTP Semantics specification là cơ quan cho ý nghĩa mã trạng thái và tiêu đề.
Bạn Cần Gì Trước Khi Triển Khai Các Lần Thử Lại?
Định nghĩa một chính sách yêu cầu theo nguồn, ngân sách số lần cố gắng và thời gian thực tế tối đa, giá trị thời gian chờ, dấu hiệu trang đã chấp nhận, và lưu trữ nhiệm vụ bền. Cài đặt một client như requests nếu sử dụng Python. Ghi lại source_id, URL, số lần cố gắng, trạng thái/lỗi cuối cùng, next_fetch_at, và một khóa hồ sơ ổn định. Nếu ứng dụng gửi nhiều worker, hãy phối hợp tốc độ theo từng máy chủ giữa chúng; một khoảng thời gian chờ cục bộ trong mỗi worker không giới hạn tỷ lệ kết hợp của chúng.
Giữ thông tin xác thực trong một trình quản lý bí mật hoặc biến môi trường. Đối với các cuộc gọi Crawl được quản lý, hãy lấy một khóa API Nstdata từ Dashboard → Crawl Playground và gửi nó dưới dạng x-api-key. Việc định tuyến proxy được tích hợp nghĩa là yêu cầu Crawl bình thường không cần các trường kết nối proxy riêng biệt.
Bạn Triển Khai Các Lần Thử Lại Có Giới Hạn Trong Python Như Thế Nào?
Phương pháp 1: Thử lại Các Lỗi Tạm Thời HTTP và Mạng
Bước 1. Sử dụng một phiên với thời gian chờ kết nối và đọc rõ ràng. Xác định client và chỉ hoạt động trong mẫu truy cập cho phép của nguồn.
Bước 2. Xử lý các trạng thái có thể thử lại, Retry-After, và ngoại lệ mạng một cách riêng biệt:
Bước 3. Xác thực trang trả về trước khi chấp nhận nó. Kiểm tra loại nội dung, nguồn chính thức, tiêu đề, các trường yêu cầu và các mẫu lỗi mềm đã biết. Ghi lại một rejected_reason rõ ràng nếu phản hồi 200 không phải là trang dự định.
Ví dụ này được giới hạn một cách có chủ đích. Trong sản xuất, đưa thời gian tối đa đã trôi qua xung quanh các lần thử lại và xác thực bất kỳ Retry-After rất lớn nào so với ngân sách công việc bằng cách hoãn tác vụ thay vì giữ cho một tác nhân ngủ. Đoạn mã không thử lại 401 hoặc 403; raise_for_status() sẽ hiển thị chúng để xem xét chính sách.
Làm Thế Nào Để Bạn Giữ Các Lần Thử An Toàn Sau Khi Tác Nhân Khởi Động Lại?
Phương Pháp 2: Sử Dụng Một Máy Trạng Thái Tác Vụ Bền
Bước 1. Lưu trữ các tác vụ URL trong một hàng đợi hoặc bảng với một khóa duy nhất và các trạng thái như pending, leased, retry_pending, accepted, rejected, và failed_terminal.
Bước 2. Cung cấp cho một tác nhân một hợp đồng giới hạn thời gian. Ghi lại nguyên liệu thô và kết quả đã được xác thực trước khi xác nhận tác vụ. Nếu tác nhân gặp sự cố sau khi ghi nhưng trước khi xác nhận, tác nhân tiếp theo phải nhận ra cùng một phiên bản bản ghi và tránh việc chèn trùng lặp.
Bước 3. Trong trường hợp thất bại có thể thử lại, lưu lại số lần thử và next_fetch_at. Trong trường hợp từ chối chính sách hoặc nội dung bị từ chối, ghi lại lý do cuối cùng và dừng các yêu cầu tự động. Đối chiếu số lần nộp và số lần cuối cùng vào cuối mỗi lần chạy.
Một mã băm nội dung hữu ích cho việc phát hiện sự thay đổi nhưng không nên là danh tính duy nhất. Hai URL khác nhau có thể hợp pháp chia sẻ văn bản, và một URL có thể tạo ra nhiều phiên bản. Sử dụng ID nguồn và URL chính thức cho danh tính thực thể, cộng với mã băm và thời gian lấy cho các phiên bản.
Làm Thế Nào Để Bạn Chẩn Đoán Sự Cố Gặm Nhấm Im Lặng?
Phương Pháp 3: Thêm Kiểm Tra Chấp Nhận Ngữ Nghĩa
Bước 1. Lưu lại một tập hợp thiết bị nhỏ: trang bình thường, chuyển hướng, trường thiếu, trang đồng ý đã biết, trang lỗi, và shell JavaScript.
Bước 2. Định nghĩa các dấu hiệu yêu cầu cho mỗi loại trang. Một bản ghi sản phẩm có thể yêu cầu ID sản phẩm, tiền tệ và một giá cả rõ ràng; một bài viết cần tiêu đề và nội dung. Xác thực các dấu hiệu đó sau khi lấy và trước khi lưu trữ.
Bước 3. Lấy mẫu cả các bản ghi đã chấp nhận và bị từ chối sau khi thay đổi nguồn hoặc trình phân tích. Cảnh báo về kết quả chấp nhận và lý do từ chối theo miền, không chỉ tỷ lệ lỗi yêu cầu.
Nstdata Có Thể Giúp Giữ Lỗi Mua Sắm Có Quan Sát Như Thế Nào?
Nstdata Crawl là một API Crawling Web cho dữ liệu sẵn sàng LLM chấp nhận một trang đã được xem xét hoặc công việc trang web bị giới hạn và công bố trạng thái và kết quả nhiệm vụ. Tài liệu của nó phân biệt phản hồi HTTP bên ngoài với mã success, status, và lỗi của nhiệm vụ lồng nhau; một ứng dụng phải kiểm tra cả hai. Các lần thử lại và tổ chức proxy tích hợp sẵn có thể giảm bớt công việc hạ tầng, nhưng một tác vụ vẫn có thể thất bại, trả về một trang bị từ chối, hoặc sản xuất nội dung thất bại theo sơ đồ của bạn.
Đầu ra sẵn sàng LLM: Markdown và HTML đã được làm sạch cho phép mã RAG hoặc trích xuất phía dưới tập trung vào nội dung liên quan; dữ liệu thô giúp chẩn đoán một chuyển đổi xấu. Liên kết, ảnh chụp màn hình, và PDF cung cấp điều hướng và bằng chứng hình ảnh. Chọn chỉ các định dạng mà người tiêu dùng cần, và kiểm tra markdownRef, htmlRef, hoặc các tham chiếu khác khi các đầu ra lớn được lưu trữ riêng biệt.
Định tuyến proxy tích hợp sẵn: Yêu cầu API tiêu chuẩn lấy x-api-key và tùy chọn trang mà không cần các trường proxy Host, Port, Username, Password, hoặc Protocol riêng biệt. Điều này giảm bớt việc thiết lập và xử lý thông tin xác thực cho việc thu thập được phép. Định tuyến proxy không cấp quyền truy cập bị từ chối bởi một nguồn.
Tính minh bạch của tác vụ: Các công việc trang web báo cáo số lượng hoàn thành, thất bại, và đang chờ thông qua lộ trình trạng thái được tài liệu hóa. Ứng dụng của bạn vẫn nên đối chiếu các bản ghi kinh doanh được chấp nhận và từ chối.
Làm Thế Nào Để Bạn Thêm Nstdata Crawl Vào Quy Trình Làm Việc Thử Lại?
Bước 1. Nhận một API key trong Bảng Điều Khiển → Crawl Playground và chọn một URL thử nghiệm được phê duyệt. Đặt thời gian chờ yêu cầu trong các giới hạn được tài liệu hiện hành.
Bước 2. Gửi một trang duy nhất và lưu phản hồi thô để so sánh chẩn đoán:
curl--request POST 'https://api.nstdata.io/api/v1/crawl/scrape/submit-sync'\--header"x-api-key: ${NSTDATA_API_TOKEN}"\--header'Content-Type: application/json'\--data'{"url":"https://example.com/","formats":["markdown","html"],"timeout":60000}'
Bước 3. Kiểm tra trạng thái HTTP bên ngoài, sau đó data.success, data.status, bất kỳ mã tác vụ nào, và data.data.metadata.statusCode. Lấy mã thông báo tham chiếu thông qua GET /api/v1/crawl/storage/read?st={ref} khi cần. Áp dụng các quy tắc chấp nhận ngữ nghĩa của bạn và lưu một kết quả cuối cùng. Đoạn mã theo tài liệu chính thức nhưng không thể thực hiện trực tiếp mà không có khóa tài khoản.
Trong sản xuất, giới hạn số lần thử cả ở lớp nhà cung cấp và lớp ứng dụng để cùng một trang thất bại không tiêu tốn ngân sách lặp đi lặp lại. Đối với các tương tác trình duyệt được phép ngoài việc chuyển đổi trang, Nstdata Cloud Browser là một sản phẩm riêng biệt. Hành động tiếp theo là một cuộc tập dượt thất bại: làm cho một trang quá thời gian, một trang trả về lỗi mềm, và một trang vượt qua, sau đó xác nhận mọi nhiệm vụ đều kết thúc ở trạng thái đúng.
Khi nào thì một trình thu thập thông tin nên mở hộp cầu dao?
Tạm dừng một nguồn khi các lỗi lặp lại cho thấy rằng nhiều yêu cầu có khả năng không giúp ích. Sự gia tăng đột ngột trong các phản hồi 403, các trang thách thức, các bản render trống, hoặc việc bác bỏ trình phân tích nên mở một hộp cầu dao cụ thể cho nguồn và cảnh báo chủ sở hữu. Sử dụng một thăm dò ngắn, có kiểm soát chỉ sau khi vấn đề truy cập hoặc nguồn đã được xem xét. Một hộp cầu dao bảo vệ mục tiêu khỏi tải không cần thiết và ngăn chặn một mẫu xấu làm ô nhiễm tập dữ liệu. Ghi lại khi nó mở ra, lý do, và ai đã cấp phép cho việc tiếp tục.
H: Một trình thu thập thông tin có nên thử lại mọi yêu cầu thất bại không?
Không. Thử lại các lỗi tạm thời trong ngân sách; dừng và xem xét ủy quyền, các trang bị thiếu vĩnh viễn, và các lỗi của trình phân tích.
H: HTTP 200 có phải là bằng chứng của việc thu thập thông tin tốt không?
Không. Xác thực danh tính của trang và nội dung cần thiết trước khi chấp nhận một bản ghi.
H: Tôi có nên bỏ qua giá trị Retry-After dài không?
Không. Trì hoãn nhiệm vụ hoặc dừng nó khi thời gian chờ được yêu cầu vượt quá ngân sách công việc của bạn; không rút ngắn thời gian chờ của nguồn để phù hợp với một vòng lặp địa phương.
H: Nstdata có loại bỏ nhu cầu thử lại ứng dụng không?
Không. Nó xử lý khôi phục thu acquisition và trạng thái nhiệm vụ, trong khi ứng dụng của bạn phải xử lý việc giao hàng hàng đợi, xác thực, lập chỉ mục, và các lỗi cuối cùng.
Lena Zhou
Oct. 30th 2026
Thu thập toàn bộ trang web chỉ với một yêu cầu API
Tỷ lệ thành công 99,8% với kết xuất JavaScript
Nhận dữ liệu sạch, sẵn sàng cho LLM ở nhiều định dạng
Chuyển mọi trang web thành Markdown, HTML, JSON, liên kết, PDF và hơn thế nữa mà không cần quản lý hạ tầng thu thập dữ liệu.
