Đồng thời vs Bình song: Sự khác biệt và Trường hợp sử dụng

Đồng thời vs Bình song

Trình duyệt Thu thập dữ liệu không bị rác cung cấp phiên duyệt được quản lý cho các trang công cộng render bằng JavaScript, trong khi ứng dụng của bạn kiểm soát số lượng công việc nó lập lịch và số lượng có thể thực thi cùng một lúc.

Tóm lại

  • Đồng thời tổ chức công việc chồng chéo. Các tác vụ có thể tiến triển trong cùng một khoảng thời gian ngay cả khi một bộ xử lý xen kẽ chúng.
  • Bình song thực hiện công việc đồng thời. Nhiều lõi, bộ xử lý hoặc công nhân thực hiện tính toán cùng một lúc.
  • Chờ I/O thường được hưởng lợi từ đồng thời. Một bộ lập lịch có thể tiến bộ một tác vụ khác trong khi một thao tác mạng hoặc lưu trữ đang chờ.
  • Công việc nặng CPU cần tính toán song song thực sự. Nhiều tác vụ được lập lịch không tự tạo ra nhiều năng lực toán học.
  • Cả hai mô hình đều cần giới hạn và quyền sở hữu. Hàng đợi, hủy bỏ, trạng thái chia sẻ và giới hạn dịch vụ xác định liệu thông lượng có giữ ổn định hay không.

Định nghĩa Đồng thời và Bình song

Đồng thời là một cách để cấu trúc nhiều tác vụ có thời gian tồn tại chồng chéo, trong khi bình song có nghĩa là hai hoặc nhiều tính toán đang được thực hiện cùng một lúc. Một chương trình đồng thời có thể chạy trên một lõi bằng cách xen kẽ các tác vụ. Một chương trình bình song yêu cầu tài nguyên thực thi có thể hoạt động đồng thời.

Sự phân biệt liên quan đến cấu trúc so với thực thi. Đồng thời phân bổ một khối lượng công việc thành các hoạt động tiến triển độc lập và xác định cách chúng phối hợp. Bình song ánh xạ công việc lên nhiều đơn vị thực thi để giảm thời gian tính toán đã trôi qua hoặc tăng thông lượng. Thuật ngữ chính được sử dụng ở đây theo giải thích của Go về đồng thời và bình song, cái mà cung cấp một ranh giới kỹ thuật cụ thể cho khái niệm này thay vì coi nó như một nhãn tiếp thị.

Một so sánh hữu ích đặt câu hỏi về công việc mà mỗi mô hình tổ chức, tài nguyên nào có thể thực thi tại cùng một thời điểm, và nơi chờ đợi, phối hợp, hoặc quyết định sơ đồ xảy ra. Đồng thời không phải là đồng nghĩa với các luồng, và bình song không được đảm bảo mỗi khi một chương trình tạo ra nhiều công nhân. Vòng sự kiện, quy trình, bộ tăng tốc, lệnh vector, và các nút phân phối có thể tham gia vào các tổ hợp khác nhau. Giữ cho ranh giới đó rõ ràng ngăn cản các sơ đồ kiến trúc gán các đảm bảo cho một thành phần thuộc về lớp khác.

Cách Chồng chéo Trở thành Công việc Đồng thời

Một khối lượng công việc di chuyển từ yêu cầu đến kết quả qua lập lịch, chờ đợi, thực thi, và phối hợp. Chương trình giống nhau có thể đồng thời ở mức tác vụ và bình song chỉ trong các giai đoạn được chọn.

  1. Ứng dụng chia nhỏ khối lượng công việc thành các tác vụ với các đầu vào, đầu ra và quy tắc hủy bỏ rõ ràng.
  2. Một bộ lập lịch quyết định tác vụ nào sẵn sàng nhận thời gian trên một luồng, quy trình, vòng sự kiện, hoặc công nhân từ xa.
  3. Khi một tác vụ chờ đợi I/O, một thiết kế đồng thời cho phép một tác vụ sẵn sàng khác tiến lên thay vì để tài nguyên thực thi không được sử dụng.
  4. Khi nhiều tài nguyên thực thi chạy các tác vụ sẵn sàng cùng một lúc, phần đó của khối lượng công việc là bình song.
  5. Hệ thống kết hợp kết quả, truyền đạt lỗi, và áp dụng các quy tắc sắp xếp hoặc nhất quán trước khi công bố đầu ra cuối cùng.

