一、概述
二、計算流程
mr計算框架發展到1.0.3左右，計算框架沒有發展大的變化。在《hadoop the definitive guide》中有張經典的圖可以說明問題，如圖1所示。
圖1圖1大致說明了我們計算的任務流程，不過並沒有深入內部講述**的一些細節。所有細節也非常繁細，我整理出一幅大致的資料流程圖互動圖來說明問題（此圖主要我理清楚思路，可能有所欠缺及不完善，主要強調任務資料流轉）。如圖2:所示：
圖2圖2簡單說明：
大致分為上下兩個部分：
上部分主要是jobtracker的一些內部資料結構。在jobtracker主要是jobinprogress的初始化，初始化的時候會確定每個jobinprogress會包含兩個jobsetup、jobcleanup、一些map、及一些reduce任務。這些會合理地分配到tasktracker機器上面。上圖主要給出的部分就是：setup及cleanup與map\reduce的排程是分開的。反饋部分圖中沒有涉及，此處就省去了。
下部分主要是tasktracker部分：
1、action有兩部分程式處理：tasktracker自己就能處理的是killjobaction及killtaskaction，這些action最後會把child程序乾掉（如果有child程序）。
交給child處理的是launchtaskaction，因為這些都會涉及到使用者自定義的**（如：map\reduce 對於jobsetup及jobclean 最終呼叫的outputcommitter，這些抽象類使用者也是可以自定義的。），可能會造成程序掛掉。
2、可以看出對於slot，對於map與reduce是分開的。分別有兩個tasklauncher守護執行緒處理。
3、對於單個的task，後在初始化過程中直接啟動相關的launchtaskworker來localizejob，再啟動taskrunner來準備一些引數及啟動乙個child程序。
4、 child呼叫介面taskumbilicalprotocol，此可以獲取任務的詳細資訊、反饋一些狀態、最後報告任務完成。
三、思考
我們可以多想想作者為什麼這麼設計hadoop。此設計的hadoop即使是jobtracker是單點的，在5000左右的機器數目也能勝任，再往上，可能需要別的設計方案，如：yarn。
1、由於是分布式的程式肯定會有網路不穩定等情況發生，所以對於處理異常情況是必不可少的。如：killjobaction等
2、由於很多的模組使用者可以自定義，為了保護守護程序，我們通常會重新啟動乙個程序來隔離。如：jobsetup都需要啟動乙個程序來處理。
3、由於我們需要擁塞控制及容量控制，我們就需要佇列，最起碼的是在接受到新任務需要乙個有限的佇列，不可能無限執行緒處理任務，或者乙個執行緒處理任務。
4、乙個很重要的原則是：簡單很重要。如：我們為什麼需要分開控制map reduce的個數，及為什麼存在物理的jobtracker。這個話題其實具有時效性，目前yarn的方案正在處理這個問題。簡單也是有針對性的。物理單點可以解除或者壓力小很多，map reduce slots可以合併。
5、分布式的執行緒之間需要同步狀態及阻塞控制，那我們就需要強悍的工具。如：concurrent包。
6、對於一些軟體的設計的一些基本思想，我們需要時常是回顧，勿忘根本。
等等。。。
TCP的互動資料流
在 tcp進行資料傳輸時 可以分為成塊資料流和互動資料流兩種 且處理的 演算法不同.每乙個互動按鍵都會產生乙個分組,也就是說,每次從客戶傳到伺服器的是乙個位元組的按鍵 而不是每次一行 報文段2可以和報文段3進行合併 按鍵確認和按鍵回顯一起傳送 按鍵確認和按鍵回顯兩個報文段合併在一起傳送，這種技術叫做...
TCP 互動資料流
tcp通訊量如果按分組數量計算，約一半的tcp報文段包含成塊資料 如ftp 電子郵件和usenet新聞 另一半則包含互動資料 如telnet,rlogin 如果按位元組計算，則成塊資料與互動資料的比例約為90 和10 這是因為成塊資料報文段基本上是滿長度的，而互動式資料則小得多。tcp同時處理這兩類...
TCP互動資料流 成塊資料流
tcp資料流分類 基於tcp的各類解決方案，可以根據資料吞吐量來大致分成兩大類 1 互動資料型別，例如telnet，ssh，這種型別的協議在大多數情況下只是做小流量的資料交換，比如說按一下鍵盤，回顯一些文字等等。2 資料成塊型別，例如ftp，這種型別的協議要求tcp能盡量的運載資料，把資料的吞吐量做...