基於 MySQL的高可用可擴充架構探討

原文引自:http://www.programmer.com.cn/3567/

隨著資訊量飛漲，資訊的儲存成為了這個時代至關重要的一項技術。如何來保證資料存放區技術能夠適應資訊量的增長速度和我們對資訊的高度依賴，成為一個非常重要的課題。本文將從資料庫結構描述的層面，通過以開源的資料存放區軟體來構建分布式資料層的思路，期望實現一個低成本的高可用可擴充的資料層架構。

 

傳統資料庫結構描述

縱觀各傳統商務資料庫軟體，多以集中式架構為主，鮮有以分布式為設計理念的架構。這些傳統資料庫軟體的最大特點就是將所有的資料都集中在一個資料庫中，依靠大型高端裝置來提供高處理能力和擴充性。

集中式資料庫結構描述在擴充性方面主要依賴於主機和存放資料的存放裝置的擴充能力，也就是說依賴硬體本身的縱向擴充能力，很難做到較好的橫向擴充。而其可靠性也同樣是以硬體裝置為依託，主要通過Share Storage的方式來實現。如大家所熟知的傳統商務資料庫代錶廠商Oracle的 RAC，就是一個非常典型的Share Everything 的集中式架構。

我們可以通過圖1來簡單地描繪一下傳統資料庫的典型架構：傳統架構在主機端大多通過兩台主機共用存放裝置，平時其中一台主機使用儲存通過資料庫軟體來管理。這樣的架構只能有一台主機（RAC除外）上的資料庫能夠提供服務，另一台主機只能是作為熱備冗餘，不能啟動資料庫執行個體提供服務。所以，其處理能力就完全取決於這台主機的最大擴充能力，很難通過增加主機數量來增加處理能力。而單台主機的擴充能力畢竟是有限的，即使是某些廠商的大型主機，同樣也有其擴充限制。此外，傳統架構對高端裝置的依賴，無疑將直接導致系統成本的大幅度增加，甚至可能會導致系統被主機和硬體廠商所“綁架”，不得不持續增加投入成本。 

 

圖1 傳統資料庫的典型架構

 

基於MySQL的可擴充和高可靠

MySQL作為開來源資料庫的佼佼者，無論是軟體本身的設計思想，還是推崇給廣大使用者們常用的架構思路都和傳統的商務資料庫軟體大相徑庭。 MySQL棄用了傳統的Share-Everything的思想，而採用了Share-Nothing的思想。MySQL的Replication實現機制，以及MySQL Cluster的架構設計，都體現了這一思想。也正因如此，給MySQL在可擴充性和高可靠性方面帶來了非常靈活的架構設計思路，也讓我們的資料庫可以擺脫對高端裝置的依賴，使用上性價比高很多的PC Server。

 

可擴充性

在提升擴充性方面，最為常用的是通過MySQL自身的Replication功能，將同一份MySQL的資料以非同步方式同時複製到另外的一台或多台MySQL主機上，並讓這些MySQL主機同時對外提供查詢服務。每增加一個複製的節點，查詢處理能力也得到相應的增加，新增節點的處理能力就是整個系統增加的處理能力。由於MySQL Replication主要是邏輯方式，同一個叢集中可有多家廠商的硬體，也可以使用不同的OS，所以可以做到完全不受任何軟/硬體平台限制，擺脫對單一平台的依賴。

人們可能會對MySQL Replication的功能特性不滿意，進而通過第三方開源軟體，甚至是通過解析其開源的通訊協定自行開發出來的複製軟體來進行資料即時（或者非同步）複製來達到 Replication完全相同甚至更好的效果。傳統資料庫可能也具有某項功能實現資料的複製，但與 MySQL相比，由於只依靠資料庫本身特性來完成，在架構的靈活性和可控性方面存在一些不足。

最後，在提升擴充性方面不得不說的資料切分（橫向/縱向）的思想，同樣可以在MySQL資料庫上得到靈活的發揮，無論是以功能模組的方式進行縱向的切分，還是以某個特定鍵（欄位）的類HASH分段的方式進行橫向的切分，抑或是通過資料庫本身的Partition功能進行切分，都可以在 MySQL上得到很好的實現。當然，無論是切分前的資料分散，還是切分後的資料路由和合并都離不開應用程式層的協作與配合，除非通過 MySQL Cluster來實現。對於提升擴充性的架構，通過圖2會有一個更為直觀的展現。

 

圖2 能夠提升擴充性的架構

圖中以“Master”為核心，通過不同的方式以三條“路線”將資料複製到相應的 MySQL 叢集中對外提供服務。實際的架構中，Master就是一個資料寫入點，複製出去的叢集則可以對外提供相應的查詢請求。常見的Web應用系統中，查詢請求遠遠大於寫入請求，所以非常適合通過MySQL 資料庫使用類似的架構思想來解決實際的擴充性問題。

 

高可靠性

在保證高可靠性方面，同樣可以通過MySQL的 Replication 為基礎，加以應用程式層架構的簡單配合或一些開源的第三方HA管理軟體來設計出多種非常靈活的高可靠架構。

對於資料寫入點，可以通過MySQL的Replication功能，將兩台MySQL主機設定成雙A的狀態，並通過HA管理軟體，對 MySQL的狀態檢測，來判定MySQL的狀態，並對外提供供單一的服務 IP 地址，以確保在任何時候有一台MySQL崩潰後馬上切換到另外一台 MySQL上提供服務。這樣自動的方式非常方便地讓我們的寫入點擁有高可靠性。如果我們的應用程式也可以自動判斷當一個點失效後馬上自動切換到另外一個點就更好，基本上可以做到對外部完全透明的切換，對可用性的影響之小，比現在一些知名廠商的專業HA管理都要好很多。

對於資料查詢點，高可靠性的實現就更容易了，可從雙A的兩台Master端中的任意一台上通過資料複製搭建多個具有完全相同資料拷貝的 MySQL節點，來保證任何時刻都可以有多台MySQL對外提供資料查詢服務。當一台MySQL崩潰，系統馬上將該節點從可以服務的節點中剔除出去。通過應用架構的協助這是非常容易做到的事情。

圖3是高可靠性執行個體圖。1描繪了基本架構，2、3和4分別描繪了當讀節點失效以及寫節點中的任何一個失效後的高可靠性實現。在高可靠性方面，除了自行控制將資料複製到多個MySQL主機上的方式之外，MySQL還提供了更為進階的方案——MySQL Cluster，一個完全的分散式資料庫叢集，而且是一個非常典型的Share-Nothing的分散式資料庫架構。資料層和SQL層分離，每份資料都以兩份或更多份拷貝存放在不同的資料節點上，整個資料層的所有節點以分散式運算的思想共同處理整個資料庫的資料，在保證高並發的處理能力的同時，以資料冗餘的方式保證了高可靠性。

 

圖 3 高可靠性執行個體圖

 

構建基於 MySQL、Cache 和Search的資料層

隨著Web應用系統負載的增速越來越快，常讓系統不堪重壓，資料庫系統尤甚。而隨著對使用者體驗關注度的提高，響應速度和使用的便利性則成為不可避免的話題。無論如何最佳化都不可能避免磁碟物理I/O的響應速度與記憶體中的I/O速度不匹配的問題，所以很自然地想到了通過記憶體Cache的方式來提高響應速度。

在使用的便利性方面最為典型的就是資料搜尋。關係型資料庫的特性，決定了它很難提供類似於Google那樣的可以全文檢索索引的搜尋系統。我們再次以藉助“外力”的方式來完善服務，將資料庫中的資料通過利用Lucene或者Egothor等類似的搜尋引擎系統，或者是利用Sphinx之類的軟體和資料庫整合，為資料庫增加全文檢索索引的能力。

可以設計出一個以資料庫（My-SQL）來完成持久化和常規的資料訪問功能，以分布式記憶體Cache系統來提供對響應速度和並發能力極高的資料的訪問，以第三方或者自行研發的分布式全文檢索搜尋系統來提供全文檢索索引服務的全方位的分布式資料服務層，中間則通過應用架構的協助實現一個統一的資料訪問層，來控制資料的讀取寫入檢索等操作，4所示：讓MySQL中的資料同步（或非同步）寫入到Cache和Search系統的實現方式很多，如對即時性要求不是很高，也不希望Data Proxy Layer中有太多的控制邏輯，完全可以通過隊列的方式以非同步方式實現；如對即時性要求較高，也可以通過 Data Proxy Layer這一層應用來控制Cache和Search中的資料更新；甚至還可以通過MySQL的使用者自訂函數，以 Trigger的方式將資料即時地更新到Cache叢集。類似的方式可以想出很多，關鍵是要根據應用情境，來選擇最合適、最簡單的方式來實現。

 

圖4 資料寫入Cache和Search系統的實現方式

架構無所謂最好的，只有最合適的。任何架構都有其適用的情境，也有其相應的生命週期。應用情境或業務量的變化，都可能導致架構不足以應對的現象。引用一句電影台詞：“出來混，遲早要還的！”