aiohttp là gì?

Scrapeless Proxies cung cấp các tuyến mạng mà client aiohttp có thể sử dụng cho các yêu cầu web công khai bất đồng bộ.

aiohttp là một thư viện Python dành cho client và server HTTP bất đồng bộ được xây dựng quanh asyncio. Phía client gửi yêu cầu và cung cấp phản hồi mà không cần mỗi thao tác chờ đợi chiếm một luồng ứng dụng riêng. Thư viện cũng hỗ trợ các trường hợp sử dụng server và WebSocket, nên phạm vi của nó vượt ra ngoài việc tải trang xuống.

Đối với một dịch vụ thu thập, aiohttp hữu ích khi các thao tác mạng độc lập có thể chồng lấp. Lợi ích phụ thuộc vào cách công việc được đưa vào, cách phản hồi được tiêu thụ và liệu phần còn lại của ứng dụng có hợp tác với event loop hay không. Chỉ thêm cú pháp async không tự tạo ra một hệ thống thu thập có giới hạn hoặc có thể kiểm soát được.

asyncio điều phối việc chờ đợi; aiohttp cung cấp HTTP

asyncio cung cấp event loop và sự điều phối tác vụ được dùng bởi các thao tác bất đồng bộ tương thích. Mô hình I/O bất đồng bộ của Python cho phép một coroutine tạm ngừng trong khi chờ đợi và cho phép các công việc sẵn sàng khác tiếp tục. aiohttp cung cấp các thao tác HTTP tham gia vào mô hình đó.

Đồng thời là khái niệm khác với việc giảm thời gian phản hồi của server từ xa. Nếu các yêu cầu độc lập dành thời gian chờ hoạt động mạng, ứng dụng có thể chồng lấp các khoảng chờ đó. Một nguồn chậm vẫn chậm đối với yêu cầu của riêng nó, và dịch vụ vẫn cần các giới hạn tôn trọng năng lực của nguồn và tài nguyên cục bộ.

Công việc nặng về CPU có hành vi khác. Một bộ phân tích cú pháp hoặc bước chuyển đổi đồng bộ chạy trên luồng event-loop có thể làm trễ các tác vụ khác ngay cả khi mọi lời gọi mạng đều bất đồng bộ. Hãy đo xem thời gian được tiêu ở đâu trước khi tăng mức đồng thời của các yêu cầu. Nhiều phản hồi hoạt động hơn có thể làm hàng đợi phân tích lớn hơn mà không cải thiện thông lượng đầu ra được chấp nhận.

Giữ cho ranh giới async của ứng dụng dễ hiểu. Một dịch vụ đã được xây dựng quanh asyncio có thể chia sẻ một vòng đời thống nhất với aiohttp. Một script đồng bộ nhỏ có thể dễ vận hành hơn với client đồng bộ, trừ khi công việc chồng lấp mang lại lợi ích thực sự. Việc chọn thư viện nên theo mô hình thực thi của chương trình hơn là sở thích chung cho async.

ClientSession sở hữu ngữ cảnh yêu cầu có thể tái sử dụng

Một aiohttp ClientSession gom nhóm các kết nối có thể tái sử dụng và trạng thái yêu cầu liên quan, bao gồm cookie. Vòng đời client aiohttp khuyến khích tái sử dụng session thay vì tạo một session mới cho mỗi yêu cầu. Việc tái sử dụng cho phép các yêu cầu liên quan chia sẻ hạ tầng kết nối như dự định.

Tạo session trong vòng đời bất đồng bộ của ứng dụng và đóng nó khi phạm vi đó kết thúc. Một bộ thu thập hữu hạn có thể đặt session quanh một lô (batch), trong khi một dịch vụ có thể quản lý nó qua giai đoạn khởi động và tắt. Để quyền sở hữu session ngầm định khiến khó giải thích thành phần nào phải giải phóng tài nguyên.

Trạng thái chia sẻ cần một ranh giới có chủ đích. Các yêu cầu gắn với những tài khoản hoặc ngữ cảnh cookie khác nhau có thể cần các session riêng biệt ngay cả khi host đích giống nhau. Ngược lại, các yêu cầu đại diện cho một tương tác nguồn liên tục có thể hưởng lợi từ việc giữ nguyên cùng một ngữ cảnh.

Thông tin xác thực không nên lan rộng chỉ vì tiện lợi. Một client mang các header nhạy cảm không nên đồng thời trở thành trình tải xuống dùng chung cho các đích được phát hiện tùy ý. Ghi lại danh tính host đã được chấp thuận và các trường kết quả hữu ích trong khi giữ các giá trị ủy quyền và nội dung cookie ra khỏi phần chẩn đoán thông thường.

Một Response có giai đoạn header và vòng đời body

