雖然定位是有“分布式”、“容錯架構”等看起來略顯復雜的字眼，但是咱們還是按照老規矩：大白話 + 手繪數張彩圖，逐步遞進，讓每個同學都能看懂這種復雜架構的設計思想。

TB 級數據放在一臺機器上：難啊!

咱們就用分布式存儲系統舉例，來聊一下容錯架構的設計。

首先，我們來瞧瞧，到底啥是分布式存儲系統呢?其實特別的簡單，咱們就用數據庫里的一張表來舉例。

比如你手頭有個數據庫，數據庫里有一張特別大的表，里面有幾十億，甚至上百億的數據。

更進一步說，假設這一張表的數據量多達幾十個 TB，甚至上百個 TB，這時你覺得咋樣?

當然是內心感到恐慌和無助了，因為如果你用 MySQL 之類的數據庫，單臺數據庫服務器上的磁盤可能都不夠放這一張表的數據!

咱們就來看看下面的這張圖，來感受一下：

到底啥是分布式存儲?

所以，假如你手頭有一個超大的數據集，幾百 TB!那你還是別考慮傳統的數據庫技術來存放了。

因為用一臺數據庫服務器可能根本都放不下，所以我們考慮一下分布式存儲技術?對了!這才是解決這個問題的辦法。

咱們完全可以搞多臺機器嘛!比如搞 20 臺機器，每臺機器上就放 1/20 的數據。

舉個例子，比如總共 20TB 的數據，在每臺機器上只要放 1TB 就可以了，1TB 應該還好吧?每臺機器都可以輕松加愉快的放下這么多數據了。

所以說，把一個超大的數據集拆分成多片，給放到多臺機器上去，這就是所謂的分布式存儲。

咱們再看看下面的圖：

那么啥又是分布式存儲系統呢?

那分布式存儲系統是啥呢?分布式存儲系統，當然就是負責把一個超大數據集拆分成多塊，然后放到多臺機器上來存儲，接著統一管理這些分散在多臺機器上存儲的數據的一套系統。

比如說經典的 Hadoop 就是這類系統，然后 FastDFS 也是類似的。如果你可以腦洞打開，從思想本質共通的層面出發，那你會發現，其實類似 Elasticsearch、Redis Cluster 等等系統，它們的本質都是如此。

這些都是基于分布式的系統架構，把超大數據拆分成多片給你存放在多臺機器上。

咱們這篇文章是從分布式系統架構層面出發，不拘泥于任何一種技術，所以姑且可以設定：這套分布式存儲系統，有兩種進程。

一個進程是 Master 節點，就在一臺機器上，負責統一管控分散在多臺機器上的數據。

另外一批進程叫做 Slave 節點，每臺機器上都有一個 Slave 節點，負責管理那臺機器上的數據，跟 Master 節點進行通信。

咱們看看下面的圖，通過圖再來直觀的看看上面的描述：

天哪!某臺機器宕機了咋辦?

這個時候又有一個問題了，那么萬一上面那 20 臺機器上，其中 1 臺機器宕機了咋整呢?

這就尷尬了，兄弟，這會導致本來完整的一份 20TB 的數據，***有 19TB 還在了，有 1TB 的數據就搞丟了，因為那臺機器宕機了啊。

所以說你當然不能允許這種情況的發生，這個時候就必須做一個數據副本的策略。

比如說，我們完全可以給每一臺機器上的那 1TB 的數據做 2 個副本的冗余，放在別的機器上，然后呢，萬一說某一臺機器宕機，沒事啊，因為其他機器上還有它的副本。

我們來看看這種多副本冗余的架構設計圖：

上面那個圖里的淺藍色的“1TB 數據 01”，代表的是 20TB 數據集中的***個 1TB 數據分片。

圖中可以看到，他就有 3 個副本，分別在三臺機器中都有淺藍色的方塊，代表了它的三個副本。

這樣的話，一份數據就有了 3 個副本了。其他的數據也是類似。這個時候我們假設有一臺機器宕機了，比如下面這臺機器宕機，必然會導致“1TB 數據 01”這個數據分片的其中一個數據副本丟失。

如下圖所示：

那這個時候要緊嗎?不要緊，因為“1TB 數據 01”這個數據分片，它還有另外 2 個副本在存活的兩臺機器上呢!

所以如果有人要讀取數據，完全可以從另外兩臺機器上隨便挑一個副本來讀取就可以了，數據不會丟的，不要緊張，大兄弟。

