Cụm Câu Là Gì?

Trình duyệt thu thập không bỏ rác cung cấp các phiên trình duyệt đám mây cho các công việc thu thập từ web công khai mà một ứng dụng có thể gửi qua quy trình công việc sử dụng cụm câu hạn chế.

TL;DR

Một cụm câu tái sử dụng các luồng công việc. Các tác vụ vào hàng đợi và các luồng sẵn có thực thi chúng mà không cần tạo một luồng mới cho mỗi tác vụ.
Hàng đợi là một phần của thiết kế. Kích thước và quy tắc tiếp nhận của nó xác định việc sử dụng bộ nhớ, độ trễ, và hành vi quá tải.
Kích thước cụm theo hình dạng khối lượng công việc. Việc chờ đợi I/O và thực thi nặng CPU đặt ra các yêu cầu khác nhau cho các luồng.
Một tương lai tách biệt việc gửi đi từ hoàn thành. Người gọi có thể quan sát kết quả, thất bại, hủy bỏ, và ngân sách thời gian thông qua một tay cầm rõ ràng.
Nhiều luồng có thể làm giảm hiệu suất. Cạnh tranh, thay đổi ngữ cảnh, áp lực phía dưới, và khóa chia sẻ có thể xóa bỏ bất kỳ lợi ích nào.

Định Nghĩa Cụm Câu

Một cụm câu là một nhóm luồng công việc có thể tái sử dụng được quản lý thực thi các tác vụ đã gửi. Thay vì tạo và hủy bỏ một luồng cho mỗi đơn vị công việc, ứng dụng đặt công việc vào một hàng đợi hoặc gửi trực tiếp cho một executor. Một luồng sẵn có thực hiện tác vụ, ghi lại kết quả, và trở lại cụm câu.

Mô hình này giảm thiểu quá trình vòng đời luồng và tập trung hóa các giới hạn, lập lịch, tắt nguồn, và xử lý kết quả. Trừu tượng executor cũng quan trọng như các luồng vì người gọi cần một cách xác định để gửi công việc và quan sát việc hoàn thành mà không trực tiếp sở hữu việc tạo luồng. Thuật ngữ chính được sử dụng ở đây theo tài liệu Python concurrent futures, điều này mang lại cho khái niệm một ranh giới kỹ thuật cụ thể thay vì coi đó như một nhãn tiếp thị.

Một định nghĩa hữu ích cũng cho biết khái niệm không làm gì. Một cụm câu không tự động là một tăng tốc song song, một bộ đệm tác vụ không giới hạn, hoặc một sự thay thế cho các kiểm soát tốc độ. Các ràng buộc thời gian thực và hành vi khối lượng công việc quyết định liệu các luồng có thực thi đồng thời hay không và liệu các hệ thống phía dưới có thể chấp nhận đầu ra của chúng hay không. Giữ ranh giới đó rõ ràng ngăn các biểu đồ kiến trúc giao cho một thành phần mà thuộc về một lớp khác.

Cách Một Cụm Câu Xử Lý Công Việc

Một cụm chuyển đổi việc đến không đều thành việc thực thi luồng có kiểm soát. Việc gửi đi, hàng đợi, phân bổ, hoàn thành, và tắt nguồn đều cần một chính sách rõ ràng.

Người gọi đóng gói công việc như một đối tượng callable hoặc tác vụ với dữ liệu mà nó cần.
Executor chỉ chấp nhận tác vụ nếu chính sách tiếp nhận và trạng thái vòng đời cho phép.
Một hàng đợi giữ công việc đã chấp nhận cho đến khi một luồng trở nên sẵn có, trừ khi thiết kế gửi công việc trực tiếp đến một luồng rỗi.
Luồng thực thi tác vụ và lưu trữ hoặc là một kết quả hoặc một ngoại lệ trong tay cầm hoàn thành liên kết.
Executor trả luồng về lại cụm, công bố kết quả, và cuối cùng thực hiện một quy trình tắt nguồn có trật tự.

Các cụm cố định giới hạn luồng hoạt động, thiết kế được lưu trữ thay đổi số lượng luồng, và thiết kế lấy cắp công việc cho phép các luồng rỗi lấy tác vụ từ các hàng đợi lân cận. Các tên khác nhau trong các thời gian thực, nhưng mọi triển khai vẫn đưa ra các lựa chọn về hàng đợi, việc tạo luồng, từ chối, và vòng đời. Hành vi này được ghi chép đầy đủ hơn trong tài liệu Java ThreadPoolExecutor. Nguồn rất hữu ích vì nó mô tả thực thi hoặc mô hình dữ liệu thực tế thay vì dựa vào một phép ẩn dụ lỏng lẻo.

Các Thành Phần Cụm Câu

