資料庫腦裂

1. HDFS 為何在大數據領域經久不衰

大數據中最寶貴、最難以代替的就是數據，一切都圍繞數據。

HDFS是最早的大數據存儲系統，存儲著寶貴的數據資產，各種新演算法、框架要想得到廣泛使用，必須支持HDFS，才能獲取已存儲在裡面的數據。所以大數據技術越發展，新技術越多，HDFS得到的支持越多，越離不開HDFS。 HDFS也許不是最好的大數據存儲技術，但依然是最重要的大數據存儲技術 。

HDFS是如何實現大數據高速、可靠的存儲和訪問的呢？

Hadoop分布式文件系統HDFS的設計目標是管理數以千計的伺服器、數以萬計的磁碟，將大規模的伺服器計算資源當作一個單一存儲系統進行管理，對應用程序提供數以PB計的存儲容量，讓應用程序像使用普通文件系統一樣存儲大規模的文件數據。

文件以多副本的方式進行存儲：

缺點：

優點：

HDFS的大容量存儲和高速訪問的實現。

RAID將數據分片後，在多塊磁碟上並發進行讀寫訪問，提高了存儲容量、加快了訪問速度，並通過數據冗餘校驗提高了數據可靠性，即使某塊磁碟損壞也不會丟數據。將RAID的設計理念擴大到整個分布式伺服器集群，就產生了分布式文件系統，這便是Hadoop分布式文件系統的核心原理。

和RAID在多個磁碟上進行文件存儲及並行讀寫的思路一樣，HDFS是在一個大規模分布式伺服器集群上，對數據分片後進行並行讀寫及冗餘存儲。因為HDFS可部署在一個大的伺服器集群，集群中所有伺服器的磁碟都可供HDFS使用，所以整個HDFS的存儲空間可以達到PB級。

HDFS是主從架構。一個HDFS集群會有一個NameNode（命名節點，簡稱NN），作為主伺服器（master server）。

HDFS公開了文件系統名稱空間，允許用戶將數據存儲在文件中，就好比我們平時使用os中的文件系統一樣，用戶無需關心底層是如何存儲數據的。 在底層，一個文件會被分成一或多個數據塊，這些資料庫塊會被存儲在一組數據節點中。在CDH中數據塊的默認128M。 在NameNode，可執行文件系統的命名空間操作，如打開，關閉，重命名文件等。這也決定了數據塊到數據節點的映射。

HDFS被設計為可運行在普通的廉價機器上，而這些機器通常運行著一個Linux操作系統。一個典型的HDFS集群部署會有一個專門的機器只能運行 NameNode ，而其他集群中的機器各自運行一個 DataNode 實例。雖然一台機器上也可以運行多個節點，但不推薦。

負責文件數據的存儲和讀寫操作，HDFS將文件數據分割成若干數據塊（Block），每個DataNode存儲一部分Block，這樣文件就分布存儲在整個HDFS伺服器集群中。

應用程序客戶端（Client）可並行訪問這些Block，從而使得HDFS可以在伺服器集群規模上實現數據並行訪問，極大提高訪問速度。

HDFS集群的DataNode伺服器會有很多台，一般在幾百台到幾千台，每台伺服器配有數塊磁碟，整個集群的存儲容量大概在幾PB~數百PB。

負責整個分布式文件系統的元數據（MetaData）管理，即文件路徑名、數據塊的ID以及存儲位置等信息，類似os中的文件分配表（FAT）。

HDFS為保證數據高可用，會將一個Block復制為多份（默認3份），並將多份相同的Block存儲在不同伺服器，甚至不同機架。當有磁碟損壞或某個DataNode伺服器宕機，甚至某個交換機宕機，導致其存儲的數據塊不能訪問時，客戶端會查找其備份Block訪問。

HDFS中，一個文件會被拆分為一個或多個數據塊。默認每個數據塊有三個副本，每個副本都存放在不同機器，而且每一個副本都有自己唯一的編號：

文件/users/sameerp/data/part-0的復制備份數設為2，存儲的BlockID分別為1、3：

上述任一台伺服器宕機後，每個數據塊都至少還有一個備份存在，不會影響對文件/users/sameerp/data/part-0的訪問。

