分布式系統(tǒng)在互聯(lián)網(wǎng)公司中的應(yīng)用已經(jīng)非常普遍枚抵，開源軟件層出不窮线欲。hadoop生態(tài)系統(tǒng)，從hdfs到hbase汽摹，從mapreduce到spark李丰，從storm到spark streaming, heron, flink等等，如何在開源的汪洋中不會迷失自己逼泣？本文將從基本概念趴泌、架構(gòu)并結(jié)合自己學(xué)習(xí)工作中的感悟，闡述如何學(xué)習(xí)分布式系統(tǒng)拉庶。由于分布式系統(tǒng)理論體系非常龐大嗜憔，知識面非常廣博，筆者能力有限氏仗，不足之處吉捶，歡迎討論交流。

常見的分布式系統(tǒng)分為數(shù)據(jù)存儲系統(tǒng)如hdfs皆尔，hbase呐舔；數(shù)據(jù)處理計算系統(tǒng)如storm、spark慷蠕、flink珊拼；數(shù)據(jù)存儲兼分析混合系統(tǒng)，這類系統(tǒng)在數(shù)據(jù)存儲的基礎(chǔ)上提供了復(fù)雜的數(shù)據(jù)搜索查詢功能砌们，如elastic search杆麸、druid。對于存儲兼計算的系統(tǒng)浪感，我們?nèi)匀豢梢苑珠_分析昔头，所以本文會從數(shù)據(jù)存儲和計算兩種系統(tǒng)來論述。

文章的大致結(jié)構(gòu)：第一部分影兽，分布式系統(tǒng)的基本概念揭斧；第二、三部分分別詳細論述數(shù)據(jù)存儲和數(shù)據(jù)計算系統(tǒng)峻堰；最后一部分總結(jié)讹开。

概念

分布式系統(tǒng)：每個人都在提分布式系統(tǒng)，那么什么是分布式系統(tǒng)捐名？其基本概念就是組件分布在網(wǎng)絡(luò)計算機上旦万，組件之間僅僅通過消息傳遞來通信并協(xié)調(diào)行動。

A distributed system is one in which

components located at networked computers communicate and coordinate their

actions only by passing messages. （摘自分布式系統(tǒng)概念和設(shè)計）

節(jié)點：節(jié)點可以理解為上述概念提到的組件镶蹋，其實完成一組完整邏輯的程序個體成艘，對應(yīng)于server上的一個獨立進程赏半。一提到節(jié)點，就會考慮節(jié)點是有狀態(tài)還是無狀態(tài)的淆两？判斷標準很簡單断箫，該獨立節(jié)點是否維護著本地存儲的一些狀態(tài)信息，或者節(jié)點是不是可以隨時遷移到其他server上而保持節(jié)點的行為和以前一致秋冰，如果是的話仲义，則該節(jié)點是無狀態(tài)，否則是有狀態(tài)的剑勾。

異常：異常處理可以說是分布式系統(tǒng)的核心問題埃撵，那么分布式異常處理相對于單機來說，有什么不同呢甥材？在單機系統(tǒng)中盯另，對于程序的處理結(jié)果是可以預(yù)知的，要么成功洲赵，要么失敗鸳惯，結(jié)果很明確〉迹可在分布式環(huán)境中芝发，處理結(jié)果除了明確返回成功或失敗，還有另外一種狀態(tài)：超時苛谷，那超時意味著處理結(jié)果完全不確定辅鲸，有可能成功執(zhí)行，也有可能執(zhí)行失敗腹殿，也有可能根本沒執(zhí)行独悴，這給系統(tǒng)開發(fā)帶來了很大的難度。其實各種各樣的分布式協(xié)議就是保證系統(tǒng)在各種異常情形下仍能正常的工作锣尉，所以在學(xué)習(xí)分布式系統(tǒng)時刻炒，要著重看一下文檔異常處理fault-tolerance章節(jié)。

CAP理論：學(xué)習(xí)分布式系統(tǒng)中需要重要理解的理論自沧，同時在架構(gòu)設(shè)計中也可以用到這個理論坟奥，例如在一些情形下我們可以通過降低一致性來提高系統(tǒng)的可用性，將數(shù)據(jù)的每次數(shù)據(jù)庫更新操作變成批量操作就是典型的例子拇厢。