Một vòng sự kiện có thể phối hợp hàng nghìn thao tác đang chờ mà không làm cho các chỉ thị CPU của chúng đồng thời. Một hồ bơi quá trình có thể thực hiện công việc nặng CPU độc lập trên các lõi, nhưng phân phối và phối hợp vẫn làm tăng chi phí. Một dịch vụ lai thường sử dụng I/O không đồng bộ xung quanh một hồ bơi giới hạn cho các chuyển đổi nặng tính toán. Hành vi này được tài liệu hóa đầy đủ hơn trong tài liệu nhiệm vụ Python asyncio. Nguồn là hữu ích vì nó mô tả mô hình thực thi hoặc dữ liệu thực tế thay vì dựa vào một phép ẩn dụ lỏng lẻo.

Đồng thời vs Bình song trong cái nhìn thoáng qua

Kích thướcĐồng thờiBình song
Mục tiêu chínhPhối hợp các hoạt động chồng chéoThực hiện công việc đồng thời
Có thể một lõiCó, thông qua xen kẽKhông cho thực thi CPU đồng thời
Thế mạnh điển hìnhChờ I/O và dịch vụ phản hồiCác tính toán nặng CPU độc lập
Chi phí chungPhối hợp, hủy bỏ, lỗi trạng thái chia sẻPhân chia, chuyển giao, đồng bộ hóa
Chứng minh để đo lườngThời gian sống của các tác vụ chồng chéoSử dụng tài nguyên đồng thời

Bảng phân tách mục tiêu khỏi cơ chế. Các luồng có thể hỗ trợ một trong hai cột, trong khi các tiến trình thường hỗ trợ cả hai, và các hàm bất đồng bộ thường nhấn mạnh đến đồng thời. Nhãn đúng theo sau quá trình thực thi quan sát thay vì tên API được sử dụng để khởi chạy công việc.

Khối lượng công việc phù hợp với mỗi mô hình

Nhiều yêu cầu mạng

Tính đồng thời giữ sự tiến bộ khi ổ cắm chờ, với điều kiện là khách hàng tôn trọng giới hạn per-host và giới hạn bộ nhớ.

Máy chủ tương tác

Xử lý tác vụ đồng thời ngăn không cho một yêu cầu chậm chặn các khách hàng không liên quan và giữ việc hủy bỏ nằm trong phạm vi của người gọi.

Biến đổi hình ảnh hoặc số

Các công nhân song song có thể chia nhỏ các đơn vị tính toán nặng độc lập khi chi phí chuyển giao và thiết lập nhỏ hơn thời gian tính toán đã tiết kiệm.

Các đường ống dữ liệu web

Thu thập thường nặng về I/O, trong khi phân tích, nén, kết hợp và chuẩn bị mô hình có thể xứng đáng với một giai đoạn song song riêng biệt.

Những trường hợp sử dụng này chia sẻ một quy tắc lựa chọn: chọn tính đồng thời và song song 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 chỉ vì tên nghe có vẻ tiên tiến hơn. Khối lượng công việc nhỏ có thể nhanh nhất với một vòng lặp tuần tự đơn giản vì việc điều phối có một chi phí. Đo thời gian hàng đợi, thời gian dịch vụ và độ trễ từ đầu đến cuối trước khi thêm công nhân.

Chọn mô hình đồng thời và song song