Thành Phần	Trách Nhiệm	Câu hỏi thiết kế
Executor	Chấp nhận công việc và quản lý vòng đời	Chuyện gì xảy ra sau khi việc tắt nguồn bắt đầu?
Hàng đợi tác vụ	Đệm công việc đã chấp nhận	Liệu dung lượng có hữu hạn và có thể quan sát được không?
Luồng	Thực thi một tác vụ tại một thời điểm	Liệu một tác vụ có thể bị chặn vô thời hạn không?
Tương lai	Đại diện cho việc hoàn thành hoặc thất bại	Hủy bỏ được phát tán như thế nào?
Chính sách từ chối	Xử lý công việc vượt quá khả năng	Người gọi có nên chặn, gộp lại, hay chuyển hướng không?

Coi hàng đợi như một chi tiết triển khai là nguồn gốc phổ biến của quá tải. Một hàng đợi không giới hạn có thể giữ số lượng luồng hoạt động ổn định trong khi độ trễ và bộ nhớ tăng mà không có trần hiện hữu. Một hàng đợi có giới hạn làm cho áp lực rõ ràng và buộc hệ thống phải chọn một phản hồi.

Vị trí của C Pool Luồng

Chặn khách hàng mạng

Công nhân có thể chờ đợi socket chồng chéo khi thư viện khách hàng phơi bày một giao diện đồng bộ và khối lượng công việc vẫn được giới hạn.

Các hoạt động tệp và lưu trữ

Một hồ bơi có thể cách ly công việc tệp chặn khỏi vòng lặp sự kiện hoặc luồng yêu cầu trong khi bảo toàn một tay cầm hoàn thành rõ ràng.

Công việc nền tảng ngắn

Công nhân tái sử dụng xử lý các công việc nhỏ thường xuyên mà không cần dành một luồng dài hạn cho mỗi nhiệm vụ.

Ranh giới bộ chuyển đổi

Một hồ bơi luồng có thể chứa một thư viện bên thứ ba chặn đằng sau một hợp đồng bất đồng bộ hẹp hoặc cấp dịch vụ.

Các trường hợp sử dụng này chia sẻ một quy tắc lựa chọn: chọn một hồ bơi luồng vì mô hình thực thi và sở hữu của nó phù hợp với khối lượng công việc, không phải vì cái tên nghe có vẻ nâng cao hơn. Các dịch vụ chạy dài, các nhiệm vụ chờ đợi vào các nhiệm vụ khác trong cùng một hồ bơi nhỏ, và mã Python bị giới hạn CPU cao có thể cần các cấu trúc khác nhau. Hồ bơi nên phù hợp với hành vi chặn thay vì cú pháp bề mặt.

Kích thước và Chính sách Hàng đợi

Kích thước hồ bơi cân bằng sự chồng chéo hữu ích với sự tranh chấp và chi phí tài nguyên. Không có số lượng công nhân phổ quát nào vì các nhiệm vụ khác nhau về thời gian CPU, thời gian chờ, bộ nhớ, mô tả tệp, và tác động hạ nguồn.

Đo lường dịch vụ và thời gian chờ. Một nhiệm vụ chờ đợi phần lớn thời gian của nó có thể chấp nhận nhiều công nhân hơn một nhiệm vụ bão hòa CPU.
Giới hạn hàng đợi. Sức chứa hữu hạn chuyển quá tải thành một quyết định chính sách trước khi bộ nhớ trở thành giới hạn duy nhất.
Tránh chờ đợi lồng ghép. Một công nhân chờ đợi một nhiệm vụ khác được nộp vào cùng một hồ bơi đã cạn kiệt có thể dẫn đến deadlock.
Đặt tên cho các luồng công nhân. Tên hữu ích kết nối các dấu vết ngăn xếp và số liệu với hồ bơi sở hữu và khối lượng công việc.
Xác định tắt. Chọn xem công việc được xếp hàng có hoàn thành, bị hủy bỏ, hoặc được giao cho một hệ thống bền bỉ khác không.

Tinh chỉnh với lưu lượng đại diện, sau đó xem tuổi hàng đợi thay vì chỉ số lượng công nhân. Tuổi hàng đợi tăng có nghĩa là công việc được chấp nhận đang chờ lâu hơn ngay cả khi thông lượng có vẻ ổn định. Tín hiệu đó thường đến trước khi người sử dụng gặp thời gian chờ hoặc cảnh báo bộ nhớ. Một tham chiếu chính liên quan là Hướng dẫn kiến trúc hồ bơi luồng Windows, cái này làm rõ các giả định lưu trữ, thực thi hoặc khả năng tương tác phía sau sự lựa chọn đó.

Các Chế độ Thất bại Hồ bơi Luồng