Một phản hồi HTTP có thể cung cấp status và header trước khi thân (body) của nó được tiêu thụ hoàn toàn. Ứng dụng vẫn cần đọc body, giải mã đúng cách, hoặc stream nó vào một đích. Các thao tác đó có các hệ quả riêng về tài nguyên và tính đúng đắn.

Mô hình biểu diễn HTTP phân biệt status của phản hồi với nội dung đang được truyền. Một status thành công là bằng chứng truyền tải hữu ích, nhưng body vẫn có thể chứa tài liệu không mong đợi hoặc lỗi ở cấp ứng dụng. Việc chấp nhận phải bao gồm danh tính nội dung dự định.

Đọc văn bản cần một quyết định về mã hóa. Giải mã JSON đòi hỏi cả cú pháp hợp lệ lẫn kiểm tra schema phù hợp cho bên tiêu thụ. Không điều nào nên được dùng như lối tắt để khẳng định rằng phản hồi thuộc về thực thể nguồn hoặc khoảng thời gian báo cáo đã yêu cầu.

Hãy chọn một chiến lược tiêu thụ body một cách có chủ đích. Đọc một trang nhỏ vào bộ nhớ có thể đơn giản hóa việc phân tích, trong khi một lượt tải lớn thường cần streaming. Tránh trao một phản hồi đã được tiêu thụ một phần cho thành phần khác vốn giả định nó sở hữu trọn vẹn body. Quyền sở hữu nên rõ ràng tại ranh giới hàm.

Streaming chỉ kiểm soát bộ nhớ khi đích theo kịp

Streaming xử lý body đến theo từng phần thay vì gom toàn bộ body vào bộ nhớ. Điều này có thể giảm bộ đệm cho các tài nguyên lớn, nhưng chỉ hiệu quả khi xử lý ở hạ lưu cũng tôn trọng một luồng công việc có giới hạn.

Một trình tải xuống đọc các phần dữ liệu rồi lập tức thêm chúng vào một danh sách trong bộ nhớ không giới hạn chỉ đơn giản là đã chuyển chỗ bộ đệm. Một luồng đáng tin cậy ghi vào một đích có thể theo kịp hoặc áp dụng backpressure khi đích chậm lại. Bao gồm một chính sách kích thước rõ ràng để một tài nguyên lớn bất ngờ không thể tiêu thụ bộ nhớ lưu trữ vô hạn.

Đầu ra một phần cần danh tính riêng. Ghi một thực thể lớn ở trạng thái chưa hoàn tất cho đến khi các điều kiện truyền và kiểm tra hợp lệ được thỏa mãn. Chỉ khi đó mới cung cấp nó qua tham chiếu đầu ra đã được chấp nhận. Việc một file tồn tại trên đĩa không chứng minh rằng quá trình truyền từ nguồn đã kết thúc hoặc nội dung của nó phù hợp để sử dụng ở hạ lưu.

Giữ lại đủ siêu dữ liệu để giải thích hiện vật. Ngữ cảnh nguồn, loại nội dung, kết quả hoàn thành và một tham chiếu toàn vẹn phù hợp có thể giúp kết nối các byte được lưu với yêu cầu đã tạo ra chúng. Tránh lưu trữ thông tin xác thực hoặc header không cần thiết cùng với tệp chỉ vì các trường đó hiện có.

Giới Hạn Công Việc Đang Chờ Cũng Như Kết Nối Đang Hoạt Động

Giới hạn kết nối kiểm soát việc sử dụng kết nối, trong khi hàng đợi của ứng dụng kiểm soát lượng công việc đang chờ để trở nên hoạt động. Tạo ra một tập hợp tác vụ khổng lồ có thể tiêu tốn bộ nhớ ngay cả khi chỉ cho phép một số lượng nhỏ kết nối chạy đồng thời.

Một thiết kế nhà sản xuất–và–công nhân có thể làm cho ranh giới đó trở nên rõ ràng. Nhà sản xuất đưa các URL đã được chấp thuận vào một hàng đợi có giới hạn, và một nhóm công nhân cố định xử lý chúng. Khi hàng đợi đầy, việc khám phá phải chờ thay vì tạo ra vô hạn tác vụ đang chờ. Bộ ghi đích cần một giới hạn tương thích để các phản hồi đã hoàn thành không bị tích tụ ở nơi khác.

Các giới hạn toàn cục và giới hạn theo nguồn trả lời những câu hỏi khác nhau. Dịch vụ có thể có bộ nhớ cho nhiều host đang hoạt động trong khi một nguồn chỉ cho phép một mẫu yêu cầu hẹp. Mô hình hóa những ranh giới đó tách biệt và xử lý phản hồi giới hạn tần suất như bằng chứng rằng việc cho phép nguồn cần được xem xét, thay vì âm thầm diễn giải chúng như nội dung nguồn trống.

