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

常見(jiàn)的分布式系統(tǒng)分為數(shù)據(jù)存儲(chǔ)系統(tǒng)如hdfs，hbase；數(shù)據(jù)處理計(jì)算系統(tǒng)如storm、spark、flink；數(shù)據(jù)存儲(chǔ)兼分析混合系統(tǒng)，這類(lèi)系統(tǒng)在數(shù)據(jù)存儲(chǔ)的基礎(chǔ)上提供了復(fù)雜的數(shù)據(jù)搜索查詢(xún)功能，如elastic search、druid。對(duì)于存儲(chǔ)兼計(jì)算的系統(tǒng)，我們?nèi)匀豢梢苑珠_(kāi)分析，所以本文會(huì)從數(shù)據(jù)存儲(chǔ)和計(jì)算兩種系統(tǒng)來(lái)論述。

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

概念

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

A distributed system is one in which

components located at networked computers communicate and coordinate their

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

節(jié)點(diǎn)：節(jié)點(diǎn)可以理解為上述概念提到的組件，其實(shí)完成一組完整邏輯的程序個(gè)體，對(duì)應(yīng)于server上的一個(gè)獨(dú)立進(jìn)程。一提到節(jié)點(diǎn)，就會(huì)考慮節(jié)點(diǎn)是有狀態(tài)還是無(wú)狀態(tài)的？判斷標(biāo)準(zhǔn)很簡(jiǎn)單，該獨(dú)立節(jié)點(diǎn)是否維護(hù)著本地存儲(chǔ)的一些狀態(tài)信息，或者節(jié)點(diǎn)是不是可以隨時(shí)遷移到其他server上而保持節(jié)點(diǎn)的行為和以前一致，如果是的話(huà)，則該節(jié)點(diǎn)是無(wú)狀態(tài)，否則是有狀態(tài)的。

異常：異常處理可以說(shuō)是分布式系統(tǒng)的核心問(wèn)題，那么分布式異常處理相對(duì)于單機(jī)來(lái)說(shuō)，有什么不同呢？在單機(jī)系統(tǒng)中，對(duì)于程序的處理結(jié)果是可以預(yù)知的，要么成功，要么失敗，結(jié)果很明確?？稍诜植际江h(huán)境中，處理結(jié)果除了明確返回成功或失敗，還有另外一種狀態(tài)：超時(shí)，那超時(shí)意味著處理結(jié)果完全不確定，有可能成功執(zhí)行，也有可能執(zhí)行失敗，也有可能根本沒(méi)執(zhí)行，這給系統(tǒng)開(kāi)發(fā)帶來(lái)了很大的難度。其實(shí)各種各樣的分布式協(xié)議就是保證系統(tǒng)在各種異常情形下仍能正常的工作，所以在學(xué)習(xí)分布式系統(tǒng)時(shí)，要著重看一下文檔異常處理fault-tolerance章節(jié)。

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

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

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

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

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

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

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

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

當(dāng)數(shù)據(jù)量太大以及已經(jīng)超過(guò)單機(jī)所能處理的極限時(shí)，就需要使用到數(shù)據(jù)存儲(chǔ)分布式系統(tǒng)。無(wú)論是選擇開(kāi)源系統(tǒng)還是自己設(shè)計(jì)，第一個(gè)要考慮的問(wèn)題就是數(shù)據(jù)如何分布式化。

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

哈希方式：哈希方式是最常見(jiàn)的數(shù)據(jù)分布方式?？梢院?jiǎn)單想象有一個(gè)大的hash表，其中每個(gè)桶對(duì)應(yīng)的一臺(tái)存儲(chǔ)服務(wù)器，每條數(shù)據(jù)通過(guò)某種方式計(jì)算出其hash值分配到對(duì)應(yīng)的桶中。 int serverId = data.hashcode % serverTotalNum 上面只是一個(gè)簡(jiǎn)單的計(jì)算公式示例，通過(guò)這種方式就可以將數(shù)據(jù)分配到不同的服務(wù)器上。

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

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

缺點(diǎn)：可擴(kuò)展性不高，當(dāng)集群規(guī)模需要擴(kuò)展時(shí)，集群中所有的數(shù)據(jù)需要遷移，即使在最優(yōu)情況下——集群規(guī)模成倍擴(kuò)展，仍然需要遷移集群一半的數(shù)據(jù)（這個(gè)問(wèn)題有時(shí)間可以考慮一下，為啥只需要遷移一半？）；另一個(gè)問(wèn)題：數(shù)據(jù)通過(guò)某種hash計(jì)算后都落在某臺(tái)服務(wù)器上，造成數(shù)據(jù)傾斜（data skew）問(wèn)題。

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

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

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

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

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

