聊聊高可用存儲架構：叢集和分區

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

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

1. 資料集中叢集

資料集中叢集與主備、主從這類架構相似，我們也可以稱資料集中叢集為 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.複制規則

即使采用了資料分區架構，每個分區仍然需要處理大量資料。單一分區的資料損壞或丢失仍然是無法接受的。是以，即使在分區架構中，也必須實施資料複制政策，以確定資料的安全和高可用性。

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

集中式備份

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

互備式備份

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

獨立式備份

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

更多資訊，點選全場景直播解決方案-航天雲網解決方案