Các hồ bơi luồng thất bại một cách yên lặng khi giới hạn của chúng chỉ tồn tại trên các công nhân hoạt động. Các nhiệm vụ chờ đợi, kết nối hạ nguồn, và bộ nhớ thuộc nhiệm vụ có thể tiếp tục tăng trưởng bên ngoài con số thấy được đó.

Nộp không giới hạn. Một nhà sản xuất nhanh có thể tạo ra một hàng đợi dài mà công việc cũ nhất của nó đã lỗi thời trước khi bắt đầu.
Phụ thuộc nội bộ hồ bơi. Các công nhân chờ đợi các tương lai từ cùng một hồ bơi đã cạn kiệt có thể ngăn nhiệm vụ cần thiết chạy.
Chặn ẩn. Một nhiệm vụ được mô tả là nhỏ có thể chờ một DNS, lưu trữ, một khóa, hoặc một hạn ngạch từ xa trong phần lớn thời gian của nó.
Lạm dụng khách hàng chia sẻ. Một đối tượng thư viện có thể không an toàn cho việc truy cập đồng thời ngay cả khi chính hồ bơi là đúng.
Tắt bất ngờ. Dừng công nhân mà không có chính sách hoàn thành có thể để lại các ghi chép một phần, hợp đồng thuê, hoặc phiên bên ngoài vẫn hoạt động.

Một thất bại nên được truy vết đến lớp có trách nhiệm nhỏ nhất. Khi độ trễ tăng, kiểm tra tuổi hàng đợi và các ngăn xếp chặn; khi CPU tăng, kiểm tra chi phí tác vụ và sự tranh chấp khóa; khi một phụ thuộc chậm lại, giảm việc nhận đầu vào trước khi mở rộng hồ bơi. Thực hành này tạo ra một hành động sửa chữa hữu ích thay vì một chỉ dẫn mơ hồ để thêm sức chứa.

Các Hồ bơi Luồng trong Bộ sưu tập Web

Một hồ bơi bộ sưu tập web nên nộp các công việc nhỏ, độc lập mà đầu ra của chúng mang lại URL nguồn và định danh công việc. Hồ bơi quản lý sự chồng chéo cục bộ; nó không cấp phép để quá tải một máy chủ hoặc bỏ qua hợp đồng dịch vụ của một API.

Đối với đầu vào web công cộng, lớp tiếp nhận nên ghi lại URL được yêu cầu, URL cuối cùng, thời gian thu thập, chế độ phản hồi, và một kiểm tra nội dung trước khi xử lý hạ nguồn bắt đầu. Trả về một kết quả có cấu trúc cho thành công, thất bại xác thực, hủy bỏ, hoặc tiêu điểm thời gian thay vì một chuỗi trần trụi. Sự bàn giao đó cung cấp cho các nhà phân tích một bản ghi nguồn có thể tái tạo và giữ hành vi thu thập tách biệt với diễn giải.

Scrapeless xử lý bước bộ sưu tập web quản lý được mô tả trong câu mở đầu. Ứng dụng vẫn sở hữu sự chấp thuận nguồn, định nghĩa trường, giới hạn khối lượng công việc, giữ lại, kiểm soát quyền truy cập, và xác thực. Trình điều khiển sở hữu các công nhân cục bộ, trong khi ứng dụng sở hữu sự công bằng theo mỗi máy chủ, phạm vi thu thập, giới hạn từ xa, và xem liệu công việc được xếp hàng có vẫn có giá trị hay không. Một hợp đồng rõ ràng giữa những lớp đó làm cho các thay đổi sau này dễ kiểm tra hơn.

Dòng chảy nên bảo tồn cả bằng chứng thô và đầu ra đã được tuyển chọn khi trường hợp sử dụng cần tính khả thi kiểm toán. Tài liệu thô hỗ trợ việc xử lý lại sau khi một bộ phân tích hoặc sơ đồ thay đổi; các bảng đã được tuyển chọn hỗ trợ phân tích ổn định. Lưu trữ nội dung đã thu thập chỉ sau khi kiểm tra rằng trang cuối cùng là trang dự định và rằng các trường cần thiết đã có mặt. Hai đại diện trả lời các câu hỏi vận hành khác nhau và không nên bị nhầm lẫn với các bản sao.

Danh sách kiểm tra đánh giá Thread Pool

Sử dụng các câu hỏi sau trong quá trình xem xét thiết kế. Một câu trả lời bằng văn bản có giá trị hơn một mặc định ước tính vì nó phơi bày nơi mà các đội không đồng ý về một thread pool.

