【文章內(nèi)容簡(jiǎn)介】 從上表可以看到，其實(shí)有的操作本質(zhì)上還是涉及到了數(shù)據(jù)服務(wù)器，比如文件創(chuàng)建和刪除操作。但是，之前提到，主控服務(wù)器只于數(shù)據(jù)服務(wù)器是一個(gè)等待拉取的地位，它們不會(huì)主動(dòng)聯(lián)系數(shù)據(jù)服務(wù)器，將指令傳輸給它們，而是放到相應(yīng)的數(shù)據(jù)結(jié)構(gòu)中，等待數(shù)據(jù)服務(wù)器來(lái)取。這樣的設(shè)計(jì)，可以減少通信的次數(shù)，加快操作的執(zhí)行速度。另，上述步驟中，有些日志和租約相關(guān)的操作，從概念上來(lái)說(shuō)，和目錄操作其實(shí)沒有任何聯(lián)系，但是，為了滿足分布式系統(tǒng)的需求，這些操作是非常有必要的，在此，按下不表。文件的讀取不論是文件讀取，還是文件的寫入，主控服務(wù)器扮演的都是中介的角色?？蛻舳税炎约旱男枨筇峤唤o主控服務(wù)器，主控服務(wù)器挑選合適的數(shù)據(jù)服務(wù)器，介紹給客戶端，讓客戶端和數(shù)據(jù)服務(wù)器單聊，要讀要寫隨你們便。這種策略類似于DMA，降低了主控服務(wù)器的負(fù)載，提高了效率。因此，在文件讀寫操作中，最主要的通信，發(fā)生在客戶端與數(shù)據(jù)服務(wù)器之間。它們之間跑的協(xié)議是ClientDatanodeProtocol。從這個(gè)協(xié)議中間，你無(wú)法看到和讀寫相關(guān)的接口，因?yàn)?，在Hadoop中，讀寫操作是不走RPC機(jī)制的，而是另立門戶，獨(dú)立搭了一套通信框架。在數(shù)據(jù)服務(wù)器一端，DataNode類中有一個(gè)DataXceiverServer類的實(shí)例，它在一個(gè)單獨(dú)的線程等待請(qǐng)求，一旦接到，就啟動(dòng)一個(gè)DataXceiver的線程，處理此次請(qǐng)求。一個(gè)請(qǐng)求一個(gè)線程，對(duì)于數(shù)據(jù)服務(wù)器來(lái)說(shuō)，邏輯上很簡(jiǎn)單。當(dāng)下，DataXceiver支持的請(qǐng)求類型有六種，具體的請(qǐng)求包和回復(fù)包格式，請(qǐng)參見這里，這里，這里。在Hadoop的實(shí)現(xiàn)中，并沒有用類來(lái)封裝這些請(qǐng)求，而是按流的次序?qū)懴聛?lái)，這給代碼閱讀帶來(lái)挺多的麻煩，也對(duì)代碼的維護(hù)帶來(lái)一定的困難，不知道是出于何種考慮。相比于寫，文件的讀取實(shí)在是一個(gè)簡(jiǎn)單的過(guò)程。在客戶端DFSClient中。當(dāng)需要讀取一個(gè)文件的時(shí)候，會(huì)生成一個(gè)DFSInputStream的實(shí)例。它會(huì)先調(diào)用ClientProtocol定義getBlockLocations接口，提供給NameNode文件路徑、讀取位置、讀取長(zhǎng)度信息，從中取得一個(gè)LocatedBlocks類的對(duì)象，這個(gè)對(duì)象包含一組LocatedBlock，那里面有所規(guī)定位置中包含的所有數(shù)據(jù)塊信息，以及數(shù)據(jù)塊對(duì)應(yīng)的所有數(shù)據(jù)服務(wù)器的位置信息。當(dāng)讀取開始后，DFSInputStream會(huì)先嘗試從某個(gè)數(shù)據(jù)塊對(duì)應(yīng)的一組數(shù)據(jù)服務(wù)器中選出一個(gè)，進(jìn)行連接。這個(gè)選取算法，在當(dāng)下的實(shí)現(xiàn)中，非常簡(jiǎn)單，就是選出第一個(gè)未掛的數(shù)據(jù)服務(wù)器，并沒有加入客戶端與數(shù)據(jù)服務(wù)器相對(duì)位置的考量。讀取的請(qǐng)求，發(fā)送到數(shù)據(jù)服務(wù)器后，自然會(huì)有DataXceiver來(lái)處理，數(shù)據(jù)被一個(gè)包一個(gè)包發(fā)送回客戶端，等到整個(gè)數(shù)據(jù)塊的數(shù)據(jù)都被讀取完了，就會(huì)斷開此鏈接，嘗試連接下一個(gè)數(shù)據(jù)塊對(duì)應(yīng)的數(shù)據(jù)服務(wù)器，整個(gè)流程，依次如此反復(fù)，直到所有想讀的都讀取完了為止。文件的寫入文件讀取是一個(gè)一對(duì)一的過(guò)程，一個(gè)客戶端，只需要與一個(gè)數(shù)據(jù)服務(wù)器聯(lián)系，就可以獲得所需的內(nèi)容。但是，寫入操作，則是一個(gè)一對(duì)多的流程。一次寫入，需要在所有存放相關(guān)數(shù)據(jù)塊的數(shù)據(jù)服務(wù)器都保持同步的更新，有任何的差池，整個(gè)流程就告失敗。在分布式系統(tǒng)中，一旦涉及到寫入操作，并發(fā)處理難免都會(huì)淪落成為一個(gè)變了相的串行操作。因?yàn)椋绻煌目蛻舳巳绻侨我鈺r(shí)序并發(fā)寫入的話，整個(gè)寫入的次序無(wú)法保證，可能你寫半條記錄我寫半條記錄，最后出來(lái)的結(jié)果亂七八糟不可估量。在HDFS中，并發(fā)寫入的次序控制，是由主控服務(wù)器來(lái)把握的。當(dāng)創(chuàng)建、續(xù)寫一個(gè)文件的時(shí)候，該文件的節(jié)點(diǎn)類，由INodeFile升級(jí)成為INodeFileUnderConstruction，INodeFileUnderConstruction是INodeFile的子類，它起到一個(gè)鎖的作用。如果當(dāng)一個(gè)客戶端想創(chuàng)建或續(xù)寫的文件是INodeFileUnderConstruction，會(huì)引發(fā)異常，因?yàn)檫@說(shuō)明這個(gè)此處有爺，請(qǐng)另尋高就，從而保持了并發(fā)寫入的次序性。同時(shí)，INodeFileUnderConstruction有包含了此時(shí)正在操作它的客戶端的信息以及最后一個(gè)數(shù)據(jù)塊的數(shù)據(jù)服務(wù)器信息，當(dāng)追加寫的時(shí)候可以更快速的響應(yīng)。與讀取類似，寫入開始，會(huì)創(chuàng)建此類的實(shí)例。DFSOutputStream會(huì)從NameNode上拿一個(gè)LocatedBlock，這里面有最后一個(gè)數(shù)據(jù)塊的所有數(shù)據(jù)服務(wù)器的信息。這些數(shù)據(jù)服務(wù)器每一個(gè)都需要能夠正常工作（對(duì)于讀取，只要還有一個(gè)能工作的就可以實(shí)現(xiàn)...），它們會(huì)依照客戶端的位置被排列成一個(gè)有著最近物理距離和最小的序列（物理距離，是根據(jù)機(jī)器的位置定下來(lái)的...），這個(gè)排序問(wèn)題類似于著名旅行商問(wèn)題，屬于NP復(fù)雜度，但是由于服務(wù)器數(shù)量不多，所以用最粗暴的算法，也并不會(huì)看上去不美。文件寫入，就是在這一組數(shù)據(jù)服務(wù)器上構(gòu)造成數(shù)據(jù)流的雙向流水線。DFSOutputStream，會(huì)與序列的第一個(gè)數(shù)據(jù)服務(wù)器建立Socket連接，發(fā)送請(qǐng)求頭，然后等待回應(yīng)。DataNode同樣是建立DataXceiver來(lái)處理寫消息，DataXceiver會(huì)依照包中傳過(guò)來(lái)的其他服務(wù)器的信息，建立與下一個(gè)服務(wù)器的連接，并生成類似的頭，發(fā)送給它，并等待回包。此流程依次延續(xù)，直到最后一級(jí)，它發(fā)送回包，反向著逐級(jí)傳遞，再次回到客戶端。如果一切順利，那么此時(shí)，流水線建立成功，開始正式發(fā)送數(shù)據(jù)。數(shù)據(jù)是分成一個(gè)個(gè)數(shù)據(jù)包發(fā)送的，所有寫入的內(nèi)容，被緩存在客戶端，當(dāng)寫滿64K，放入DFSOutputStream的dataQueue隊(duì)列。，一旦不為空，則開始發(fā)送，將位于dataQueue隊(duì)首的包移動(dòng)到ackQueue隊(duì)列的隊(duì)尾，表示已發(fā)送但尚未接受回復(fù)的包隊(duì)列。同時(shí)啟動(dòng)ResponseProcessor線程監(jiān)聽回包，直到收到相應(yīng)回包，才將發(fā)送包從ackQueue中移除，表示成功。每一個(gè)數(shù)據(jù)服務(wù)器的DataXceiver收到了數(shù)據(jù)包，一邊寫入到本地文件中去，一邊轉(zhuǎn)發(fā)給下一級(jí)的數(shù)據(jù)服務(wù)器，等待回包，同前面建立流水線的流程。當(dāng)一個(gè)數(shù)據(jù)塊寫滿了之后，客戶端需要向主控服務(wù)器申請(qǐng)追加新的數(shù)據(jù)塊。這個(gè)會(huì)引起一次數(shù)據(jù)塊的分配，成功后，會(huì)將新的數(shù)據(jù)服務(wù)器組返還給客戶端。然后重新回到上述流程，繼續(xù)前行。關(guān)于寫入的流程，還可以參見這里。此外，寫入涉及到租約問(wèn)題，后續(xù)會(huì)仔細(xì)的來(lái)說(shuō)。IV. 分布式支持如果單機(jī)的文件系統(tǒng)是田里勤懇的放牛娃，那么分布式文件系統(tǒng)就是刀尖上討飯吃的馬賊了。在分布式環(huán)境中，有太多的意外，數(shù)據(jù)隨時(shí)傳輸錯(cuò)誤，服務(wù)器時(shí)刻準(zhǔn)備犧牲，很多平常稱為異常的現(xiàn)象，在這里都需要按照平常事來(lái)對(duì)待。因此，對(duì)于分布式文件系統(tǒng)而言，僅僅是滿足了正常狀況下文件系統(tǒng)各項(xiàng)服務(wù)還不夠，還需要保證分布式各種意外場(chǎng)景下健康持續(xù)的服務(wù)，否則，將一無(wú)是處。服務(wù)器的錯(cuò)誤恢復(fù)在分布式環(huán)境中，哪臺(tái)服務(wù)器犧牲都是常見的事情，犧牲不可怕，可怕的是你都沒有時(shí)刻準(zhǔn)備好它們會(huì)犧牲。作為一個(gè)合格的分布式系統(tǒng)，HDFS當(dāng)然時(shí)刻準(zhǔn)備好了前赴后繼奮勇向前。HDFS有三類服務(wù)器，每一類服務(wù)器出錯(cuò)了，都有相應(yīng)的應(yīng)急策略。a. 客戶端生命最輕如鴻毛的童鞋，應(yīng)該就是客戶端了。畢竟，做為一個(gè)文件系統(tǒng)的使用者，在整個(gè)文件系統(tǒng)中的地位，難免有些歸于三流。而作為客戶端，大部分時(shí)候，犧牲了就犧牲了，沒人哀悼，無(wú)人同情，只有在在辛勤寫入的時(shí)候，不幸辭世（機(jī)器掛了，或者網(wǎng)絡(luò)斷了，諸如此類...），才會(huì)引起些恐慌。因?yàn)?，此時(shí)此刻，在主控服務(wù)器上對(duì)應(yīng)的文件，正作為INodeFileUnderConstruction活著，僅僅為占有它的那個(gè)客戶端服務(wù)者，做為一個(gè)專一的文件，它不允許別的客戶端染指。這樣的話，一旦占有它的客戶端服務(wù)者犧牲了，此客戶端會(huì)依