Làm thế nào để thiết lập tính đồng thời trích xuất dữ liệu từ web mà không bị bão thử lại

TL;DR

• Giới hạn đồng thời kiểm soát công việc đang thực hiện; giới hạn tốc độ kiểm soát tốc độ bắt đầu các yêu cầu mới.
• Áp dụng giới hạn cho nguồn và phạm vi tài khoản thực sự chia sẻ tài nguyên, không chỉ cho từng công nhân độc lập.
• Các yêu cầu được thử lại phải sử dụng cùng một ngân sách tiếp nhận như lần đầu tiên.
• Xem HTTP 429 là tín hiệu làm mát chung và giữ nguyên bất kỳ hướng dẫn Retry-After hợp lệ nào.
• Tăng đồng thời chỉ khi tốc độ dữ liệu được chấp nhận cải thiện mà không gây trễ không thể chấp nhận, lỗi hoặc tăng trưởng hàng đợi.
• Giữ các nhiệm vụ CAPTCHA và yêu cầu đích trong các nhóm riêng biệt với sự chuyển giao rõ ràng giữa chúng.

Một trình quét có thể gửi nhiều yêu cầu hơn nhưng thu thập ít dữ liệu hữu ích hơn. Các phản hồi chậm giữ kết nối chiếm dụng, công nhân lặp lại các yêu cầu thất bại và hàng đợi đầy ắp các bản sao của công việc đang tiến hành. Tăng số lượng công nhân sau đó có thể khuếch đại cùng một điểm nghẽn. Chỉ số hiệu suất hữu ích là dữ liệu được chấp nhận được giao trong thời hạn của công việc, không phải số lượng yêu cầu được bắt đầu.

Hướng dẫn này giải thích cách thiết lập giới hạn đồng thời quét cho một quy trình thu thập được ủy quyền. Nó bao gồm tiếp nhận cấp nguồn, lịch trình thử lại, tài nguyên trình duyệt và quy trình điều chỉnh có kiểm soát. CapSolver phù hợp vào giai đoạn xử lý CAPTCHA riêng biệt khi quy trình được phép yêu cầu một. Không phải số lượng nhóm công nhân lớn hơn hay việc hoàn thành thử thách thay đổi chính sách tốc độ của nguồn, vì vậy bộ lập lịch phải duy trì kiểm soát trong suốt quá trình.

Tách biệt đồng thời khỏi tốc độ yêu cầu

Đồng thời là số lượng thao tác đang thực hiện, trong khi tốc độ yêu cầu đo số lần bắt đầu theo thời gian. Một giới hạn đồng thời riêng lẻ không đảm bảo tốc độ yêu cầu ổn định vì thời gian phản hồi thay đổi cách nhanh các vị trí trở nên sẵn sàng.

Hãy tưởng tượng một nguồn thử nghiệm được phép với bốn vị trí yêu cầu hoạt động. Nếu các yêu cầu kết thúc nhanh, các vị trí đó có thể tạo ra nhiều lần bắt đầu trong một khoảng thời gian ngắn. Nếu phản hồi chậm lại, cùng bốn vị trí đó tạo ra ít lần bắt đầu hơn trong khi dành nhiều thời gian hơn để chiếm dụng. Cả hai hành vi đều tuân theo giới hạn đồng thời. Một bộ điều khiển tốc độ riêng biệt là cần thiết khi các lần bắt đầu phải duy trì trong một khoản cho phép theo thời gian.

Các thuật ngữ về đồng thời và các thuật ngữ về giới hạn tốc độ mô tả các khái niệm liên quan. Trong bộ lập lịch của bạn, ghi lại chúng như các cài đặt riêng biệt. Thêm một hàng đợi chờ tối đa và thời hạn công việc để công việc bị trì hoãn không thể tích lũy vô hạn sau các giới hạn hợp lý.

Không có số lượng yêu cầu đồng thời tối ưu tuyệt đối. Chính sách nguồn, kích thước dữ liệu, trình duyệt, băng thông và xử lý phía sau tất cả ảnh hưởng đến điểm hoạt động hữu ích. Bắt đầu từ khoản cho phép được tài liệu hóa của nguồn và năng lực của bạn, sau đó đo lường một khối lượng công việc được phép rõ ràng.