和RAID一樣，數據分成若干Block後，存儲到不同伺服器，實現數據大容量存儲，並且不同分片的數據能並行進行讀/寫操作，實現數據的高速訪問。

副本存放：NameNode節點選擇一個DataNode節點去存儲block副本的過程，該過程的策略是在可靠性和讀寫帶寬間權衡。

《Hadoop權威指南》中的默認方式：

Google大數據「三駕馬車」的第一駕是GFS（Google 文件系統），而Hadoop的第一個產品是HDFS，分布式文件存儲是分布式計算的基礎。

這些年來，各種計算框架、各種演算法、各種應用場景不斷推陳出新，但大數據存儲的王者依然是HDFS。

磁碟介質在存儲過程中受環境或者老化影響，其存儲的數據可能會出現錯亂。

HDFS對存儲在DataNode上的數據塊，計算並存儲校驗和（CheckSum）。在讀數據時，重新計算讀取出來的數據的校驗和，校驗不正確就拋異常，應用程序捕獲異常後就到其他DataNode上讀取備份數據。

DataNode監測到本機的某塊磁碟損壞，就將該塊磁碟上存儲的所有BlockID報告給NameNode，NameNode檢查這些數據塊還在哪些DataNode上有備份，通知相應的DataNode伺服器將對應的數據塊復制到其他伺服器上，以保證數據塊的備份數滿足要求。

DataNode會通過心跳和NameNode保持通信，如果DataNode超時未發送心跳，NameNode就會認為這個DataNode已經宕機失效，立即查找這個DataNode上存儲的數據塊有哪些，以及這些數據塊還存儲在哪些伺服器上，隨後通知這些伺服器再復制一份數據塊到其他伺服器上，保證HDFS存儲的數據塊備份數符合用戶設置的數目，即使再出現伺服器宕機，也不會丟失數據。

NameNode是整個HDFS的核心，記錄著HDFS文件分配表信息，所有的文件路徑和數據塊存儲信息都保存在NameNode，如果NameNode故障，整個HDFS系統集群都無法使用；如果NameNode上記錄的數據丟失，整個集群所有DataNode存儲的數據也就沒用了。

所以，NameNode高可用容錯能力非常重要。NameNode採用主從熱備的方式提供高可用服務：

集群部署兩台NameNode伺服器：

兩台伺服器通過Zk選舉，主要是通過爭奪znode鎖資源，決定誰是主伺服器。而DataNode則會向兩個NameNode同時發送心跳數據，但是只有主NameNode才能向DataNode返回控制信息。

正常運行期，主從NameNode之間通過一個共享存儲系統shared edits來同步文件系統的元數據信息。當主NameNode伺服器宕機，從NameNode會通過ZooKeeper升級成為主伺服器，並保證HDFS集群的元數據信息，也就是文件分配表信息完整一致。

軟體系統，性能差點，用戶也許可接受；使用體驗差，也許也能忍受。但若可用性差，經常出故障不可用，就麻煩了；如果出現重要數據丟失，那開發攤上大事。

而分布式系統可能出故障地方又非常多，內存、CPU、主板、磁碟會損壞，伺服器會宕機，網路會中斷，機房會停電，所有這些都可能會引起軟體系統的不可用，甚至數據永久丟失。

所以在設計分布式系統的時候，軟體工程師一定要綳緊可用性這根弦，思考在各種可能的故障情況下，如何保證整個軟體系統依然是可用的。

## 6 保證系統可用性的策略

任何程序、任何數據，都至少要有一個備份，也就是說程序至少要部署到兩台伺服器，數據至少要備份到另一台伺服器上。此外，稍有規模的互聯網企業都會建設多個數據中心，數據中心之間互相進行備份，用戶請求可能會被分發到任何一個數據中心，即所謂的異地多活，在遭遇地域性的重大故障和自然災害的時候，依然保證應用的高可用。

