主備、主從、和主主架構都基于一個共同的前提：主機需要有能力存儲所有數據。然而，主機的存儲和處理容量是有限的。以歷史發展為例，Intel 386時代的服務器僅能存儲幾百MB數據，到了Intel奔騰時代則能夠存儲幾十GB，而進入Intel酷睿多核時代后，服務器的存儲能力增加到了數TB。盡管從硬件發展角度看，存儲能力的提升速度相當快，但與業務需求的增長速度相比，這種提升還是遠遠不夠。例如，截至2013年，Facebook已經累計存儲了2500億張照片，總容量達到250PB（250×1024TB），日均上傳量達到3億5000萬張圖片。這種龐大的數據量顯然無法由單臺服務器來存儲和處理，因此必須依賴多臺服務器的集群架構來實現。

簡而言之，集群是由多臺機器組成的一個統一系統，這里的“多臺”通常指的是至少3臺機器。與主備或主從架構的兩臺機器相比，集群提供了更大的擴展性。集群可以根據其中機器承擔的角色不同分為兩種類型：數據集中型集群和數據分散型集群。

數據集中集群

數據集中集群與主備、主從這類架構相似，我們也可以稱數據集中集群為 1 主多備或者 1 主多從。無論是 1 主 1 從、1 主 1 備，還是 1 主多備、1 主多從，數據都只能往主機中寫，而讀操作可以參考主備、主從架構進行靈活多變。下圖是讀寫全部到主機的一種架構：

圖片

在主備和主從架構中，數據通常通過單一的復制通道從主機復制到備機。然而，在數據集中集群架構中，存在多個復制通道，這可能會增加主機的復制負擔。在某些情形下，減輕主機的復制負擔或減少復制操作對正常讀寫活動的影響是必要的。

此外，多個復制通道可能會導致不同備機之間的數據出現不一致。在這種情況下，需要對各備機之間的數據一致性進行驗證和調整。

對于備機如何判斷主機的狀態，主備和主從架構中只涉及單臺備機的狀態判斷。但在數據集中集群架構中，多臺備機都需要對主機狀態做出判斷，且不同備機的判斷結果可能不一致，處理這些不一致的判斷是一個復雜的問題。

當主機發生故障時，如何決定新的主機也是一個關鍵問題。在主從架構中，通常直接將備機升級為主機。然而，在數據集中集群架構中，由于存在多臺可升級的備機，必須決定哪一臺備機最適合成為新的主機，以及備機之間如何進行協調。

ZooKeeper是一個典型的開源數據集中集群解決方案，它通過ZAB算法來解決這些問題，盡管ZAB算法相當復雜。

對于數據分散集群，這種結構涉及多臺服務器，每臺服務器存儲部分數據并備份其他部分數據。數據分散集群面臨的復雜性在于如何將數據恰當地分配到不同服務器上。這涉及到以下幾個設計要素：

• 均衡性：分配算法必須確保數據在各服務器之間的分布大體均衡，避免某臺服務器的數據量顯著高于其他服務器。
• 容錯性：當部分服務器出現故障時，算法需要能夠將受影響的數據區重新分配給其他服務器。
• 可伸縮性：當需要擴展集群容量時，算法應能自動將數據遷移到新增的服務器上，并確保擴容后數據依然均衡分布。

與數據集中集群不同，數據分散集群中的每臺服務器都能處理讀寫請求，因此不存在像數據集中集群中那樣的專門負責寫操作的主機角色。然而，在數據分散集群中，需要有一個特定角色負責執行數據分配算法，這個角色可能是一臺獨立服務器，也可能是由集群內部選舉產生的服務器。如果是后者，這臺服務器通常也被稱為主機，但其職責與數據集中集群中的主機職責有所不同。

Hadoop 的實現就是獨立的服務器負責數據分區的分配，這臺服務器叫作Namenode。Hadoop 的數據分區管理架構如下：

圖片

與 Hadoop 不同的是，Elasticsearch 集群通過選舉一臺服務器來做數據分區的分配，叫作 master node，其數據分區管理架構是：

圖片