Dung lượng hàng đợi tối đa và tuổi tối đa của hàng đợi là gì?
Một tác vụ có thể chờ đợi một tác vụ khác trong cùng một pool không?
Những thao tác nào bị chặn, và cái gì giải phóng những chờ đợi đó?
Kết quả, ngoại lệ và hủy bỏ được đại diện như thế nào?
Có tài liệu nào về các khách hàng và bộ phân tích chia sẻ là an toàn với thread không?
Những giới hạn dịch vụ từ xa nào áp dụng một cách độc lập với số lượng công nhân?
Những chỉ số nào phơi bày tình trạng bão hòa trước khi xảy ra lỗi đối mặt với người dùng?
Quá trình tắt máy xử lý công việc đã xếp hàng và công việc đang hoạt động như thế nào?

Một thread pool đã sẵn sàng cho sản xuất khi hàng đợi, hành vi từ chối, quyền sở hữu tác vụ, giám sát và con đường tắt đều được cân nhắc kỹ lưỡng như số lượng công nhân của nó. Hãy xem lại các câu trả lời sau khi hình dạng tải công việc, khối lượng dữ liệu, giới hạn dịch vụ hoặc mong đợi của người tiêu dùng thay đổi. Một kiến trúc đã hợp lý cho một lô hàng khám phá có thể không phù hợp cho một con đường sản xuất liên tục.

Kết luận

Một thread pool là một mẫu quản lý công nhân tái sử dụng, không phải là một công cụ điều khiển tốc độ kỳ diệu. Nó hữu ích khi nhiều tác vụ độc lập có thể chia sẻ một số lượng luồng giới hạn và khi ứng dụng cần một nơi để quản lý việc nộp, kết quả và tắt máy. Thiết kế tốt điều chỉnh kích thước công nhân từ hành vi bị chặn quan sát, giới hạn công việc đã xếp hàng, ngăn chặn tình trạng chết bên trong pool, và phối hợp đồng thời cục bộ với khả năng từ xa.

Sẵn sàng xây dựng một Bounded Browser Worker Pool?

Kết hợp các phiên trình duyệt được quản lý với dung lượng hàng đợi rõ ràng, quyền sở hữu công nhân và xác thực kết quả.

Đăng ký hôm nay và nhận $5 tín dụng miễn phí — không cần thẻ tín dụng.

Yêu cầu tín dụng $5 của bạn →

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

Vấn đề nào mà một thread pool giải quyết?

Một thread pool tái sử dụng một tập hợp các luồng công nhân được quản lý cho nhiều tác vụ đã nộp. Nó giảm việc tạo luồng lặp lại, tập trung hóa kiểm soát vòng đời, và cho phép ứng dụng giới hạn công việc đang hoạt động. Chính sách hàng đợi và từ chối là thiết yếu vì pool cũng phải xác định điều gì xảy ra khi các tác vụ đến nhanh hơn các công nhân hoàn thành.

Một pool nên có bao nhiêu luồng?

Kích thước chính xác phụ thuộc vào thời gian CPU đã đo, thời gian chờ, bộ nhớ, mô tả tệp, khóa chia sẻ và khả năng phía dưới. Công việc nặng nề CPU thường cần một mối quan hệ chặt chẽ hơn với tài nguyên thực thi có sẵn. Công việc nặng nề I/O có thể hưởng lợi từ sự chồng chéo nhiều hơn, nhưng chỉ trong khi hàng đợi và các hệ thống từ xa vẫn khỏe mạnh.

Liệu một thread pool có thể bị chết không?

Có. Một trường hợp phổ biến xảy ra khi mỗi công nhân chờ đợi một tác vụ khác đã được nộp vào cùng một pool nhưng không thể bắt đầu vì không có công nhân nào miễn phí. Các khóa chia sẻ và thứ tự thu nhận không nhất quán có thể tạo ra các tình trạng chết khác. Cấu trúc phụ thuộc phải được xem xét riêng biệt với kích thước pool.

Một thread pool có giống như một connection pool không?

Không. Một thread pool quản lý các công nhân thực thi, trong khi một connection pool quản lý các kết nối tái sử dụng đến cơ sở dữ liệu, dịch vụ hoặc điểm cuối mạng. Một tác vụ có thể cần một kết nối trong khi nó thực hiện, vì vậy hai pool tương tác. Các khả năng của chúng nên được phối hợp để tránh công nhân chờ đợi vô thời hạn cho các kết nối.

Có nên sử dụng một thread pool cho việc thu thập trình duyệt không?

Một thread pool có thể phù hợp với một trình duyệt đồng bộ hoặc khách hàng HTTP khi các công việc là độc lập và giới hạn. Một khách hàng bất đồng bộ có thể sử dụng ít luồng hơn và thay vào đó là một vòng lặp sự kiện. Trong cả hai thiết kế, số lượng công nhân cục bộ phải tách biệt với chính sách theo từng máy chủ, giới hạn phiên, xác thực, và khả năng xử lý phía dưới.