CAP理論爱谁，三個字母代表了系統(tǒng)中三個相互矛盾的屬性：

C（Consistency）：強一致性，保證數(shù)據(jù)中的數(shù)據(jù)完全一致孝偎；

A（Available）：在系統(tǒng)異常時访敌，仍然可以提供服務(wù)，注：這兒的可用性衣盾，一方面要求系統(tǒng)可以正常的運行返回結(jié)果捐顷，另一方面同樣對響應(yīng)速度有一定的保障荡陷；

P（Tolerance to the partition of network ）：既然是分布式系統(tǒng)雨效，很多組件都是部署在不同的server中迅涮，通過網(wǎng)絡(luò)通信協(xié)調(diào)工作，這就要求在某些節(jié)點服發(fā)生網(wǎng)絡(luò)分區(qū)異常徽龟，系統(tǒng)仍然可以正常工作叮姑。

CAP 理論指出，無法設(shè)計一種分布式協(xié)議同時完全具備CAP屬性据悔。

從以上CAP的概念我們得出一個結(jié)論传透，在技術(shù)選型時，根據(jù)你的需求來判斷是需要AP高可用性的系統(tǒng)（容忍返回不一致的數(shù)據(jù)）還是CP強一致性的系統(tǒng)极颓，或者根據(jù)系統(tǒng)提供的參數(shù)在AC之間權(quán)衡朱盐。（可能會有讀者會問，為什么一定需要P呢菠隆？既然是分布式系統(tǒng)兵琳，在網(wǎng)絡(luò)分區(qū)異常情況下仍然正常提供服務(wù)是必須的。）

數(shù)據(jù)存儲系統(tǒng)

當(dāng)數(shù)據(jù)量太大以及已經(jīng)超過單機所能處理的極限時骇径，就需要使用到數(shù)據(jù)存儲分布式系統(tǒng)躯肌。無論是選擇開源系統(tǒng)還是自己設(shè)計，第一個要考慮的問題就是數(shù)據(jù)如何分布式化破衔。

數(shù)據(jù)分布方式

哈希方式：哈希方式是最常見的數(shù)據(jù)分布方式清女。可以簡單想象有一個大的hash表晰筛，其中每個桶對應(yīng)的一臺存儲服務(wù)器嫡丙，每條數(shù)據(jù)通過某種方式計算出其hash值分配到對應(yīng)的桶中。 int serverId = data.hashcode % serverTotalNum 上面只是一個簡單的計算公式示例读第，通過這種方式就可以將數(shù)據(jù)分配到不同的服務(wù)器上曙博。

優(yōu)點：不需要存儲數(shù)據(jù)和server映射關(guān)系的meta信息，只需記錄serverId和server

ip映射關(guān)系即可卦方。

缺點：可擴展性不高羊瘩，當(dāng)集群規(guī)模需要擴展時，集群中所有的數(shù)據(jù)需要遷移盼砍，即使在最優(yōu)情況下——集群規(guī)模成倍擴展尘吗，仍然需要遷移集群一半的數(shù)據(jù)（這個問題有時間可以考慮一下，為啥只需要遷移一半浇坐？）睬捶；另一個問題：數(shù)據(jù)通過某種hash計算后都落在某臺服務(wù)器上，造成數(shù)據(jù)傾斜（data skew）問題近刘。

應(yīng)用例子：ElasticSearch數(shù)據(jù)分布就是hash方式擒贸，根據(jù)routingId取模映射到對應(yīng)到不同node上臀晃。

數(shù)據(jù)范圍分布：將數(shù)據(jù)的某個特征值按照值域分為不同區(qū)間。比如按時間介劫、區(qū)間分割徽惋，不同時間范圍劃分到不同server上。

優(yōu)點：數(shù)據(jù)區(qū)間可以自由分割座韵，當(dāng)出現(xiàn)數(shù)據(jù)傾斜時险绘，即某一個區(qū)間的數(shù)據(jù)量非常大，則可以將該區(qū)間split然后將數(shù)據(jù)進行重分配誉碴；集群方便擴展宦棺，當(dāng)添加新的節(jié)點，只需將數(shù)據(jù)量多的節(jié)點數(shù)據(jù)遷移到新節(jié)點即可黔帕。

