[[312241]]

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

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

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

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

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

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

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

你肯定憤怒的問客服為啥不再多存幾份?？扇绻钦麄€硬盤所在機架都掛了呢?

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

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

「狡兔三窟」。 :-)

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

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

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

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

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

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

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

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

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

以下是官方文檔給出的一個python 的例子

為什么需要 Rack Awareness?

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