大規(guī)模分布式系統(tǒng)的容錯架構(gòu)設(shè)計

假設(shè)有一個數(shù)據(jù)庫，數(shù)據(jù)庫里有一張?zhí)貏e大的表，里面有幾十億，甚至上百億的數(shù)據(jù)。更進一步說，假設(shè)這一張表的數(shù)據(jù)量多達幾十個 TB，甚至上百個 TB，那么如果用 MySQL 之類的數(shù)據(jù)庫，單臺數(shù)據(jù)庫服務(wù)器上的磁盤可能都不夠放這一張表的數(shù)據(jù)！

假如你手頭有一個超大的數(shù)據(jù)集，幾百 TB！那你還是別考慮傳統(tǒng)的數(shù)據(jù)庫技術(shù)來存放了。因為用一臺數(shù)據(jù)庫服務(wù)器可能根本都放不下，所以我們考慮一下分布式存儲技術(shù)？對了！這才是解決這個問題的辦法。

咱們完全可以搞多臺機器嘛！比如搞 20 臺機器，每臺機器上就放 $1/20$ 的數(shù)據(jù)。舉個例子，比如總共 20TB 的數(shù)據(jù)，在每臺機器上只要把 1TB 就可以了，1TB 應(yīng)該還好吧？每臺機器都可以輕松加愉快的放下這么多數(shù)據(jù)了。

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

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

比如說經(jīng)典的 Hadoop 就是這類系統(tǒng)，然后 FastDFS 也是類似的。如果你可以腦洞打開，從思想本質(zhì)共通的層面出發(fā)，那你會發(fā)現(xiàn)，其實類似 Elasticsearch、Redis Cluster 等等系統(tǒng)，本質(zhì)都是如此。這些都是基于分布式的系統(tǒng)架構(gòu)，把超大數(shù)據(jù)拆分成多片給你存放在多臺機器上。

咱們這篇文章是從分布式系統(tǒng)架構(gòu)層面出發(fā)，不拘泥于任何一種技術(shù)，所以姑且可以設(shè)定：這套分布式存儲系統(tǒng)，有兩種進程。

• 一個進程是 Master 節(jié)點，就在一臺機器上，負責統(tǒng)一管控分散在多臺機器上的數(shù)據(jù)。
• 另外一批進程叫做 Slave 節(jié)點，每臺機器上都有一個 Slave 節(jié)點，負責管理那臺機器上的數(shù)據(jù)，跟 Master 節(jié)點進行通信。

這個時候又有一個問題了，那么萬一上面那 20 臺機器上，其中 1 臺機器宕機了咋整呢？這就尷尬了，兄弟，這會導(dǎo)致本來完整的一份 20TB 的數(shù)據(jù)，最后有 19TB 還在了，有 1TB 的數(shù)據(jù)就搞丟了，因為那臺機器宕機了啊。所以說你當然不能允許這種情況的發(fā)生，這個時候就必須做一個數(shù)據(jù)副本的策略。

比如說，我們完全可以給每一臺機器上的那 1TB 的數(shù)據(jù)做 2 個副本的冗余，放在別的機器上，然后呢，萬一說某一臺機器宕機，沒事啊，因為其他機器上還有他的副本。我們來看看這種多副本冗余的架構(gòu)設(shè)計圖。

上面那個圖里的深藍色的 1TB 數(shù)據(jù) 01，代表的是 20TB 數(shù)據(jù)集中的第一個 1TB 數(shù)據(jù)分片。從上圖中可以看到，它有 3 個副本，分別在三臺機器中都有淺藍色的方塊，代表了它的三個副本。這樣的話，一份數(shù)據(jù)就有了 3 個副本了。其他的數(shù)據(jù)也是類似。

這個時候我們假設(shè)有一臺機器宕機了，比如下面這臺機器宕機，必然會導(dǎo)致 1TB 數(shù)據(jù) 01 這個數(shù)據(jù)分片的其中一個數(shù)據(jù)副本丟失。如下圖所示：

那這個時候要緊嗎？不要緊，因為 1TB 數(shù)據(jù) 01 這個數(shù)據(jù)分片，他還有另外 2 個副本在存活的兩臺機器上呢！所以如果有人要讀取數(shù)據(jù)，完全可以從另外兩臺機器上隨便挑一個副本來讀取就可以了，數(shù)據(jù)不會丟的。