缺點：需要存儲大量的元信息（數(shù)據(jù)區(qū)間和server的對應(yīng)關(guān)系）代咸。

應(yīng)用例子：Hbase的數(shù)據(jù)分布則是利用data的rowkey進行區(qū)間劃分到不同的region server，而且支持region的split成黄。

數(shù)據(jù)量分布：按數(shù)據(jù)量分布呐芥，可以考慮一個簡單例子：當(dāng)使用log文件記錄一些系統(tǒng)運行的日志信息時，當(dāng)日志文件達到一定大小慨默，就會生成新的文件開始記錄后續(xù)的日志信息贩耐。這樣的存儲方式和數(shù)據(jù)的特征類型沒有關(guān)系，可以理解成將一個大的文件分成固定大小的多個block厦取。

優(yōu)點：不會有數(shù)據(jù)傾斜的問題潮太，而且數(shù)據(jù)遷移時速度非常快（因為一個文件由多個block組成虾攻，block在不同的server上铡买，遷移一個文件可以多個server并行復(fù)制這些block）。

缺點： 需要存儲大量的meta信息（文件和block的對應(yīng)關(guān)系霎箍，block和server的對應(yīng)關(guān)系）奇钞。

應(yīng)用例子：Hdfs的文件存儲按數(shù)據(jù)量block分布。

一致性哈希：前文剛提到的哈希方式漂坏，當(dāng)添加刪除節(jié)點時候景埃，所有節(jié)點都會參與到數(shù)據(jù)的遷移，整個集群都會受到影響顶别。那么一致性哈瞎柔悖可以很好的解決這個問題。一致性哈希和哈希的數(shù)據(jù)分布方式大概一致驯绎，唯一不同的是一致性哈希hash的值域是個環(huán)完慧。

優(yōu)點：集群可擴展性好，當(dāng)增加刪除節(jié)點剩失，只影響相鄰的數(shù)據(jù)節(jié)點屈尼。

缺點：上面的優(yōu)點同時也是缺點册着，當(dāng)一個節(jié)點掛掉時，將壓力全部轉(zhuǎn)移到相鄰節(jié)點脾歧，有可能將相鄰節(jié)點壓垮甲捏。

應(yīng)用例子：Cassandra數(shù)據(jù)分布使用的是一致性hash，只不過使用的是一致性hash改良版：虛擬節(jié)點的一致性hash（有興趣的可以研究下）涨椒。

討論完數(shù)據(jù)分布問題摊鸡，接下來該考慮如何解決當(dāng)某個節(jié)點服務(wù)不可達的時候系統(tǒng)仍然可以正常工作（分布式系統(tǒng)CAP中網(wǎng)絡(luò)分區(qū)異常問題）？這個問題的解決方案說起來很簡單蚕冬，就是將數(shù)據(jù)的存儲增加多個副本，而且分布在不同的節(jié)點上是辕，當(dāng)某個節(jié)點掛掉的時候囤热，可以從其他數(shù)據(jù)副本讀取。

引入多個副本后获三，引來了一系列問題：多個副本之間旁蔼，讀取時以哪個副本的數(shù)據(jù)為準呢，更新時什么才算更新成功疙教，是所有副本都更新成功還是部分副本更新成功即可認為更新成功棺聊？這些問題其實就是CAP理論中可用性和一致性的問題。其中primary-secondary副本控制模型則是解決這類問題行之有效的方法贞谓。

主從（primary-secondary ）模型是一種常見的副本更新讀取模型限佩，這種模型相對來說簡單，所有的副本相關(guān)控制都由中心節(jié)點控制裸弦，數(shù)據(jù)的并發(fā)修改同樣都由主節(jié)點控制祟同，這樣問題就可以簡化成單機問題，極大的簡化系統(tǒng)復(fù)雜性理疙。

注：常用的副本更新讀取架構(gòu)有兩種：主從（primary-secondary）和去中心化（decentralized）結(jié)構(gòu)晕城，其中主從結(jié)構(gòu)較為常見，而去中心化結(jié)構(gòu)常采用paxos窖贤、raft砖顷、vector time等協(xié)議，這里由于本人能力有限赃梧，就不再這兒敘述了滤蝠，有興趣可以自己學(xué)習(xí)，歡迎補充槽奕。