Bước 1: Xác định phạm vi chia sẻ giới hạn

Một giới hạn đồng thời phải bao gồm các công nhân cạnh tranh cho cùng tài nguyên hoặc quyền truy cập. Một cài đặt theo quy trình không đủ khi nhiều quy trình, máy tính hoặc công việc truy cập cùng một nguồn bị giới hạn.

Xác định phạm vi liên quan trước khi tạo công nhân. Nó có thể là tên máy chủ, chứng chỉ API, hạn mức tài khoản được định nghĩa bởi nguồn, hoặc phiên trình duyệt được kiểm soát. Sử dụng phạm vi được mô tả bởi nhà cung cấp thay vì giả định rằng mỗi URL có tài nguyên độc lập. Các tên miền con cũng có thể chia sẻ cơ sở hạ tầng hoặc hạn mức tài khoản.

Tách biệt tài nguyên toàn cầu khỏi tài nguyên nguồn. Một giới hạn tối đa bảo vệ máy tính của bạn và tài nguyên đầu ra. Các giới hạn theo nguồn ngăn một hàng đợi nhanh chiếm hết tất cả các vị trí có sẵn. Nếu nguồn tạm dừng, một nguồn được phép độc lập khác có thể tiếp tục mà không cần mượn danh tính hoặc hạn mức của nguồn đã dừng.

Đối với quy trình trình duyệt, xác định điều gì chiếm một vị trí: một lần điều hướng, trang đang hoạt động, hay toàn bộ phiên. Một phiên được liên kết với tài khoản không nên được chia sẻ một cách tùy tiện giữa các công việc đồng thời. Cookie, hành động đang chờ và đích mong đợi cần có người sở hữu trong suốt thời gian nhiệm vụ.

Bước 2: Đảm bảo mọi yêu cầu đi qua tiếp nhận

Tiếp nhận nên xảy ra trước khi yêu cầu bắt đầu và áp dụng đồng đều cho các lần thử ban đầu, thử lại, chuyển hướng do khách hàng kiểm soát, và khởi động lại công nhân. Một đường thử lại gửi trực tiếp đến giao diện truyền có thể phá vỡ giới hạn của bộ lập lịch chính.

Sử dụng một danh tính nhiệm vụ cho quan sát mong muốn và danh tính thử lại riêng biệt cho công việc truyền. Điều này cho phép hàng đợi phân biệt giữa một lần thử lại hợp lệ và một công việc được lập lịch trùng lặp. Nếu công nhân khởi động lại, nó nên kiểm tra xem quan sát đã hoàn thành hay chưa trước khi tạo yêu cầu khác.

Một vị trí nên được giải phóng khi thao tác liên quan thực sự đã hoàn thành hoặc giao diện truyền đã bị hủy. Giải phóng tài nguyên chỉ vì người gọi dừng chờ có thể để lại các yêu cầu ẩn chạy vượt quá giới hạn danh nghĩa. Xem công việc không chắc chắn hoặc vẫn đang chạy là tài nguyên đang sử dụng cho đến khi trạng thái được giải quyết.

Giới hạn hàng đợi nữa. Khi công việc đến quá nhiều, hoãn cửa sổ thu thập sau, từ chối yêu cầu thừa, hoặc giảm phạm vi yêu cầu theo hợp đồng dịch vụ của bạn. Giữ một danh sách chờ không giới hạn chuyển lỗi vào áp lực bộ nhớ và quan sát lỗi thời.

Bước 3: Lập lịch thử lại thay vì ngủ ở mọi nơi

Các lần thử lại nên quay lại hàng đợi được kiểm soát với thời gian đủ điều kiện tương lai, số lần thử và thời hạn công việc còn lại. Các lời gọi ngủ phân tán bên trong công nhân làm khó phối hợp thời gian làm mát chung.

