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

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

數(shù)據(jù)集中集群

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

圖片

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

此外，多個復(fù)制通道可能會導(dǎo)致不同備機之間的數(shù)據(jù)出現(xiàn)不一致。在這種情況下，需要對各備機之間的數(shù)據(jù)一致性進行驗證和調(diào)整。

對于備機如何判斷主機的狀態(tài)，主備和主從架構(gòu)中只涉及單臺備機的狀態(tài)判斷。但在數(shù)據(jù)集中集群架構(gòu)中，多臺備機都需要對主機狀態(tài)做出判斷，且不同備機的判斷結(jié)果可能不一致，處理這些不一致的判斷是一個復(fù)雜的問題。

當(dāng)主機發(fā)生故障時，如何決定新的主機也是一個關(guān)鍵問題。在主從架構(gòu)中，通常直接將備機升級為主機。然而，在數(shù)據(jù)集中集群架構(gòu)中，由于存在多臺可升級的備機，必須決定哪一臺備機最適合成為新的主機，以及備機之間如何進行協(xié)調(diào)。

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

對于數(shù)據(jù)分散集群，這種結(jié)構(gòu)涉及多臺服務(wù)器，每臺服務(wù)器存儲部分數(shù)據(jù)并備份其他部分數(shù)據(jù)。數(shù)據(jù)分散集群面臨的復(fù)雜性在于如何將數(shù)據(jù)恰當(dāng)?shù)胤峙涞讲煌?wù)器上。這涉及到以下幾個設(shè)計要素：

• 均衡性：分配算法必須確保數(shù)據(jù)在各服務(wù)器之間的分布大體均衡，避免某臺服務(wù)器的數(shù)據(jù)量顯著高于其他服務(wù)器。
• 容錯性：當(dāng)部分服務(wù)器出現(xiàn)故障時，算法需要能夠?qū)⑹苡绊懙臄?shù)據(jù)區(qū)重新分配給其他服務(wù)器。
• 可伸縮性：當(dāng)需要擴展集群容量時，算法應(yīng)能自動將數(shù)據(jù)遷移到新增的服務(wù)器上，并確保擴容后數(shù)據(jù)依然均衡分布。

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

Hadoop 的實現(xiàn)就是獨立的服務(wù)器負責(zé)數(shù)據(jù)分區(qū)的分配，這臺服務(wù)器叫作Namenode。Hadoop 的數(shù)據(jù)分區(qū)管理架構(gòu)如下：

圖片

與 Hadoop 不同的是，Elasticsearch 集群通過選舉一臺服務(wù)器來做數(shù)據(jù)分區(qū)的分配，叫作 master node，其數(shù)據(jù)分區(qū)管理架構(gòu)是：

圖片

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

數(shù)據(jù)分區(qū)

在考慮存儲高可用架構(gòu)時，我們通常關(guān)注的是如何在硬件故障發(fā)生時維持系統(tǒng)的運行。然而，對于可能導(dǎo)致所有硬件同時故障的重大災(zāi)害或事故，如新奧爾良的水災(zāi)、美加大范圍停電、洛杉磯的大地震等，單純基于硬件故障的高可用架構(gòu)可能不足以應(yīng)對。在這種情況下，需要設(shè)計可以抵抗地理級別故障的高可用架構(gòu)，這正是數(shù)據(jù)分區(qū)架構(gòu)的來源。

數(shù)據(jù)分區(qū)架構(gòu)通過按照特定規(guī)則將數(shù)據(jù)分布在不同的地理位置來避免地理級別的故障帶來的重大影響。這種架構(gòu)確保即使某一地區(qū)遭受重大災(zāi)害，也只有部分數(shù)據(jù)受到影響，而非全部數(shù)據(jù)。一旦地區(qū)故障恢復(fù)，其他地區(qū)的備份數(shù)據(jù)可以快速恢復(fù)受影響地區(qū)的業(yè)務(wù)運行。

設(shè)計有效的數(shù)據(jù)分區(qū)架構(gòu)需要綜合考慮多個方面：

1.數(shù)據(jù)量數(shù)據(jù)量的大小決定了分區(qū)復(fù)雜性

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

2.分區(qū)規(guī)則

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

3.復(fù)制規(guī)則

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

常見的分區(qū)復(fù)制規(guī)則有三種：集中式、互備式和獨立式。

集中式備份

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

圖片

互備式備份

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

獨立式備份

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

圖片