其中涉及到主從副本操作有以下幾種：

副本的更新

副本更新基本流程：數(shù)據(jù)更新操作發(fā)到primary節(jié)點几睛，由primary將數(shù)據(jù)更新操作同步到其他secondary副本，根據(jù)其他副本的同步結(jié)果返回客戶端響應(yīng)粤攒。各類數(shù)據(jù)存儲分布式系統(tǒng)的副本更新操作流程大體是一樣的所森，唯一不同的是primary副本更新操作完成后響應(yīng)客戶端時機的不同囱持，這與系統(tǒng)可用性和一致性要求密切相關(guān)。

以mysql的master slave簡單說明下焕济，通常情況下纷妆，mysql的更新只需要master更新成功即可響應(yīng)客戶端，slave可以通過binlog慢慢同步晴弃，這種情形讀取slave會有一定的延遲掩幢，一致性相對較弱，但是系統(tǒng)的可用性有了保證上鞠；另一種slave更新策略际邻，數(shù)據(jù)的更新操作不僅要求master更新成功，同時要求slave也要更新成功芍阎，primary和secondray數(shù)據(jù)保持同步世曾，系統(tǒng)保證強一致性，但可用性相對較差谴咸，響應(yīng)時間變長轮听。

上述的例子只有兩個副本，如果要求強一致性岭佳，所有副本都更新完成才認為更新成功血巍，響應(yīng)時間相對來說也可以接受，但是如果副本數(shù)更多珊随，有沒有什么方法在保證一定一致性同時滿足一定的可用性呢述寡？這時就需要考慮Quorum協(xié)議，其理論可以用一個簡單的數(shù)學(xué)問題來說明：

有N個副本玫恳，其中在更新時有W個副本更新成功辨赐，那我們讀取R個副本，W京办、R在滿足什么條件下保證我們讀取的R個副本一定有一個副本是最新數(shù)據(jù)（假設(shè)副本都有一個版本號掀序，版本號大的即為最新數(shù)據(jù)）？

問題的答案是：W+R > N (有興趣的可以思考下)

通過quorum協(xié)議惭婿，在保證一定的可用性同時又保證一定的一致性的情形下不恭，設(shè)置副本更新成功數(shù)為總副本數(shù)的一半（即N/2+1）性價比最高。（看到這兒有沒有想明白為什么zookeeper server數(shù)最好為基數(shù)個财饥？）

副本的讀取

副本的讀取策略和一致性的選擇有關(guān)换吧，如果需要強一致性，我們可以只從primary副本讀取钥星，如果需要最終一致性沾瓦，可以從secondary副本讀取結(jié)果，如果需要讀取最新數(shù)據(jù)，則按照quorum協(xié)議要求贯莺，讀取相應(yīng)的副本數(shù)风喇。

副本的切換

當(dāng)系統(tǒng)中某個副本不可用時，需要從剩余的副本之中選取一個作為primary副本來保證后續(xù)系統(tǒng)的正常執(zhí)行缕探。這兒涉及到兩個問題：

副本狀態(tài)的確定以及防止brain split問題：一般方法是利用zookeeper中的sesstion以及臨時節(jié)點魂莫，其基本原理則是lease協(xié)議和定期heartbeat。Lease協(xié)議可以簡單理解成參與雙方達成一個承諾爹耗，針對zookeeper耙考，這個承諾就是在session有效時間內(nèi)，我認為你的節(jié)點狀態(tài)是活的是可用的潭兽，如果發(fā)生session timeout倦始，認為副本所在的服務(wù)已經(jīng)不可用，無論誤判還是服務(wù)真的宕掉了讼溺，通過這種機制可以防止腦裂的發(fā)生楣号。但這樣會引起另外一個問題：當(dāng)在session timeout期間，primary 副本服務(wù)掛掉了怒坯，這樣會造成一段時間內(nèi)的服務(wù)不可用。

primary副本的確定：這個問題和副本讀取最新數(shù)據(jù)其實是一個問題藻懒，可以利用quoram以及全局版本號確定primary副本剔猿。zookeeper在leader選舉的過程中其實利用了quoram以及全局事務(wù)id——zxid確定primary副本。