當要訪問的程序或者數據無法訪問時，需要將訪問請求轉移到備份的程序或者數據所在的伺服器上，這也就是 失效轉移 。失效轉移你應該注意的是失效的鑒定，像NameNode這樣主從伺服器管理同一份數據的場景，如果從伺服器錯誤地以為主伺服器宕機而接管集群管理，會出現主從伺服器一起對DataNode發送指令，進而導致集群混亂，也就是所謂的「腦裂」。這也是這類場景選舉主伺服器時，引入ZooKeeper的原因。ZooKeeper的工作原理，我將會在後面專門分析。

當大量的用戶請求或者數據處理請求到達的時候，由於計算資源有限，可能無法處理如此大量的請求，進而導致資源耗盡，系統崩潰。這種情況下，可以拒絕部分請求，即進行 限流 ；也可以關閉部分功能，降低資源消耗，即進行 降級 。限流是互聯網應用的常備功能，因為超出負載能力的訪問流量在何時會突然到來，你根本無法預料，所以必須提前做好准備，當遇到突發高峰流量時，就可以立即啟動限流。而降級通常是為可預知的場景准備的，比如電商的「雙十一」促銷，為了保障促銷活動期間應用的核心功能能夠正常運行，比如下單功能，可以對系統進行降級處理，關閉部分非重要功能，比如商品評價功能。

HDFS是如何通過大規模分布式伺服器集群實現數據的大容量、高速、可靠存儲、訪問的。

1.文件數據以數據塊的方式進行切分，數據塊可以存儲在集群任意DataNode伺服器上，所以HDFS存儲的文件可以非常大，一個文件理論上可以占據整個HDFS伺服器集群上的所有磁碟，實現了大容量存儲。

2.HDFS一般的訪問模式是通過MapRece程序在計算時讀取，MapRece對輸入數據進行分片讀取，通常一個分片就是一個數據塊，每個數據塊分配一個計算進程，這樣就可以同時啟動很多進程對一個HDFS文件的多個數據塊進行並發訪問，從而實現數據的高速訪問。關於MapRece的具體處理過程，我們會在專欄後面詳細討論。

3.DataNode存儲的數據塊會進行復制，使每個數據塊在集群里有多個備份，保證了數據的可靠性，並通過一系列的故障容錯手段實現HDFS系統中主要組件的高可用，進而保證數據和整個系統的高可用。

2. 【Redis集群專題】「集群三部曲」分析一下相關的Redis集群模式下的腦裂問題（問題篇）

技術格言：追求完美的過程沒有終點，每一次嘗試都讓我們更接近理想。

腦裂的字面意義是指思想分家，形成了兩個對立的觀念或行動路線。在高可用集群中，如果兩台伺服器在一定時間內因網路原因無法互相檢測心跳，各自啟動故障轉移，導致服務所有權沖突，形成同時運行的情況，就是腦裂問題。這種情況下，服務兩端可能同時佔用同一VIP地址，用戶數據可能被不一致地寫入，從而引發數據丟失或不完整。

腦裂問題可能導致數據不完整，當外部無法確定主節點時，集群兩端均能正常訪問，數據一致性難以保證。引發腦裂的原因可能包括心跳線路故障、軟體層面問題等。

生產環境應預防腦裂，通過監控心跳線路、升級軟體版本、優化網路結構等手段實現。

Redis腦裂現象指的是兩個master節點同時存在的情況。在哨兵模式下，當master與部分slave和哨兵之間出現網路故障，但其餘slave與哨兵通信正常時，可能存在腦裂。應用伺服器連接到不同master導致數據不一致，分布式鎖和全局唯一id生成可能出錯。

集群模式下的腦裂更復雜，涉及多分片節點，網路分區可能導致數據不一致問題。手動處理腦裂時，需要人工檢測網路狀況，確保只有一個master運行，但此方法操作繁瑣。

自動處理腦裂依賴哨兵機制，哨兵檢測master狀態，自動選舉新master以實現故障轉移。然而，哨兵與slave之間的連接故障可能導致腦裂，新老master同步數據時，舊master數據丟失。

解決腦裂問題，可設置master限制slave數量，並調整redis配置文件中的參數，以減少數據丟失。新版本的redis配置文件調整了參數設置，以適應非同步復制情況下的數據一致性。

盡管官方文檔強調Redis集群並非強一致性系統，對於強一致性要求的應用，傳統關系型資料庫（RDBMS）可能是更佳選擇。