Master 節點如何感知到數據副本消失?

現在有一個問題，比如說有個兄弟要讀取“1TB 數據 01”這個數據分片，那么他就會找 Master 節點，說：“你能不能告訴我“1TB 數據 01”這個數據分片人在哪里啊?在哪臺機器上啊?我需要讀他啊!”

我們來看看下面的圖：

那么這個時候，Master 節點就需要從“1TB 數據 01”的 3 個副本里選擇一個出來，告訴人家說：“兄弟，在哪臺哪臺機器上，有 1 個副本，你可以去那臺機器上讀“1TB 數據 01”的一個副本就 ok 了。”

但是現在的問題是，Master 節點此時還不知道“1TB 數據 01”的副本 3 已經丟失了，那萬一 Master 節點還是通知人家去讀取一個已經丟失的副本 3，肯定是不可以的。

所以，我們怎么才能讓 Master 節點知道副本 3 已經丟失了呢?其實也很簡單，每臺機器上負責管理數據的 Slave 節點，都每隔幾秒(比如說 1 秒)給 Master 節點發送一個心跳。

那么，一旦 Master 節點發現一段時間(比如說 30 秒內)沒收到某個 Slave 節點發送過來的心跳，此時就會認為這個 Slave 節點所在機器宕機了，那臺機器上的數據副本都丟失了，然后 Master 節點就不會告訴別人去讀那個丟失的數據副本。

大家看看下面的圖，一旦 Slave 節點宕機，Master 節點收不到心跳，就會認為那臺機器上的副本 3 就已經丟失了，此時絕對不會讓別人去讀那臺宕機機器上的副本 3。

那么此時，Master 節點就可以通知人家去讀“1TB 數據 01”的副本 1 或者副本 2，哪個都行，因為那兩個副本其實還是在的。

舉個例子，比如可以通知客戶端去讀副本 1，此時客戶端就可以找那臺機器上的 Slave 節點說要讀取那個副本 1。

整個過程如下圖所示：

復制副本保持足夠副本數量

這個時候又有另外一個問題，那就是“1TB 數據 01”這個數據分片此時只有副本 1 和副本 2 這兩個副本了，這就不足夠 3 個副本啊。

因為我們預設的是每個數據分片都得有 3 個副本的。大家想想，此時如何給這個數據分片增加 1 個副本呢?

很簡單，Master 節點一旦感知到某臺機器宕機，就能感知到某個數據分片的副本數量不足了。

此時，就會生成一個副本復制的任務，挑選另外一臺機器來從有副本的機器去復制一個副本。

比如看下面的圖，可以挑選第 4 臺機器從第 2 臺機器去復制一個副本：

但是，現在這個復制任務是有了，我們怎么讓機器 4 知道呢?其實也很簡單，機器 4 不是每秒都會發送一次心跳么?

當機器 4 發送心跳過去的時候，Master 節點就通過心跳響應把這個復制任務下發給機器 4，讓機器 4 從機器 2 復制一個副本好了。

同樣，我們來一張圖，看看這個過程：

看上圖，現在機器 4 上是不是又多了一個“1TB 數據 01”的副本 3?那么“1TB 數據 01”這個數據分片是不是又變成 3 個副本了?

刪除多余副本

那反過來，如果說此時機器 3 突然恢復了，他上面也有一個“1TB 數據 01”的副本 3，相當于此時“1TB 數據 01”就有 4 個副本了，副本不就多余了嗎?

沒關系，一旦 Master 節點感知到機器 3 復活，會發現副本數量過多，此時會生成一個刪除副本任務。

他會在機器 3 發送心跳的時候，下發一個刪除副本的指令，讓機器 3 刪除自己本地多余的副本就可以了。這樣，就可以保持副本數量只有 3 個。

一樣的，大家來看看下面的圖：

總結

好了，到這里，通過超級大白話的講解，還有十多張圖的漸進式演進說明，相信大家以前即使不了解分布式系統，都絕對能理解一個分布式系統的完整的數據容錯架構是如何設計的了。

實際上，這種數據分片存儲 、多副本冗余、宕機感知、自動副本遷移、多余副本刪除，這套機制，對于 Hadoop、Elasticsearch 等很多系統來說，都是類似的。

所以筆者在這里強烈建議大家，一定好好吸收一下這種分布式系統、中間件系統底層數據容錯架構的思想。

這樣，以后學習類似的一些技術的時候，對他們的原理、思想都會感到一種似曾相識的感覺。