Lựa chọn bắt đầu với thời gian chờ chiếm ưu thế. Công việc gắn với mạng, công việc gắn với lưu trữ, áp lực bộ nhớ và sự bão hòa CPU yêu cầu các phản ứng khác nhau ngay cả khi triệu chứng mà người dùng thấy là thời gian hoàn thành chậm tương tự.

  • Phân loại điểm nghẽn. Ghi lại thời gian mà các tác vụ chờ đợi, chạy, chuyển dữ liệu và điều phối.
  • Giới hạn việc nhận. Giữ cho hàng đợi có giới hạn để một cú sốc lưu lượng không thể chuyển đổi áp lực tạm thời thành cạn kiệt bộ nhớ toàn bộ quy trình.
  • Giảm thiểu sự biến đổi chia sẻ. Đầu vào bất biến và đầu ra tách biệt giảm thiểu các cuộc đua và giúp dễ dàng phát lại các tác vụ lỗi như là công việc mới.
  • Bảo tồn việc hủy bỏ. Một người gọi không còn cần kết quả nên có thể dừng công việc trong hàng đợi và giải phóng khả năng ở hạ nguồn.
  • Kiểm tra toàn bộ con đường. Bao gồm tuần tự hóa, khởi động, thu thập, phân tích, và lắp ráp kết quả thay vì chỉ đo thời gian một hàm.

Đối với các chương trình Python gắn với CPU, quy trình hoặc các bộ thông dịch tách biệt có thể cung cấp thực thi đa lõi thực sự nơi các luồng thông thường có thể không. Đối với các chương trình nặng về mạng, các tác vụ hoặc luồng bất đồng bộ có thể cải thiện sử dụng mà không phải biến mọi bước thành tính toán song song. Một tài liệu tham khảo chính liên quan là Tài liệu đa xử lý Python, điều này làm rõ các giả định về lưu trữ, thực thi, hoặc khả năng tương tác đứng sau sự lựa chọn đó.

Những sai lầm làm sai lệch sự so sánh

Các lỗi tốn kém nhất đến từ việc coi số lượng công nhân như một hệ thống kiểm soát hiệu suất phổ quát. Mỗi tác vụ bổ sung tiêu thụ các mô tả, bộ nhớ, không gian hàng đợi, khả năng từ xa và sự chú ý trong quá trình xử lý lỗi.

  • Gọi tất cả tính đồng thời chồng chéo. Công việc xen kẽ trên một tài nguyên thực thi là đồng thời nhưng không phải là song song.
  • Thêm công nhân trước khi đo lường. Nhiều công nhân hơn có thể khuếch đại sự tranh chấp hoặc làm chậm ở hạ nguồn mà không cải thiện thời gian hoàn thành.
  • Chặn bên trong một vòng lặp sự kiện. Một hoạt động đồng bộ dài có thể làm đóng băng các coroutine không liên quan chia sẻ cùng một vòng lặp.
  • Chia sẻ trạng thái có thể thay đổi một cách tùy tiện. Các khóa bảo vệ các bất biến chỉ khi mỗi truy cập tuân theo cùng một giao thức sở hữu.
  • Bỏ qua thứ tự kết quả. Thứ tự hoàn thành, thứ tự đầu vào và thứ tự kinh doanh là các hợp đồng riêng biệt phải được xác định.

Một sự thất bại nên được truy vết đến lớp chịu trách nhiệm nhỏ nhất. Nếu CPU không hoạt động trong khi các yêu cầu chờ đợi, hãy kiểm tra tính đồng thời I/O; nếu CPU bị bão hòa, hãy kiểm tra tính toán và phân vùng; nếu hàng đợi phát triển trong khi độ trễ hạ nguồn tăng, hãy giảm việc nhận vào hoặc thêm áp lực ngược. Thực hành này tạo ra một hành động khắc phục hữu ích thay vì một chỉ dẫn mơ hồ để thêm nhiều khả năng hơn.

Tính đồng thời trong một đường ống dữ liệu web công khai

Một đường ống web công khai thường kết hợp cả hai mô hình. Việc phát hiện URL và thu thập trang chồng chéo vì phần lớn thời gian của chúng là chờ đợi mạng. Phân tích và chuẩn hóa có thể chạy song song khi các bản ghi độc lập. Các cam kết lưu trữ có thể trở lại được tuần tự hóa để bảo vệ thứ tự hoặc các đảm bảo giao dịch.

Đối với đầu vào web công khai, lớp thu thập 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à kiểm tra nội dung trước khi việc xử lý ở hạ nguồn bắt đầu. Mỗi bản ghi được thu thập nên mang theo một định danh ổn định để thứ tự hoàn thành không trở thành thứ tự dữ liệu một cách âm thầm. Sự chuyể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ữ cho hành vi thu thập tách biệt với việc giải thích.

Scrapeless xử lý bước thu thập web được quản lý được mô tả trong câu mở đầu. Ứng dụng vẫn sở hữu phê duyệt nguồn, định nghĩa trường, giới hạn khối lượng công việc, lưu giữ, kiểm soát truy cập và xác thực. Dịch vụ thu thập có thể cung cấp nội dung trang được hiển thị, nhưng lớp điều phối quyết định tỷ lệ tiếp nhận, số phiên hoạt động tối đa, công bằng theo từng máy chủ, ngân sách thời gian và việc hủy bỏ. Một hợp đồng rõ ràng giữa các lớp đó làm cho các thay đổi sau này dễ thử nghiệm hơn.

Đường ống nên bảo tồn cả chứng cứ thô và đầu ra đã được biên tập khi trường hợp sử dụng cần tính khả thi kiểm toán. Nguyên liệu thô hỗ trợ việc xử lý lại sau khi một bộ phân tích hoặc schema thay đổi; các bảng đã được biên tập hỗ trợ phân tích ổn định. Một hàng đợi có giới hạn giữa thu thập và chuyển đổi hấp thụ biến động ngắn trong khi báo hiệu quá tải kéo dài trước khi tăng trưởng bộ nhớ trở thành cơ chế điều khiển. Hai đại diện này trả lời những câu hỏi khác nhau về hoạt động và không nên bị nhầm lẫn là bản sao.

Danh sách kiểm tra đánh giá kiến trúc

Sử dụng các câu hỏi sau trong quá trình đánh giá 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 giả định vì nó phơi bày nơi các nhóm không đồng ý về độ đồng thời và sự song song.

  • Những nhiệm vụ nào có thể chồng chéo mà không vi phạm quy tắc thứ tự hoặc tính nhất quán?
  • Giai đoạn nào đang chờ I/O, và giai đoạn nào đang tiêu thụ CPU?
  • Số lượng tối đa của các công việc đang chờ và đang hoạt động tại mỗi ranh giới là bao nhiêu?
  • Làm thế nào để hủy bỏ di chuyển từ người gọi đến công việc đang chờ và các hoạt động phía dưới?
  • Dữ liệu nào được chia sẻ, và thành phần nào sở hữu mọi giá trị có thể thay đổi?
  • Khối lượng công việc có yêu cầu thứ tự đầu vào, thứ tự hoàn thành, hay không có thứ tự nào?
  • Các chỉ số nào chứng minh sự chồng chéo hữu ích hoặc thực hiện đồng thời?
  • Chuyện gì xảy ra khi một dịch vụ phía dưới trở nên chậm hơn nhà sản xuất?

Thiết kế sẵn sàng khi độ đồng thời được giới hạn, các giai đoạn song song có đủ công việc độc lập để bù đắp chi phí phối hợp, và quá tải tạo ra một phản ứng có chủ đích. Xem lại các câu trả lời sau khi hình dạng khối lượng công việc, khối lượng dữ liệu, giới hạn dịch vụ, hoặc kỳ vọng của người tiêu dùng thay đổi. Một kiến trúc mà hợp lý cho một lô thí nghiệm có thể không phù hợp cho một con đường sản xuất liên tục.

Kết luận

Độ đồng thời và sự song song giải quyết các vấn đề liên quan nhưng khác nhau. Độ đồng thời cấu trúc các hoạt động chồng chéo và giữ cho các hệ thống phản hồi trong thời gian chờ. Sự song song sử dụng thực hiện đồng thời để tăng tốc công việc phù hợp. Nhiều quy trình sản xuất cần cả hai, được kết nối bởi hàng đợi có giới hạn và quyền sở hữu rõ ràng. Quyết định thực tế đến từ việc đo lường thời gian tiêu tốn và phân bổ mỗi giai đoạn mô hình thực hiện phù hợp với cổ chai thực tế của nó.

Sẵn sàng để xây dựng một quy trình thu thập có kiểm soát?

Kết nối đầu vào công khai đã được kết xuất với một lớp phối hợp có giới hạn nhiệm vụ rõ ràng, kiểm tra bằng chứng và chuyền tay xuống phía dưới.

Đă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 $5 của bạn →

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

Độ đồng thời có thể tồn tại mà không có sự song song không?

Có. Một bộ xử lý đơn lẻ có thể đan xen nhiều nhiệm vụ để thời gian sống của chúng chồng chéo ngay cả khi chỉ có một nhiệm vụ thực hiện các lệnh trong một khoảnh khắc nhất định. Các vòng lặp sự kiện thường sử dụng mô hình này cho công việc nặng về I/O. Ứng dụng có được khả năng phản hồi và sử dụng tốt hơn thời gian chờ mà không có thực hiện đồng thời trên CPU.

Sự song song có thể tồn tại mà không có thiết kế đồng thời không?

Có theo một nghĩa hạn chế. Một môi trường thực thi hoặc bộ xử lý có thể song song hóa một phép toán đơn nội bộ ngay cả khi ứng dụng trình bày một giao diện tuần tự đơn giản. Các lệnh vector và các toán tử cơ sở dữ liệu song song là các ví dụ. Độ đồng thời ở cấp ứng dụng vẫn hữu ích khi nhiều hoạt động độc lập phải được phối hợp theo thời gian.

Các luồng có đồng thời hay song song không?

Các luồng có thể hỗ trợ độ đồng thời, sự song song, hoặc cả hai. Câu trả lời phụ thuộc vào môi trường thực thi, bộ xử lý, khối lượng công việc, và lập lịch. Nhiều luồng có thể đan xen trên một lõi, hoặc các luồng riêng biệt có thể thực hiện trên các lõi khác nhau đồng thời. Chỉ tạo ra các luồng không chứng minh rằng công việc song song hữu ích đã xảy ra.

Mô hình nào tốt hơn cho các yêu cầu web?

Độ đồng thời thường là công cụ đầu tiên cho các yêu cầu web vì các hoạt động mạng tiêu tốn nhiều thời gian chờ. Thiết kế nên vẫn được giới hạn bởi chính sách per-host, bộ nhớ, mô tả tệp, và khả năng xử lý phía dưới. Các công nhân CPU song song có thể vẫn giúp sau này với phân tích, nén, hoặc chuyển đổi phân tích.

Một nhóm nên thử nghiệm sự thay đổi độ đồng thời như thế nào?

Thử nghiệm với một khối lượng công việc đại diện và ghi lại thông lượng, thời gian hàng đợi, thời gian dịch vụ, các loại lỗi, bộ nhớ, sử dụng CPU, và độ trễ phía dưới. So sánh toàn bộ quy trình với cùng một đầu vào. Một sự thay đổi chỉ hữu ích nếu nó cải thiện chỉ số mục tiêu mà không vi phạm thứ tự, công bằng, hoặc giới hạn tài nguyên.

Tài liệu tham khảo