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

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

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

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

圖片

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

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

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

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

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

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

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

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

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

圖片

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

圖片

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

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

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

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

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

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

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

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

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

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

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

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

集中式備份

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

圖片

互備式備份

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

獨(dú)立式備份

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

圖片