Mã trạng thái HTTP 429 cho biết đã gửi quá nhiều yêu cầu trong khoảng thời gian liên quan. Khi phản hồi bao gồm Retry-After, giữ nguyên thời gian hoặc ngữ nghĩa ngày tháng. Không để mỗi công nhân chọn thời gian chờ ngắn hơn độc lập.

Sử dụng thời gian làm mát chung cho phạm vi bị ảnh hưởng. Ngừng tiếp nhận công việc mới ở đó trong khi thời gian làm mát đang hoạt động, bao gồm cả các yêu cầu chưa từng thất bại. Công việc đang chạy có thể kết thúc, nhưng một phản hồi thành công từ một công nhân không nên tự động xóa thời gian làm mát hợp lệ được quan sát bởi công nhân khác.

Đối với các lỗi đọc tạm thời mà không có hướng dẫn máy chủ, áp dụng chính sách thử lại có giới hạn phù hợp với thao tác. Một lịch trình phân tán có thể tránh các đợt xung đột đồng bộ sau khi dừng. Không thêm thử lại vào thao tác gửi biểu mẫu hoặc các thao tác thay đổi trạng thái trừ khi hiệu ứng và khả năng lặp lại được hiểu rõ.

Quan sát	Phản hồi của bộ lập lịch	Bằng chứng cần giữ
HTTP 429	Tạm dừng phạm vi bị ảnh hưởng và tuân thủ hướng dẫn thử lại	Phạm vi nguồn, thời gian phản hồi, thời gian làm mát
Thời gian chờ đọc tạm thời	Đưa lại chỉ trong ngân sách thử lại và thời hạn	Danh tính thử lại và thời gian còn lại
Từ chối xác thực hoặc truy cập	Dừng hoặc định tuyến để xem xét truy cập	Loại phản hồi bị che
Điểm kiểm tra CAPTCHA được hỗ trợ	Vào giai đoạn thử thách được phép riêng biệt	Quan sát hiện tại và bối cảnh thử thách
Bản ghi trích xuất không hợp lệ	Khảo sát cách phân tích hoặc dữ liệu nguồn	Tham chiếu trang được giữ và lỗi xác minh

Nhận mã thưởng CapSolver của bạn

Tăng ngân sách tự động hóa của bạn ngay lập tức!
Sử dụng mã thưởng CAP26 khi nạp tiền vào tài khoản CapSolver để nhận thêm 5% thưởng cho mỗi lần nạp — không giới hạn.
Nhận mã ngay bây giờ trong Bảng điều khiển CapSolver

Bước 4: Ngăn xử lý thử thách làm tăng nhu cầu

Một điểm kiểm tra CAPTCHA nên tạo ra sự chuyển giao được kiểm soát, không phải một vòng lặp yêu cầu bổ sung chạy song song với trình quét. Quan sát đích vẫn là một nhiệm vụ ngay cả khi nó yêu cầu bước thử thách được hỗ trợ.

Tài liệu tạo nhiệm vụ CapSolver định nghĩa việc gửi nhiệm vụ, trong khi getTaskResult mô tả việc lấy kết quả. Tuân theo các yêu cầu nhiệm vụ phù hợp và giữ liên kết danh tính nhiệm vụ được trả về với quan sát hiện tại. Quét một nhiệm vụ đã biết và tạo một nhiệm vụ mới là các thao tác khác nhau.

Gán giai đoạn này một giới hạn riêng cho công việc đang hoạt động, thời gian và số lần thử. Quyền hạn tốc độ của đích vẫn áp dụng khi trình duyệt tiếp tục. Một kết quả thử thách không nên cấp phép ngoại lệ tức thì cho thời gian làm mát của nguồn hoặc khiến tất cả công nhân bị dừng khởi động cùng nhau.

Nếu việc gửi nhiệm vụ hết thời gian trước khi biết được sự chấp nhận, giữ sự không chắc chắn. Gửi lại nhiệm vụ một cách mù quáng có thể nhân đôi công việc. Bộ lập lịch nên biết liệu nó có đang chờ kết quả hiện tại, đang điều tra yêu cầu không chắc chắn, hay đóng quan sát để xem xét.