數(shù)據(jù)量分布：按數(shù)據(jù)量分布，可以考慮一個(gè)簡(jiǎn)單例子：當(dāng)使用log文件記錄一些系統(tǒng)運(yùn)行的日志信息時(shí)，當(dāng)日志文件達(dá)到一定大小，就會(huì)生成新的文件開(kāi)始記錄后續(xù)的日志信息。這樣的存儲(chǔ)方式和數(shù)據(jù)的特征類(lèi)型沒(méi)有關(guān)系，可以理解成將一個(gè)大的文件分成固定大小的多個(gè)block。

優(yōu)點(diǎn)：不會(huì)有數(shù)據(jù)傾斜的問(wèn)題，而且數(shù)據(jù)遷移時(shí)速度非?？欤ㄒ?yàn)橐粋€(gè)文件由多個(gè)block組成，block在不同的server上，遷移一個(gè)文件可以多個(gè)server并行復(fù)制這些block）。

缺點(diǎn)： 需要存儲(chǔ)大量的meta信息（文件和block的對(duì)應(yīng)關(guān)系，block和server的對(duì)應(yīng)關(guān)系）。

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

一致性哈希：前文剛提到的哈希方式，當(dāng)添加刪除節(jié)點(diǎn)時(shí)候，所有節(jié)點(diǎn)都會(huì)參與到數(shù)據(jù)的遷移，整個(gè)集群都會(huì)受到影響。那么一致性哈?？梢院芎玫慕鉀Q這個(gè)問(wèn)題。一致性哈希和哈希的數(shù)據(jù)分布方式大概一致，唯一不同的是一致性哈希hash的值域是個(gè)環(huán)。

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

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

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

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

引入多個(gè)副本后，引來(lái)了一系列問(wèn)題：多個(gè)副本之間，讀取時(shí)以哪個(gè)副本的數(shù)據(jù)為準(zhǔn)呢，更新時(shí)什么才算更新成功，是所有副本都更新成功還是部分副本更新成功即可認(rèn)為更新成功？這些問(wèn)題其實(shí)就是CAP理論中可用性和一致性的問(wèn)題。其中primary-secondary副本控制模型則是解決這類(lèi)問(wèn)題行之有效的方法。

主從（primary-secondary ）模型是一種常見(jiàn)的副本更新讀取模型，這種模型相對(duì)來(lái)說(shuō)簡(jiǎn)單，所有的副本相關(guān)控制都由中心節(jié)點(diǎn)控制，數(shù)據(jù)的并發(fā)修改同樣都由主節(jié)點(diǎn)控制，這樣問(wèn)題就可以簡(jiǎn)化成單機(jī)問(wèn)題，極大的簡(jiǎn)化系統(tǒng)復(fù)雜性。

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

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

副本的更新

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

以mysql的master slave簡(jiǎn)單說(shuō)明下，通常情況下，mysql的更新只需要master更新成功即可響應(yīng)客戶(hù)端，slave可以通過(guò)binlog慢慢同步，這種情形讀取slave會(huì)有一定的延遲，一致性相對(duì)較弱，但是系統(tǒng)的可用性有了保證；另一種slave更新策略，數(shù)據(jù)的更新操作不僅要求master更新成功，同時(shí)要求slave也要更新成功，primary和secondray數(shù)據(jù)保持同步，系統(tǒng)保證強(qiáng)一致性，但可用性相對(duì)較差，響應(yīng)時(shí)間變長(zhǎng)。

上述的例子只有兩個(gè)副本，如果要求強(qiáng)一致性，所有副本都更新完成才認(rèn)為更新成功，響應(yīng)時(shí)間相對(duì)來(lái)說(shuō)也可以接受，但是如果副本數(shù)更多，有沒(méi)有什么方法在保證一定一致性同時(shí)滿(mǎn)足一定的可用性呢？這時(shí)就需要考慮Quorum協(xié)議，其理論可以用一個(gè)簡(jiǎn)單的數(shù)學(xué)問(wèn)題來(lái)說(shuō)明：

有N個(gè)副本，其中在更新時(shí)有W個(gè)副本更新成功，那我們讀取R個(gè)副本，W、R在滿(mǎn)足什么條件下保證我們讀取的R個(gè)副本一定有一個(gè)副本是最新數(shù)據(jù)（假設(shè)副本都有一個(gè)版本號(hào)，版本號(hào)大的即為最新數(shù)據(jù)）？

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

通過(guò)quorum協(xié)議，在保證一定的可用性同時(shí)又保證一定的一致性的情形下，設(shè)置副本更新成功數(shù)為總副本數(shù)的一半（即N/2+1）性?xún)r(jià)比最高。（看到這兒有沒(méi)有想明白為什么zookeeper server數(shù)最好為基數(shù)個(gè)？）

副本的讀取

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

副本的切換

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

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

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

存儲(chǔ)架構(gòu)模型

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

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

這類(lèi)系統(tǒng)主要分為三個(gè)模塊：client模塊，負(fù)責(zé)用戶(hù)和系統(tǒng)內(nèi)部模塊的通信；master節(jié)點(diǎn)模塊，負(fù)責(zé)元數(shù)據(jù)的存儲(chǔ)以及節(jié)點(diǎn)健康狀態(tài)的管理；data節(jié)點(diǎn)模塊，用于數(shù)據(jù)的存儲(chǔ)和數(shù)據(jù)查詢(xún)返回。