在集群架構中，數據集中型集群只允許客戶端將數據寫入主節點，而數據分散型集群允許客戶端在任何服務器上進行讀寫操作。這一關鍵差異決定了兩種架構適用于不同的應用場景。數據集中型集群通常適用于數據量較小、服務器數量較少的情況，如ZooKeeper集群，通常建議使用約5臺服務器，且每臺服務器的數據量是可管理的。相反，數據分散型集群因其優越的可擴展性，更適合處理大量業務數據和大規模服務器群，如Hadoop和HBase集群，這些集群可包含數百甚至數千臺服務器。

數據分區

在考慮存儲高可用架構時，我們通常關注的是如何在硬件故障發生時維持系統的運行。然而，對于可能導致所有硬件同時故障的重大災害或事故，如新奧爾良的水災、美加大范圍停電、洛杉磯的大地震等，單純基于硬件故障的高可用架構可能不足以應對。在這種情況下，需要設計可以抵抗地理級別故障的高可用架構，這正是數據分區架構的來源。

數據分區架構通過按照特定規則將數據分布在不同的地理位置來避免地理級別的故障帶來的重大影響。這種架構確保即使某一地區遭受重大災害，也只有部分數據受到影響，而非全部數據。一旦地區故障恢復，其他地區的備份數據可以快速恢復受影響地區的業務運行。

設計有效的數據分區架構需要綜合考慮多個方面：

1.數據量數據量的大小決定了分區復雜性

例如，假設每臺MySQL服務器的存儲能力為500GB，那么2TB的數據需要至少4臺服務器。但對于200TB的數據，簡單地增加到800臺MySQL服務器將極大增加管理復雜度。例如，可能每周都有服務器故障，從800臺服務器中找出故障的那一兩臺并不簡單，同時，運維復雜度也會顯著提高。在地理分布上，若數據集中在一個城市，一旦發生大型災難，風險極高。

2.分區規則

分區可以按照洲際、國家或城市等級別進行，具體采取哪種規則取決于業務需求和成本考慮。洲際分區適用于服務不同大洲的用戶，由于網絡延遲較大，通常用作數據備份而非實時服務。國家分區適合針對具有不同語言、法律需求的國家，通常也主要用于數據備份。城市分區則適合在同一國家或地區內提供低延遲服務，適用于異地多活等需求。

3.復制規則

即使采用了數據分區架構，每個分區仍然需要處理大量數據。單一分區的數據損壞或丟失仍然是無法接受的。因此，即使在分區架構中，也必須實施數據復制策略，以確保數據的安全和高可用性。

常見的分區復制規則有三種：集中式、互備式和獨立式。

集中式備份

集中式備份系統設有一個主要的備份中心，所有的分區都將其數據傳輸至該中心進行備份。此架構的優點包括設計的簡潔性，由于分區之間沒有直接的聯系，各自獨立運作，互不干擾。此外，擴展性也較高，若需要添加新的分區，如武漢分區，僅需將其數據備份到已有的西安備份中心，不影響其他分區。然而，這種方式的缺點是成本相對較高，因為需要建立和維護一個獨立的備份中心。

圖片

互備式備份

互備式備份要求每個分區備份另一個分區的數據。這種設計較為復雜，因為每個分區不僅要處理自己的業務數據還要負責備份工作，分區間存在相互影響和依賴。擴展此系統相對困難，例如引入武漢分區可能需要重新配置廣州分區的備份目標為武漢，同時還需處理原有的北京與廣州的備份數據，不論是數據遷移還是保留歷史數據都會帶來挑戰。但這種方法成本較低，因為它直接利用現有的設施。

獨立式備份

獨立式備份中，每個分區都擁有自己的備份中心，且備份中心不與原數據中心位于同一地點。例如，北京分區的備份設在天津，上海的備份設在杭州，廣州的則設在汕頭，主要目的是為了防止同城或相同地理位置的災難同時影響主數據中心和備份中心。這種架構的優點在于設計簡單，分區間互不干涉，擴展也相對簡單，新分區只需建立自己的備份中心即可。然而，其缺點是成本非常高，每個分區需要單獨建設和維護備份中心，地點租賃和設施成本是主要的財務負擔，使得獨立式備份的成本遠高于集中式備份。

圖片