現(xiàn)在有一個問題，比如說有個兄弟要讀取 1TB 數(shù)據(jù) 01 這個數(shù)據(jù)分片，那么他就會找 Master 節(jié)點，說：你能不能告訴我 1TB 數(shù)據(jù) 01 這個數(shù)據(jù)分片人在哪里??？在哪臺機器上??？我需要讀他??！

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

但是現(xiàn)在的問題是，Master 節(jié)點此時還不知道 1TB 數(shù)據(jù) 01 的副本 3 已經(jīng)丟失了，那萬一 Master 節(jié)點還是通知人家去讀取一個已經(jīng)丟失的副本 3，肯定是不可以的。

所以，我們怎么才能讓 Master 節(jié)點知道副本 3 已經(jīng)丟失了呢？

其實也很簡單，每臺機器上負責管理數(shù)據(jù)的 Slave 節(jié)點，都每隔幾秒（比如說 1 秒）給 Master 節(jié)點發(fā)送一個 心跳。那么，一旦 Master 節(jié)點發(fā)現(xiàn)一段時間（比如說 30 秒內(nèi)）沒收到某個 Slave 節(jié)點發(fā)送過來的心跳，此時就會認為這個 Slave 節(jié)點所在機器宕機了，那臺機器上的數(shù)據(jù)副本都丟失了，然后 Master 節(jié)點就不會告訴別人去讀那個丟失的數(shù)據(jù)副本。

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

那么此時，Master 節(jié)點就可以通知人家去讀 1TB 數(shù)據(jù) 01 的副本 1 或者副本 2，哪個都行，因為那兩個副本其實還是在的。舉個例子，比如可以通知客戶端去讀副本 1，此時客戶端就可以找那臺機器上的 Slave 節(jié)點說要讀取那個副本 1。

這個時候又有另外一個問題，那就是 1TB 數(shù)據(jù) 01 這個數(shù)據(jù)分片此時只有副本 1 和副本 2 這兩個副本了，這就不足夠 3 個副本啊。因為我們預(yù)設(shè)的是每個數(shù)據(jù)分片都得有 3 個副本的。大家想想，此時如何給這個數(shù)據(jù)分片增加 1 個副本呢？

很簡單，Master 節(jié)點一旦感知到某臺機器宕機，就能感知到某個數(shù)據(jù)分片的副本數(shù)量不足了。此時，就會生成一個副本復(fù)制的任務(wù)，挑選另外一臺機器來從有副本的機器去復(fù)制一個副本。

比如看下面的圖，可以挑選第四臺機器從第二臺機器去復(fù)制一個副本。

但是，現(xiàn)在這個復(fù)制任務(wù)是有了，我們怎么讓機器 4 知道呢？其實也很簡單，機器 4 不是每秒都會發(fā)送一次心跳么？當機器 4 發(fā)送心跳過去的時候，Master 節(jié)點就通過心跳響應(yīng)把這個復(fù)制任務(wù)下發(fā)給機器 4，讓機器 4 從機器 2 復(fù)制一個副本好了。

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

看上圖，現(xiàn)在機器 4 上是不是又多了一個 1TB 數(shù)據(jù) 01 的副本 3 ？那么 1TB 數(shù)據(jù) 01 這個數(shù)據(jù)分片是不是又變成 3 個副本了？

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

沒關(guān)系，一旦 Master 節(jié)點感知到機器 3 復(fù)活，會發(fā)現(xiàn)副本數(shù)量過多，此時會生成一個刪除副本任務(wù)。他會在機器 3 發(fā)送心跳的時候，下發(fā)一個刪除副本的指令，讓機器 3 刪除自己本地多余的副本就可以了。這樣，就可以保持副本數(shù)量只有 3 個。

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

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

所以筆者在這里強烈建議大家，一定好好吸收一下這種分布式系統(tǒng)、中間件系統(tǒng)底層數(shù)據(jù)容錯架構(gòu)的思想。文章來源地址http://www.zghlxwxcb.cn/news/detail-445253.html

到了這里，關(guān)于【軟件開發(fā)】大規(guī)模分布式系統(tǒng)的容錯架構(gòu)設(shè)計的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！