Việc hủy bỏ cũng phải tính đến công việc đã được chấp nhận. Khi tắt, dừng nhận mục mới, quyết định liệu các thao tác đang hoạt động có nên hoàn thành hay không, và ghi lại các mục chưa hoàn thành trước khi giải phóng tài nguyên. Một tiến trình thoát mà không hạch toán hàng đợi của nó thì không thể đáng tin cậy tuyên bố rằng phạm vi nguồn dự định đã được thu thập.

Định Tuyến Proxy Không Thay Đổi Ranh Giới Parser

Một proxy thay đổi tuyến mạng được sử dụng cho một yêu cầu. Scrapeless Proxies có thể cung cấp tuyến đó cho một client aiohttp, trong khi client vẫn sở hữu việc xây dựng yêu cầu, tiêu thụ phản hồi và xác thực ứng dụng. Khả năng của Scrapeless Proxies mô tả các họ proxy sẵn có và vai trò của chúng.

Chọn ngữ cảnh định tuyến dựa trên biểu diễn nguồn mà ứng dụng muốn quan sát. Ngữ cảnh địa lý hoặc sự liên tục phiên có thể ảnh hưởng nội dung. Giữ lại những đầu vào đó cùng với quan sát để một bên tiêu thụ sau này có thể phân biệt thay đổi của nguồn với thay đổi trong ngữ cảnh thu thập.

aiohttp không thực thi các script trang của một website. Một proxy không thể điền vào tài liệu được client render chỉ bằng cách thay đổi tuyến. Kiểm tra phản hồi thực tế trước khi giả định rằng một lựa chọn trống nghĩa là nguồn không có bản ghi; nội dung cần thiết có thể không tồn tại trong biểu diễn HTTP.

Phần thảo luận về cân nhắc đánh đổi client HTTP trong Python so sánh các mô hình thực thi và ranh giới của client. Sử dụng so sánh đó để chọn một thư viện xung quanh ứng dụng bạn đã có. Bao gồm Scrapeless pricing khi việc thu thập sử dụng định tuyến được quản lý, và lập ngân sách theo phạm vi nguồn đã được chấp thuận thay vì tối đa hóa số yêu cầu đồng thời chỉ vì nó.

Các Nhóm Lỗi Giữ Lại Ý Nghĩa Của Dữ Liệu Bị Thiếu

Một bộ thu thập nên phân biệt kết quả mạng, trạng thái bị từ chối, biểu diễn không hợp lệ và kết quả trống được chấp nhận. Những trạng thái này ám chỉ các hành động khác nhau cho bên tiêu thụ, ngay cả khi tất cả đều dẫn đến không có hàng mới nào được chấp nhận.

Ví dụ, một thư mục xuất bản công khai có thể hợp lệ khi không chứa mục nào cho một giai đoạn cụ thể. Kết luận đó đòi hỏi một thư mục được nhận diện và trạng thái trống đã biết của nó. Một trang xin đồng ý hoặc một phản hồi sai định dạng không hỗ trợ cùng kết luận đó, ngay cả khi một parser HTML không trả về phần tử xuất bản nào.

Sử dụng các kết quả rõ ràng giữ lại danh tính nguồn và ngữ cảnh quan sát. Một báo cáo hạ nguồn khi đó có thể cho thấy một nguồn không khả dụng trong khi nguồn khác được chấp nhận nhưng không có mục nào. Việc triệt tiêu sự khác biệt đó khiến phạm vi bao phủ tổng hợp trông tốt hơn so với bằng chứng thực tế.

Timeout phải nằm trong vòng đời đơn vị công việc rộng hơn. Cho ứng dụng đủ thời gian để phân loại kết quả, giải phóng tài nguyên phản hồi và ghi lại công việc chưa hoàn thành. Timeout của một yêu cầu không phải là bản ghi hoàn thành, và một thông báo ngoại lệ không nên được lưu như thể đó là nội dung bài viết nguồn.

Kết luận

aiohttp cung cấp giao tiếp HTTP bất đồng bộ trong mô hình asyncio của Python. Việc thu thập đáng tin cậy phụ thuộc vào quyền sở hữu phiên, xử lý phản hồi đầy đủ, giới hạn chấp nhận và kết quả rõ ràng. Bắt đầu với một vòng đời có thể giải thích mọi URL đã được chấp nhận từ yêu cầu đến đầu ra được chấp nhận. Chỉ tăng mức đồng thời sau khi việc sử dụng bộ nhớ, giới hạn nguồn và xử lý hạ nguồn vẫn dễ hiểu dưới khối lượng công việc đại diện.