Sau khi đích tiếp tục, xác minh trang mong muốn và ghi nhận hợp đồng. Ngược lại, lưu lượng thử thách tăng có thể che giấu thực tế rằng đầu ra thu thập được chấp nhận không cải thiện.

Bước 5: Chạy tăng đồng thời có kiểm soát

Một giai đoạn tăng đồng thời nên thay đổi một cài đặt tài nguyên trong khi giữ ổn định khối lượng công việc so sánh và tiêu chí chấp nhận. Sử dụng nguồn thử được sở hữu hoặc môi trường khác nơi kiểm tra tải được phép rõ ràng.

Thiết lập cơ sở

Bắt đầu với khối lượng công việc được phép nhỏ và ghi lại các quan sát hoàn thành, bản ghi được chấp nhận, độ trễ yêu cầu, danh mục lỗi và tuổi hàng đợi. Tách biệt thời gian chờ tiếp nhận khỏi thời gian trên mạng hoặc trong trình duyệt. Thời gian kết thúc dài có thể có các nguyên nhân khác nhau cần các giải pháp khác nhau.

Giữ các lần thử ban đầu và thử lại hiển thị trong cùng báo cáo. Nếu bản ghi được chấp nhận không thay đổi trong khi tổng số yêu cầu tăng, lưu lượng bổ sung không tạo ra luồng hữu ích. Kiểm tra xem chính sách thử lại, sự sẵn sàng trang, hoặc xác minh phía sau giải thích sự khác biệt trước khi thêm công nhân.

Tăng chỉ khi kết quả cải thiện

Tăng giới hạn theo bước định trước nhỏ và quan sát khoảng thời gian tương đương. Dừng tăng khi lưu lượng chấp nhận phẳng, tần suất lỗi tăng, hoặc độ trễ đuôi vượt quá nhu cầu nhiệm vụ. Những quan sát này xác định ranh giới tài nguyên cho khối lượng công việc đó; chúng không chứng minh một giới hạn toàn bộ nhà cung cấp.

Lặp lại các trường hợp đại diện trên kích thước dữ liệu và loại trang. Một trang HTML nhẹ và bảng điều khiển JavaScript nặng có thể yêu cầu tài nguyên trình duyệt rất khác nhau. Tránh chọn giới hạn hoạt động từ các trang dễ nhất riêng lẻ.

Giữ khoảng trống cho sự biến đổi

Chọn điểm hoạt động có khoảng trống dưới ranh giới lỗi thay vì chạy liên tục ở giá trị cao nhất chỉ vừa qua. Hiệu suất nguồn và cơ sở hạ tầng của bạn có thể thay đổi. Dự trữ tài nguyên cho công việc được lên lịch và ngăn các công việc khám phá chiếm toàn bộ nhóm.

Hiểu các điều khiển làm chậm tự động

Làm chậm tự động có thể điều chỉnh thời gian yêu cầu theo độ trễ quan sát, nhưng hành vi của nó phụ thuộc vào triển khai và giới hạn được cấu hình. Đọc tài liệu khung tiêu thụ trước khi kết hợp với bộ lập lịch thứ hai.

Tài liệu Scrapy AutoThrottle mô tả một mục tiêu đồng thời và điều chỉnh độ trễ dựa trên độ trễ, đồng thời tuân thủ các giới hạn đồng thời được cấu hình. Mục tiêu của nó không phải là cam kết không điều kiện rằng một số lượng yêu cầu chính xác luôn hoạt động. Các phản hồi không thành công cũng nhận được xử lý đặc biệt trong tính toán độ trễ.

Sử dụng các điều khiển cụ thể khung cho phạm vi được tài liệu hóa. Một bộ làm chậm cục bộ của trình quét không tự động phối hợp các triển khai độc lập hoặc áp đặt một hạn mức tổ chức tổng thể. Nếu nhiều công việc chia sẻ một khoản cho phép, đặt một bộ điều khiển chung trên các công nhân độc lập đó.