存儲架構(gòu)模型

關(guān)于數(shù)據(jù)的分布和副本的模型這些細節(jié)問題已經(jīng)詳細敘述嬉荆，那么從系統(tǒng)整體架構(gòu)來看归敬，數(shù)據(jù)存儲的一般流程和主要模塊都有哪些呢？從元數(shù)據(jù)存儲以及節(jié)點之間的membership管理方面來看蓄髓，主要分以下兩類：

中心化的節(jié)點membership管理架構(gòu)

這類系統(tǒng)主要分為三個模塊：client模塊仔燕，負責(zé)用戶和系統(tǒng)內(nèi)部模塊的通信装黑；master節(jié)點模塊，負責(zé)元數(shù)據(jù)的存儲以及節(jié)點健康狀態(tài)的管理舱污；data節(jié)點模塊，用于數(shù)據(jù)的存儲和數(shù)據(jù)查詢返回弥虐。

數(shù)據(jù)的查詢流程通常分兩步：1. 向master節(jié)點查詢數(shù)據(jù)對應(yīng)的節(jié)點信息扩灯；2. 根據(jù)返回的節(jié)點信息連接對應(yīng)節(jié)點，返回相應(yīng)的數(shù)據(jù)霜瘪。

分析一下目前常見的數(shù)據(jù)存儲系統(tǒng)珠插，從hdfs，hbase再到Elastic Search颖对，通過與上述通用系統(tǒng)對比捻撑，發(fā)現(xiàn)：master節(jié)點模塊具體對應(yīng)hdfs的namenode、hbase的hMaster、Elastic

Search的master節(jié)點顾患；data節(jié)點對應(yīng)hdfs的datanode番捂、hbase的region server、Elastic Search的data node描验。

去中心化的節(jié)點membership管理架構(gòu)

與上一模型比較白嘁，其最大的變化就是該架構(gòu)中不存在任何master節(jié)點，系統(tǒng)中的每個節(jié)點可以做類似master的任務(wù)：存儲系統(tǒng)元信息以及管理集群節(jié)點膘流。

數(shù)據(jù)的查詢方式也有所不同絮缅，client可以訪問系統(tǒng)中的任意節(jié)點，而不再局限于master節(jié)點呼股，具體查詢流程如下：1. 查詢系統(tǒng)中任意節(jié)點耕魄，如果該數(shù)據(jù)在此節(jié)點上則返回相應(yīng)的數(shù)據(jù)，如果不在該節(jié)點彭谁，則返回對應(yīng)數(shù)據(jù)的節(jié)點地址吸奴，執(zhí)行第二步；2. 獲得數(shù)據(jù)對應(yīng)的地址后向相關(guān)請求數(shù)據(jù)缠局。

節(jié)點之間共享狀態(tài)信息是如何做到的呢则奥？常用的方法是使用如gossip的協(xié)議以及在此基礎(chǔ)之上開發(fā)的serf框架，感興趣的話可以參考redis cluster 和 consul實現(xiàn)狭园。

數(shù)據(jù)計算處理系統(tǒng)

常用的數(shù)據(jù)計算主要分為離線批量計算读处，可以是實時計算，也可以是準實時mini-batch計算唱矛，雖然開源的系統(tǒng)很多罚舱，且每個系統(tǒng)都有其側(cè)重點，但有些問題卻是共性相通的绎谦。

數(shù)據(jù)投遞策略

在數(shù)據(jù)處理中首先要考慮一個問題管闷，我們的數(shù)據(jù)記錄在系統(tǒng)中會被處理幾次（包括正常情形和異常情形）：

at most once：數(shù)據(jù)處理最多一次，這種語義在異常情況下會有數(shù)據(jù)丟失窃肠；

at least once：數(shù)據(jù)處理最少一次包个，這種語義會造成數(shù)據(jù)的重復(fù)；

exactly once：數(shù)據(jù)只處理一次铭拧，這種語義支持是最復(fù)雜的赃蛛，要想完成這一目標需要在數(shù)據(jù)處理的各個環(huán)節(jié)做到保障。