數(shù)據(jù)的查詢(xún)流程通常分兩步：1. 向master節(jié)點(diǎn)查詢(xún)數(shù)據(jù)對(duì)應(yīng)的節(jié)點(diǎn)信息；2. 根據(jù)返回的節(jié)點(diǎn)信息連接對(duì)應(yīng)節(jié)點(diǎn)，返回相應(yīng)的數(shù)據(jù)。

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

Search的master節(jié)點(diǎn)；data節(jié)點(diǎn)對(duì)應(yīng)hdfs的datanode、hbase的region server、Elastic Search的data node。

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

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

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

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

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

常用的數(shù)據(jù)計(jì)算主要分為離線批量計(jì)算，可以是實(shí)時(shí)計(jì)算，也可以是準(zhǔn)實(shí)時(shí)mini-batch計(jì)算，雖然開(kāi)源的系統(tǒng)很多，且每個(gè)系統(tǒng)都有其側(cè)重點(diǎn)，但有些問(wèn)題卻是共性相通的。

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

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

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

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

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

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

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

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

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

異常任務(wù)的處理

異常處理相對(duì)數(shù)據(jù)存儲(chǔ)系統(tǒng)來(lái)說(shuō)簡(jiǎn)單很多，因?yàn)閿?shù)據(jù)計(jì)算的節(jié)點(diǎn)都是無(wú)狀態(tài)的，只要啟動(dòng)任務(wù)副本即可。

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

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

簡(jiǎn)單暴力，重啟任務(wù)重新計(jì)算相關(guān)數(shù)據(jù)，典型應(yīng)用：storm，當(dāng)某個(gè)數(shù)據(jù)執(zhí)行超時(shí)或失敗，則將該數(shù)據(jù)從源頭開(kāi)始在拓?fù)渲兄匦掠?jì)算。

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

背壓——Backpressure

在數(shù)據(jù)處理中，經(jīng)常會(huì)擔(dān)心這樣一個(gè)問(wèn)題：數(shù)據(jù)處理的上游消費(fèi)數(shù)據(jù)速度太快，會(huì)不會(huì)壓垮下游數(shù)據(jù)輸出端如mysql等。 通常的解決方案：上線前期我們會(huì)做詳細(xì)的測(cè)試，評(píng)估數(shù)據(jù)下游系統(tǒng)承受的最大壓力，然后對(duì)數(shù)據(jù)上游進(jìn)行限流的配置，比如限制每秒最多消費(fèi)多少數(shù)據(jù)。其實(shí)這是一個(gè)常見(jiàn)的問(wèn)題，現(xiàn)在各個(gè)實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)都提供了背壓的功能，包括spark streaming、storm等，當(dāng)下游的數(shù)據(jù)處理速度過(guò)慢，系統(tǒng)會(huì)自動(dòng)降低上游數(shù)據(jù)的消費(fèi)速度。

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

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

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

client： 負(fù)責(zé)計(jì)算任務(wù)的提交。

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

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

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

v1版本的mapreduce計(jì)算框架圖，現(xiàn)在都已經(jīng)yarn模式的新的計(jì)算框架圖，誰(shuí)還用這種模式？哈哈，說(shuō)的對(duì)，但是現(xiàn)在仍然有些處理框架就是這種模型————storm。

不妨把圖上的一些概念和storm的概念映射起來(lái)：Job tracker 對(duì)應(yīng)于 nimbus，task tracker 對(duì)應(yīng)于 supervisor，每臺(tái)supervisor 同樣要配置worker slot，worker對(duì)應(yīng)于storm中的worker。這樣一對(duì)比，是不是就覺(jué)得一樣了？

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

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

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

總結(jié)

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

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

如果是數(shù)據(jù)存儲(chǔ)系統(tǒng)，從數(shù)據(jù)分布和副本策略開(kāi)始入手；如果是數(shù)據(jù)處理問(wèn)題，從數(shù)據(jù)投遞策略入手。

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

在了解了系統(tǒng)的大概，著重看下文檔中fault tolerence章節(jié)，看系統(tǒng)如何容錯(cuò)，或者自己可以預(yù)先問(wèn)些問(wèn)題，比如如果一個(gè)節(jié)點(diǎn)掛了、一個(gè)任務(wù)掛了系統(tǒng)是如何處理這些異常的，帶著問(wèn)題看文檔。

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

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

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

qun號(hào)是：八六四，六三四，八四五。qun內(nèi)有很多開(kāi)發(fā)工具，很多干貨和技術(shù)資料分享！

如果您覺(jué)得此篇文章對(duì)您有幫助，歡迎關(guān)注微信公眾號(hào)：大禹編程，您的支持是對(duì)我最大的鼓勵(lì)！共同學(xué)習(xí)，共同進(jìn)步: