高可用存儲架構：集羣和分區
主備、主從、和主主架構都基於一個共同的前提：主機需要有能力存儲所有數據。然而，主機的存儲和處理容量是有限的。以歷史發展爲例，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 集羣，這些集羣可包含數百甚至數千臺服務器。
數據分區
在考慮存儲高可用架構時，我們通常關注的是如何在硬件故障發生時維持系統的運行。然而，對於可能導致所有硬件同時故障的重大災害或事故，如新奧爾良的水災、美加大範圍停電、洛杉磯的大地震等，單純基於硬件故障的高可用架構可能不足以應對。在這種情況下，需要設計可以抵抗地理級別故障的高可用架構，這正是數據分區架構的來源。
數據分區架構通過按照特定規則將數據分佈在不同的地理位置來避免地理級別的故障帶來的重大影響。這種架構確保即使某一地區遭受重大災害，也只有部分數據受到影響，而非全部數據。一旦地區故障恢復，其他地區的備份數據可以快速恢復受影響地區的業務運行。
設計有效的數據分區架構需要綜合考慮多個方面：
-
數據量
數據量的大小決定了分區複雜性。例如，假設每臺 MySQL 服務器的存儲能力爲 500GB，那麼 2TB 的數據需要至少 4 臺服務器。但對於 200TB 的數據，簡單地增加到 800 臺 MySQL 服務器將極大增加管理複雜度。例如，可能每週都有服務器故障，從 800 臺服務器中找出故障的那一兩臺並不簡單，同時，運維複雜度也會顯著提高。在地理分佈上，若數據集中在一個城市，一旦發生大型災難，風險極高。 -
分區規則
分區可以按照洲際、國家或城市等級別進行，具體採取哪種規則取決於業務需求和成本考慮。洲際分區適用於服務不同大洲的用戶，由於網絡延遲較大，通常用作數據備份而非實時服務。國家分區適合針對具有不同語言、法律需求的國家，通常也主要用於數據備份。城市分區則適合在同一國家或地區內提供低延遲服務，適用於異地多活等需求。
- 複製規則
即使採用了數據分區架構，每個分區仍然需要處理大量數據。單一分區的數據損壞或丟失仍然是無法接受的。因此，即使在分區架構中，也必須實施數據複製策略，以確保數據的安全和高可用性。
常見的分區複製規則有三種：集中式、互備式和獨立式。
集中式備份
集中式備份系統設有一個主要的備份中心，所有的分區都將其數據傳輸至該中心進行備份。此架構的優點包括設計的簡潔性，由於分區之間沒有直接的聯繫，各自獨立運作，互不干擾。此外，擴展性也較高，若需要添加新的分區，如武漢分區，僅需將其數據備份到已有的西安備份中心，不影響其他分區。然而，這種方式的缺點是成本相對較高，因爲需要建立和維護一個獨立的備份中心。
互備式備份
互備式備份要求每個分區備份另一個分區的數據。這種設計較爲複雜，因爲每個分區不僅要處理自己的業務數據還要負責備份工作，分區間存在相互影響和依賴。擴展此係統相對困難，例如引入武漢分區可能需要重新配置廣州分區的備份目標爲武漢，同時還需處理原有的北京與廣州的備份數據，不論是數據遷移還是保留歷史數據都會帶來挑戰。但這種方法成本較低，因爲它直接利用現有的設施。
獨立式備份
獨立式備份中，每個分區都擁有自己的備份中心，且備份中心不與原數據中心位於同一地點。例如，北京分區的備份設在天津，上海的備份設在杭州，廣州的則設在汕頭，主要目的是爲了防止同城或相同地理位置的災難同時影響主數據中心和備份中心。這種架構的優點在於設計簡單，分區間互不干涉，擴展也相對簡單，新分區只需建立自己的備份中心即可。然而，其缺點是成本非常高，每個分區需要單獨建設和維護備份中心，地點租賃和設施成本是主要的財務負擔，使得獨立式備份的成本遠高於集中式備份。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/FzKbs770_LGM83u2V6nRfA