如何做到exactly once搀菩，需要在數(shù)據(jù)處理各個階段做些保證：

數(shù)據(jù)接收：由不同的數(shù)據(jù)源保證呕臂。

數(shù)據(jù)傳輸：數(shù)據(jù)傳輸可以保證exactly once。

數(shù)據(jù)輸出：根據(jù)數(shù)據(jù)輸出的類型確定肪跋，如果數(shù)據(jù)的輸出操作對于同樣的數(shù)據(jù)輸入保證冪等性歧蒋，這樣就很簡單（比如可以把kafka的offset作為輸出mysql的id），如果不是，要提供額外的分布式事務(wù)機制如兩階段提交等等谜洽。

異常任務(wù)的處理

異常處理相對數(shù)據(jù)存儲系統(tǒng)來說簡單很多萝映，因為數(shù)據(jù)計算的節(jié)點都是無狀態(tài)的，只要啟動任務(wù)副本即可阐虚。

注意：異常任務(wù)除了那些失敗序臂、超時的任務(wù)，還有一類特殊任務(wù)——straggler（拖后腿）任務(wù)实束，一個大的Job會分成多個小task并發(fā)執(zhí)行奥秆，發(fā)現(xiàn)某一個任務(wù)比同類型的其他任務(wù)執(zhí)行要慢很多（忽略數(shù)據(jù)傾斜導(dǎo)致執(zhí)行速度慢的因素）。

其中任務(wù)恢復(fù)策略有以下幾種：

簡單暴力咸灿，重啟任務(wù)重新計算相關(guān)數(shù)據(jù)构订，典型應(yīng)用：storm，當(dāng)某個數(shù)據(jù)執(zhí)行超時或失敗避矢，則將該數(shù)據(jù)從源頭開始在拓撲中重新計算悼瘾。

根據(jù)checkpoint重試出錯的任務(wù)，典型應(yīng)用：mapreduce审胸，一個完整的數(shù)據(jù)處理是分多個階段完成的亥宿，每個階段（map 或者reduce）的輸出結(jié)果都會保存到相應(yīng)的存儲中，只要重啟任務(wù)重新讀取上一階段的輸出結(jié)果即可繼續(xù)開始運行砂沛，不必從開始重新執(zhí)行該任務(wù)箩绍。

背壓——Backpressure

在數(shù)據(jù)處理中，經(jīng)常會擔(dān)心這樣一個問題：數(shù)據(jù)處理的上游消費數(shù)據(jù)速度太快尺上，會不會壓垮下游數(shù)據(jù)輸出端如mysql等。 通常的解決方案：上線前期我們會做詳細的測試圆到，評估數(shù)據(jù)下游系統(tǒng)承受的最大壓力怎抛，然后對數(shù)據(jù)上游進行限流的配置，比如限制每秒最多消費多少數(shù)據(jù)芽淡。其實這是一個常見的問題马绝，現(xiàn)在各個實時數(shù)據(jù)處理系統(tǒng)都提供了背壓的功能，包括spark streaming挣菲、storm等富稻，當(dāng)下游的數(shù)據(jù)處理速度過慢，系統(tǒng)會自動降低上游數(shù)據(jù)的消費速度白胀。

對背壓感興趣朋友們椭赋，或者有想法自己實現(xiàn)一套數(shù)據(jù)處理系統(tǒng)，可以參考Reactive Stream或杠，該項目對通用數(shù)據(jù)處理提供了一種規(guī)范哪怔，采用這種規(guī)范比較有名的是akka。

數(shù)據(jù)處理通用架構(gòu)

數(shù)據(jù)處理的架構(gòu)大抵是相似的，通常包含以下幾個模塊：

client： 負責(zé)計算任務(wù)的提交认境。

scheduler ： 計算任務(wù)的生成和計算資源的調(diào)度胚委，同時還包含計算任務(wù)運行狀況的監(jiān)控和異常任務(wù)的重啟。

worker：計算任務(wù)會分成很多小的task叉信，worker負責(zé)這些小task的執(zhí)行同時向scheduler匯報當(dāng)前node可用資源及task的執(zhí)行狀況亩冬。

上圖是通用的架構(gòu)模型圖，有些人會問這是hadoop

