用master-worker模型比對團隊管理

       先講一個場景：「團隊負責人接到一個新項目，他會把項目進行需求細化，功能細化，而後他會分配給不一樣的團隊成員完成」。 在這個場景中，團隊負責人就是master，團隊成員就是worker，至於這樣作的好處，不用說你們也明白，若是團隊負責人一我的幹，估麼着他要麼累死，要麼任務完不成被領導罵死。同理，架構層面master-worker模型的最大做用就是提升處理效率，特別是在多核cpu上，多worker的併發執行更有效的利用了cpu資源，提升了處理效率。在咱們的實際應用中master-worker模型每每會結合生產者-消費者模型使用，由master產生一個隊列，而每一個worker做爲消費者消費這個隊列。

       回到上面的場景中，是個典型的瀑布團隊的作法，由團隊負責人把各個任務強行攤派給每一個團隊成員，他假設給每一個人分配了合適的任務，也假設每一個人能在指定時間內完成任務，這種方式的典型應用就是memcached網絡模型的使用。以下圖：

       這樣看似很公平了吧。但是實際中確定某人由於能力或者外界干擾的緣由沒法按時完成任務，這樣也就影響了總體處理的效率。乾脆咱們採用敏捷團隊的作法，由團隊成員本身選擇任務，根據本身的能力甚至興趣愛好，自我量力的保證本身能夠完成，甚至效率高的成員還能夠多選多作，這種方式的典型應用就是nginx。以下圖：

       再回到上面的場景中，每一個團隊成員怎樣獲得任務呢？我對於memcached網絡模型，當咱們往每一個worker隊列中push任務時就採用某種通知機制告知worker有任務了，快領命幹活。好比memcahed的網絡模型採用每一個worker線程和master線程之間創建一個pipe來進行通知。 好比團隊負責人簡單地按照RR（輪詢）的方式分配任務，做爲一個新手你確定會抱怨，由於沒有考慮到你的實際處理能力。對於nginx的方式，當有新任務時，首先看看你們誰能作，好比nginx就是採用worker爭鎖的方式來競爭任務，master只是負責管理每一個worker。

       以上就是master-worker模型的簡單介紹，至於他的適用場景有不少不少，你們能夠本身擴展。另外從上面的場景模擬中我也想向你們推薦敏捷團隊的管理組織方式。

參考書籍：

《深刻理解計算機系統》  13章-併發編程

《UNIX環境高級編程》    11章-11.3線程標識