歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）
週一至週五早8點半！精品技術文章準時送上！
目錄
（1）TB級資料放在一臺機器上：難啊！
（2）到底啥是分散式儲存？
（3）那啥又是分散式儲存系統呢？
（4）天哪！某臺機器當機了咋辦？
（5）Master節點如何感知到資料副本消失？
（6）如何複製副本保持足夠副本數量
（7）刪除多餘副本又該怎麼做呢？
（8）全文總結
“ 這篇文章，我們將用非常淺顯易懂的語言，跟大家聊聊大規模分散式系統的容錯架構設計。雖然定位是有“分散式”、“容錯架構”等看起來略顯複雜的字眼，但是我們們還是按照老規矩：大白話 + 手繪數張彩圖，逐步遞進，讓每個同學都能看懂這種複雜架構的設計思想。
1、TB級資料放在一臺機器上：難啊！
我們們就用分散式儲存系統舉例，來聊一下容錯架構的設計。
首先，我們來瞧瞧，到底啥是分散式儲存系統呢？
其實特別的簡單，我們們就用資料庫裡的一張表來舉例。
比如你手頭有個資料庫，資料庫裡有一張特別大的表，裡面有幾十億，甚至上百億的資料。
更進一步說，假設這一張表的資料量多達幾十個TB，甚至上百個TB，這時你覺得咋樣？
當然是內心感到恐慌和無助了，因為如果你用MySQL之類的資料庫，單臺資料庫伺服器上的磁碟可能都不夠放這一張表的資料！
我們們就來看看下面的這張圖，來感受一下。
2、到底啥是分散式儲存？
所以，假如你手頭有一個超大的資料集，幾百TB！那你還是別考慮傳統的資料庫技術來存放了。
因為用一臺資料庫伺服器可能根本都放不下，所以我們考慮一下分散式儲存技術？對了！這才是解決這個問題的辦法。
我們們完全可以搞多臺機器嘛！比如搞20臺機器，每臺機器上就放1/20的資料。
舉個例子，比如總共20TB的資料，在每臺機器上只要把1TB就可以了，1TB應該還好吧？每臺機器都可以輕鬆加愉快的放下這麼多資料了。
所以說，把一個超大的資料集拆分成多片，給放到多臺機器上去，這就是所謂的分散式儲存。
我們們再看看下面的圖。
3、那麼啥又是分散式儲存系統呢？
那分散式儲存系統是啥呢？
分散式儲存系統，當然就是負責把一個超大資料集拆分成多塊，然後放到多臺機器上來儲存，接著統一管理這些分散在多臺機器上儲存的資料的一套系統。
比如說經典的hadoop就是這類系統，然後fastdfs也是類似的。
如果你可以腦洞開啟，從思想本質共通的層面出發，那你會發現，其實類似elasticsearch、redis cluster等等系統，他本質都是如此。
這些都是基於分散式的系統架構，把超大資料拆分成多片給你存放在多臺機器上。
我們們這篇文章是從分散式系統架構層面出發，不拘泥於任何一種技術，所以姑且可以設定：這套分散式儲存系統，有兩種程式。
一個程式是Master節點，就在一臺機器上，負責統一管控分散在多臺機器上的資料。
另外一批程式叫做Slave節點，每臺機器上都有一個Slave節點，負責管理那臺機器上的資料，跟Master節點進行通訊。
我們們看看下面的圖，通過圖再來直觀的看看上面的描述。
4、天哪！某臺機器當機了咋辦？
這個時候又有一個問題了，那麼萬一上面那20臺機器上，其中1臺機器當機了咋整呢？
這就尷尬了，兄弟，這會導致本來完整的一份20TB的資料，最後有19TB還在了，有1TB的資料就搞丟了，因為那臺機器當機了啊。
所以說你當然不能允許這種情況的發生，這個時候就必須做一個資料副本的策略。
比如說，我們完全可以給每一臺機器上的那1TB的資料做2個副本的冗餘，放在別的機器上，然後呢，萬一說某一臺機器當機，沒事啊，因為其他機器上還有他的副本。
我們來看看這種多副本冗餘的架構設計圖。
上面那個圖裡的淺藍色的“1TB資料01”，代表的是20TB資料集中的第一個1TB資料分片。
圖中可以看到，他就有3個副本，分別在三臺機器中都有淺藍色的方塊，代表了他的三個副本。
這樣的話，一份資料就有了3個副本了。其他的資料也是類似。
這個時候我們假設有一臺機器當機了，比如下面這臺機器當機，必然會導致“1TB資料01”這個資料分片的其中一個資料副本丟失。如下圖所示：
那這個時候要緊嗎？不要緊，因為“1TB資料01”這個資料分片，他還有另外2個副本在存活的兩臺機器上呢！
所以如果有人要讀取資料，完全可以從另外兩臺機器上隨便挑一個副本來讀取就可以了，資料不會丟的，不要緊張，大兄弟。
5、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。
整個過程如下圖所示。
6、複製副本保持足夠副本數量
這個時候又有另外一個問題，那就是“1TB資料01”這個資料分片此時只有副本1和副本2這兩個副本了，這就不足夠3個副本啊。
因為我們預設的是每個資料分片都得有3個副本的。大家想想，此時如何給這個資料分片增加1個副本呢？
很簡單，Master節點一旦感知到某臺機器當機，就能感知到某個資料分片的副本數量不足了。
此時，就會生成一個副本複製的任務，挑選另外一臺機器來從有副本的機器去複製一個副本。
比如看下面的圖，可以挑選第四臺機器從第二臺機器去複製一個副本。
但是，現在這個複製任務是有了，我們怎麼讓機器4知道呢？
其實也很簡單，機器4不是每秒都會傳送一次心跳麼？當機器4傳送心跳過去的時候，Master節點就通過心跳響應把這個複製任務下發給機器4，讓機器4從機器2複製一個副本好了。
同樣，我們來一張圖，看看這個過程：
看上圖，現在機器4上是不是又多了一個“1TB資料01”的副本3 ？那麼“1TB資料01”這個資料分片是不是又變成3個副本了？
7、刪除多餘副本
那反過來，如果說此時機器3突然恢復了，他上面也有一個“1TB資料01”的副本3，相當於此時“1TB資料01”就有4個副本了，副本不就多餘了嗎？
沒關係，一旦Master節點感知到機器3復活，會發現副本數量過多，此時會生成一個刪除副本任務。
他會在機器3傳送心跳的時候，下發一個刪除副本的指令，讓機器3刪除自己本地多餘的副本就可以了。這樣，就可以保持副本數量只有3個。
一樣的，大家來看看下面的圖。
8、全文總結
好了，到這裡，通過超級大白話的講解，還有十多張圖的漸進式演進說明，相信大家以前即使不瞭解分散式系統，都絕對能理解一個分散式系統的完整的資料容錯架構是如何設計的了。
實際上，這種資料分片儲存 、多副本冗餘、當機感知、自動副本遷移、多餘副本刪除，這套機制，對於hadoop、elasticsearch等很多系統來說，都是類似的。
所以筆者在這裡強烈建議大家，一定好好吸收一下這種分散式系統、中介軟體系統底層資料容錯架構的思想。
這樣，以後學習類似的一些技術的時候，對他們的原理、思想都會感到一種似曾相識的感覺。
End
如有收穫，請幫忙轉發，您的鼓勵是作者最大的動力，謝謝！
一大波微服務、分散式、高併發、高可用的原創系列文章正在路上
歡迎掃描下方二維碼，持續關注：
石杉的架構筆記（id:shishan100）
十餘年BAT架構經驗傾囊相授
推薦閱讀：
2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
9、【坑爹呀！】最終一致性分散式事務如何保障實際生產中99.99%高可用？
11、【眼前一亮！】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上？
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
18、大白話聊聊Java併發面試問題之volatile到底是什麼？
19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能？
20、大白話聊聊Java併發面試問題之談談你對AQS的理解？
21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？
22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
23、網際網路公司的面試官是如何360°無死角考察候選人的？（上篇）
24、網際網路公司面試官是如何360°無死角考察候選人的？（下篇）
25、Java進階面試系列之一：哥們，你們的系統架構中為什麼要引入訊息中介軟體？
26、【Java進階面試系列之二】：哥們，那你說說系統架構引入訊息中介軟體有什麼缺點？
27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷
28、【Java進階面試系列之三】哥們，訊息中介軟體在你們專案裡是如何落地的？
29、【Java進階面試系列之四】扎心！線上服務當機時，如何保證資料100%不丟失？
30、一次JVM FullGC的背後，竟隱藏著驚心動魄的線上生產事故！
31、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？
32、【Java進階面試系列之五】訊息中介軟體叢集崩潰，如何保證百萬生產資料不丟失？
33、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（上）？
34、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？
35、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（下）？
37、億級流量系統架構之如何保證百億流量下的資料一致性（上）
38、億級流量系統架構之如何保證百億流量下的資料一致性（中）？
39、億級流量系統架構之如何保證百億流量下的資料一致性（下）？
40、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（1）
41、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（2）
42、面試大殺器：訊息中介軟體如何實現消費吞吐量的百倍優化？
43、高併發場景下，如何保證生產者投遞到訊息中介軟體的訊息不丟失？
作者：石杉的架構筆記 連結：juejin.im/post/5c263a… 來源：掘金 著作權歸作者所有，轉載請聯絡作者獲得授權！