[[312241]]

分布式技術(shù)，在保障高可用和容錯(cuò)或彈性時(shí)，一般常用這兩種手段：

• 復(fù)制
• 分區(qū)

對應(yīng)英語一個(gè)是replication, 一個(gè)是partition。

復(fù)制，是把每次寫入的數(shù)據(jù)多保存 N 份，這樣在出故障的時(shí)候可以用來恢復(fù)，同時(shí)也可以進(jìn)行讀寫分離，緩解讀的壓力。分區(qū)則是在數(shù)據(jù)超越了單臺(tái)存儲(chǔ)能力的時(shí)候，按一定規(guī)則分多臺(tái)存儲(chǔ)。分區(qū)的數(shù)據(jù)其實(shí)也是有復(fù)制的存在來保障這一個(gè)partition的數(shù)據(jù)不丟失。

復(fù)制了就可以高枕無憂了?

這都是理想情況，實(shí)際上每天都會(huì)出現(xiàn)機(jī)房故障，硬盤損壞，失誤斷電等等問題。

比如咱們自己把手機(jī)上的照片、文件等等備份到網(wǎng)盤，手機(jī)一清理， 欣喜騰出不少空間。某天去看的時(shí)候，網(wǎng)盤里一部分?jǐn)?shù)據(jù)找不到了，客服告訴你某天機(jī)房備份文件的硬盤壞了，再也找不回來，你啥感覺?

你肯定憤怒的問客服為啥不再多存幾份。可如果是整個(gè)硬盤所在機(jī)架都掛了呢?

和咱們搭應(yīng)用的服務(wù)一樣，為了應(yīng)對問題，保證高可用，除了不出現(xiàn)單點(diǎn)，還得考慮實(shí)例部署在不同的機(jī)房，這樣就算某個(gè)機(jī)房都出問題的時(shí)候，另一個(gè)機(jī)房也還能扛著。

對應(yīng)到數(shù)據(jù)的復(fù)制和備份上，聰明的腦袋們想出了類似的思路，將備份存在不同的硬盤，不同的機(jī)架，甚至不同的機(jī)房上，像兔子一樣，做到

「狡兔三窟」。 :-)

咱們一般使用網(wǎng)盤，云服務(wù)廠商提供的各類存儲(chǔ)，背后都有一個(gè)分布式的存儲(chǔ)服務(wù)，來保證應(yīng)用的高可用，彈性容錯(cuò)等等，像咱們之前分享的神書 DDIA 里許多技術(shù)都在這些服務(wù)里有使用。

HDFS 做為Hadoop的核心存儲(chǔ)實(shí)現(xiàn)，內(nèi)部也支持這種更安全的多地存儲(chǔ)備份實(shí)現(xiàn)。在 HDFS 中，這一技術(shù)稱為 Rack Awareness。

Rack 就是機(jī)架，是在機(jī)房或者數(shù)據(jù)中心里存儲(chǔ)著一堆的物理機(jī)，通過網(wǎng)絡(luò)的技術(shù)來管理。

在 Hadoop 里為了在一個(gè)集群里提升網(wǎng)絡(luò)讀寫 HDFS 文件的速度，管理MetaData信息的 NameNode 會(huì)根據(jù) Rack 就近選取 DataNode去

讀寫。畢竟 NameNode存放著 rack id 和 DataNode 的對應(yīng)信息，我們的備份數(shù)據(jù)真正寫到了 DataNode里。rack id 相當(dāng)于代號(hào)。

NameNode 根據(jù) Rack id 選擇一個(gè)更近的 DataNode 的過程，稱之為 Rack Awareness。

默認(rèn)的 Hadoop 按照所有的DataNode 屬于同一個(gè) Rack。這樣就容易出問題，而打開 Awareness之后，效果類似下面這個(gè)圖，

我們保存文件的時(shí)候，文件會(huì)被分成以128M為大小的 Block，之然通過NameNode來獲得具體保存數(shù)據(jù)的DataNode 地址，默認(rèn)是3 個(gè)備份，遵循的原則是「每個(gè)block，兩個(gè)備份存在同一個(gè) rack，第三個(gè)備份存在另一個(gè)不同的rack上」。這一規(guī)則也稱為 Replica Placement Policy。

具體存放時(shí)如何確定放到哪個(gè)rack上?我們前面提到是通過 rack id 來判斷的， HDFS 內(nèi)部是可以通過執(zhí)行一個(gè)外部腳本或者是在配置文件中指定一個(gè) Java類來獲得。

以下是官方文檔給出的一個(gè)python 的例子

為什么需要 Rack Awareness?

• 可以保證數(shù)據(jù)的高可用和可依賴性
• 提升集群的性能
• 在整個(gè) Rack 出現(xiàn)故障時(shí)避免數(shù)據(jù)丟失