一系列的任務能夠並行的無衝突的分配給若干任務處理機處理，我們把這種任務的處理方式成為並行任務處理。

並行任務的處理關鍵在過各個處理機處理的任務處理互相獨立，也就是構建一個無衝突的任務環境。最簡單的無衝突模型，就是能夠明確標識某任務分給了具體的某個任務處理機，該處理機獨享該任務的處理許可權。常見有如下方式的並行：

1、多執行緒並行任務：

基於多執行緒的併發任務設計，把不同的任務分配給作業系統某個程序的多個執行緒去處理，這樣，各個執行緒只負責處理已分配的獨享許可權的任務，從而實現在單臺處理機上的任務併發。 然而多執行緒的這種併發只是一種使用者態的併發，也就是說這種併發只是讓使用者看起來是併發的。因為多個執行緒共享一個程序的cpu處理資源，多個執行緒通過輪流切換暫用cpu空閒時間片的從而獲得類似於並行的處理。實際上對一個程序而言在cpu上仍然是序列處理的。如果每個執行緒處理的任務時本身耗費的cpu資源是巨大的，那麼導致cpu空閒時間片減少，很可能處理的效率尚不如一個序列處理機處理所有的任務，因為執行緒的輪流切換本身就是一個很耗費資源的操作。因此程序中建立執行緒太多的場景不適合採取執行緒併發方式。

2、cpu多核的並行任務：

充分利用多核cpu的的每一個核去構建並行程式，而非像多執行緒那樣去共享一個cpu核的程序資源，這種並行處理是高效的，然而基於這種方案的並行設計很可能比較複雜，工程實施和維護的代價也比較高。

3、並行任務本身的併發：

更高層面的併發設計，他脫離了執行緒和程序層面，他把某個具體的任務和具體的處理機提前建立一個對應的map關係，任務處理機僅僅負責處理和他建立對應關係的任務，而對單個處理機而已僅僅是一個序列的任務處理機，這樣整個併發模型的構建具有很強的靈活性和穩定性，尤其適應企業分佈的環境的任務處理,更為直觀的表示如下。

如上圖，任務分發程式負責建立具體某個任務和處理機的map對應關係，既任務分發程式實現任務的無衝突分配。實際上我們可以大膽假設，如果任務分發程式的分發速度比N太處理機的處理速度慢時，它本身就會變成一個任務處理速度的瓶頸。

任務的分發需要一個類似於"任務分發程式"的東西，它會根據各個機器的實際負載執行情況主動的有預測性的給各個處理機分發任務，這種想法和實施也許是直觀的簡單的易於理解的。

但是作為一個分發程式需要主動的去採集各個處理機的資料，衡量每一個機器的執行情況，然後幾乎在同一個時間分配每個機器不均等的任務量，顯然是比較吃力的，對於處理機而言這種處理方式也是被動的。

假設，每個處理機衡量自己的處理情況，然後在一定的設定條件下主動觸發向分發處理程式請求一定量的處理任務，然後任務處理機接受到請求訊號後響應一個的任務佇列給處理機。（如下圖，處理機在當前任務處理剩下15%時出發任務請求訊號請求分發程式分發任務）我們把這種處理機主動發起任務請求，分發程式響應一個任務佇列的方式，稱之為請求分發模型。

顯然，處理速度快的處理機向任務分發程式傳送任務請求的頻次就會增加，從而達到"能者多勞，適量分配，求總體高效"的目的。

反之，亦然；

極端情況，某臺處理機down掉，就不會向任務分發程式傳送請求任務的訊號。

這種處理模型，可以避免請求分發程式成為排程的瓶頸。適用於分散式系統下多處理器併發任務處理。