Ghi lại cấu hình hiệu quả được sử dụng cho mỗi lần chạy. Một thí nghiệm đồng thời khó tái tạo nếu khung, nhóm truyền, middleware thử lại và bộ lập lịch bên ngoài thay đổi cùng lúc. Tổng quan cơ sở hạ tầng trình duyệt cung cấp bối cảnh hữu ích để tách biệt các tài nguyên này.

Chẩn đoán lưu lượng thấp trước khi tăng tài nguyên

Lưu lượng chấp nhận thấp có thể đến từ mạng, nguồn, trình duyệt, bộ phân tích hoặc kho lưu trữ đích. Nhiều công nhân tải chỉ giúp một số điểm nghẽn và có thể làm xấu các điểm khác.

Nếu hàng đợi tăng trong khi các vị trí mạng vẫn trống, kiểm tra logic tiếp nhận và thời gian làm mát. Nếu bộ nhớ trình duyệt tăng, xem xét thời gian sống phiên và làm sạch trang. Nếu yêu cầu kết thúc nhưng bản ghi bị từ chối, kiểm tra sự sẵn sàng nội dung, thay đổi lược đồ và hành vi bộ phân tích. Nếu bản ghi được chấp nhận chờ lưu trữ, áp dụng áp lực ngược từ người viết phía sau.

Giữ quy trình dừng rõ ràng. Người vận hành nên có thể dừng các lần bắt đầu mới cho một nguồn, giữ các danh tính nhiệm vụ đang thực hiện và tiếp tục dần sau khi vấn đề được hiểu. Khởi động lại tất cả công nhân cùng lúc là sự thay thế kém cho việc mở lại tài nguyên có kiểm soát.

Điều chỉnh để có đầu ra thu thập hữu ích

Thiết lập đồng thời quét xung quanh chính sách nguồn, quyền sở hữu tài nguyên thực tế và bản ghi được chấp nhận. Đưa mọi lần thử qua tiếp nhận, phối hợp thời gian làm mát và chỉ tăng tải khi toàn bộ chuỗi lợi ích.

Đối với các quy trình yêu cầu xử lý CAPTCHA được hỗ trợ, sử dụng CapSolver trong giai đoạn được giới hạn riêng và quay lại các quy tắc nguồn sau đó. Một bộ lập lịch có kỷ luật làm cho hệ thống dễ vận hành hơn khi tải và hành vi trang thay đổi.

Câu hỏi thường gặp

Câu hỏi: Giới hạn đồng thời có giống với giới hạn yêu cầu mỗi giây không?

Không. Giới hạn đồng thời kiểm soát các thao tác đang hoạt động. Giới hạn tốc độ yêu cầu kiểm soát số lần bắt đầu theo thời gian, vì vậy bạn có thể cần cả hai điều khiển.

Câu hỏi: Mỗi công nhân có nên xử lý HTTP 429 độc lập không?

Các công nhân chia sẻ cùng một phạm vi bị giới hạn tốc độ nên phối hợp thời gian làm mát. Các lần thử lại độc lập có thể tạo ra đợt xung đột ngay cả khi mỗi công nhân dường như thận trọng.

Câu hỏi: Tôi có thể cải thiện tốc độ quét chậm bằng cách tăng đồng thời không?

Chỉ khi tài nguyên bổ sung cải thiện đầu ra được chấp nhận trong giới hạn cho phép của nguồn. Trước tiên xác định xem điểm nghẽn là thu thập, hiển thị, phân tích hay lưu trữ.

Câu hỏi: Kết quả CAPTCHA có cho phép yêu cầu bỏ qua bộ lập lịch không?

Không. Các quy tắc tốc độ và đồng thời của đích vẫn áp dụng sau khi xử lý thử thách hoàn tất.

Câu hỏi: Điều gì sẽ xảy ra khi kho lưu trữ phía sau bị chậm?

Giảm hoặc tạm dừng thu thập mới thông qua áp lực ngược. Một hàng đợi không giới hạn các trang đã thu thập làm tăng sử dụng tài nguyên và có thể để quan sát lỗi thời trước khi được chấp nhận.