v1版本的mapreduce計算框架圖硼身，現(xiàn)在都已經(jīng)yarn模式的新的計算框架圖硅急，誰還用這種模式？哈哈鸠姨，說的對铜秆，但是現(xiàn)在仍然有些處理框架就是這種模型————storm。

不妨把圖上的一些概念和storm的概念映射起來：Job tracker 對應(yīng)于 nimbus讶迁，task tracker 對應(yīng)于 supervisor连茧，每臺supervisor 同樣要配置worker slot，worker對應(yīng)于storm中的worker巍糯。這樣一對比啸驯，是不是就覺得一樣了？

這種框架模型有它的問題祟峦，責(zé)任不明確罚斗，每個模塊干著多樣工作。例如Job tracker不僅要監(jiān)控任務(wù)的執(zhí)行狀態(tài)宅楞，還要負責(zé)任務(wù)的調(diào)度针姿。TaskTracker也同樣，不僅要監(jiān)控task的狀態(tài)厌衙、執(zhí)行距淫，同樣還要監(jiān)控節(jié)點資源的使用。

針對以上問題婶希，基于yarn模式的新的處理架構(gòu)模型榕暇，將任務(wù)執(zhí)行狀態(tài)的監(jiān)控和任務(wù)資源的調(diào)度分開。原來的Job tracker分為resource manger 負責(zé)資源的調(diào)度喻杈，任務(wù)執(zhí)行的監(jiān)控則交給每個appMaster來負責(zé)彤枢，原來的task tracker，變?yōu)榱薾ode manager筒饰，負責(zé)資源的監(jiān)控和task的啟動缴啡，而task的執(zhí)行狀態(tài)和異常處理則交給appMaster處理。

同樣的龄砰，twitter 根據(jù)storm架構(gòu)方面的一些問題盟猖，推出了新的處理框架heron讨衣，其解決的問題也是將任務(wù)的調(diào)度和任務(wù)的執(zhí)行狀態(tài)監(jiān)控責(zé)任分離，引入了新的概念Topology Master式镐，類似于這兒的appMaster反镇。

總結(jié)

分布式系統(tǒng)涵蓋的內(nèi)容非常多，本篇文章主要從整體架構(gòu)以及概念上介紹如何入門娘汞，學(xué)習(xí)過程有一些共性的問題歹茶，在這兒總結(jié)一下：

先分析該系統(tǒng)是數(shù)據(jù)存儲還是計算系統(tǒng)。

如果是數(shù)據(jù)存儲系統(tǒng)你弦，從數(shù)據(jù)分布和副本策略開始入手惊豺；如果是數(shù)據(jù)處理問題，從數(shù)據(jù)投遞策略入手禽作。

讀對應(yīng)系統(tǒng)架構(gòu)圖尸昧，對應(yīng)著常用的架構(gòu)模型，每個組件和已有的系統(tǒng)進行類比旷偿，想一下這個組件類似于hdfs的namenode等等烹俗，最后在腦海里梳理下數(shù)據(jù)流的整個流程。

在了解了系統(tǒng)的大概萍程，著重看下文檔中fault tolerence章節(jié)幢妄，看系統(tǒng)如何容錯，或者自己可以預(yù)先問些問題茫负，比如如果一個節(jié)點掛了蕉鸳、一個任務(wù)掛了系統(tǒng)是如何處理這些異常的，帶著問題看文檔忍法。

文檔詳細讀了一遍潮尝，就可以按照官方文檔寫些hello world的例子了，詳細查看下系統(tǒng)配置項饿序，隨著工作的深入就可以看些系統(tǒng)的細節(jié)和關(guān)鍵源碼了衍锚。

————————————————————————————————————

想了解更多前沿技術(shù)，想獲取最新免費編程資源視頻源碼筆記嗤堰，小伙伴請往下看！

qun號是：八六四度宦，六三四踢匣，八四五。qun內(nèi)有很多開發(fā)工具戈抄，很多干貨和技術(shù)資料分享离唬！

如果您覺得此篇文章對您有幫助，歡迎關(guān)注微信公眾號：大禹編程划鸽，您的支持是對我最大的鼓勵输莺！共同學(xué)習(xí)戚哎，共同進步: