架構設計之「資料庫叢集方案」

來自：不止思考（微訊號：bzsikao）

在之前的文章中，我們知道資料庫服務可能已經成為了很多系統的效能關鍵點，甚至是瓶頸了。也給大家介紹了資料庫伺服器從主備架構、到主從架構、再到主主架構的基礎方案。但如果單臺機器已經不能滿足完整業務資料儲存的時候，我們就需要考慮採用多機甚至多中心的部署方案了。

今天我們就再來聊一聊，在多機環境下，資料庫叢集的架構方案。

同樣，這裡先不看細節，不管底層資料源是什麼資料庫，我們先談架構方案。因為無論底層是 Mysql 還是 Redis、MongoDB，我們在架構設計上都是相通的。

針對多機的架構，常見有如下做法：

• 單中心資料叢集

• 多中心資料分割槽

下麵我們來具體看看：

一、單中心的資料叢集架構（單中心多機）

單資料中心多機器的叢集又可以分為：

• 資料集中樣式

• 資料分散樣式

這兩種的主要區別在於叢集中的完整業務資料是全部集中在一臺機器上，但是分散在多臺機器上。

1. 資料集中樣式

如圖，

這種樣式與「一主一從式」（主從式）比較類似，完整的業務資料還是儲存在一臺主機的上，主機承擔讀服務和寫服務，從機只承擔讀服務。但是從機有多臺機器，從機實時的從主機同步資料。所以這種樣式，也可以理解為「一主多從」式。

因為有多個從機，那麼也給這種架構帶來了一些額外需要處理問題，比如：
1.1，主機需要實時的將資料同步到多臺從機上，涉及到主機的處理壓力問題。
1.2，需要保障多臺從機之間的資料一致性的問題，如果出現資料不一致，如何處理。
1.3，多臺從機是如何檢測主機狀態的，因為從機在關鍵時刻是要替換主機的，那麼如果多臺從機監測到的主機狀態不一致，那又可能會帶來其它問題。
1.4，從機切換為主機的時候，選擇哪一臺從機來切換呢，這涉及到多臺從機之間如何進行選舉的問題。

這些問題，在我們進行架構設計的時候，必須提前考慮。不過市面上也有一些工具可以輔助實現，例如 ZooKeeper等。

另外，由於資料集中樣式的所有寫操作都只到一臺主機上，而讀操作可以到N臺從機上。因此這種樣式比較適用於業務資料量不大、讀操作遠遠大於寫操作、叢集規模較小的業務場景。

2. 資料分散樣式

如圖，

資料分散樣式是指，完整的業務資料並非是全部儲存在一臺主機上的，而是由多臺主機共同分擔，分散儲存。因此這種樣式適用於大資料量、叢集規模較大的場景。

使用這種樣式，也有幾點需要特別註意的：
1.1，儘量將資料均衡的分散的各個機上，這樣才能保證資源的均衡使用和效能的最佳。
1.2，多臺機器上的資料雖然不同，但是也需要互相進行資料的備份。
1.3，要能動態的增加和刪除節點，這樣可以便於隨時擴充套件，通常採用一致性HASH的方法。

聊完了單資料中心的叢集架構，我們再來看看多資料中心的資料分割槽架構。

二、多中心的資料分割槽架構（多中心多機）

出於容災的考慮，通常會在多個不同地區部署多套的資料叢集。畢竟在國內運營商網路故障、光纖被山東藍翔技工鏟斷等事件還是不少的。輕則一個機房出問題，重則一個城市一個省份都可能故障。

如果我們資料儲存服務只部署在一個機房，那如果這個機房出現了故障，很有可能導致不能服務甚至是無法恢復業務了。因此我們就需要考慮多中心的資料分割槽架構，將資料按照一定的規則進行分割槽，部署在不同機房/城市裡，且每一個分割槽都儲存一部分資料，透過這種方式來保障資料和服務的可用性。

在多中心的資料分割槽樣式下，我們需要提前規劃 “分割槽規則” 。畢竟將資料在地理位置上分割槽，在網路通訊方面是有時延的，所以必須要考慮好我們是要以區域、還是以城市、還是省份來分節點部署。

除了 “分割槽規則” ，我們還需要考慮 “備份規則” 。
因為分割槽之後，各區都只儲存一部分資料，並不是完整資料。如果其中一個區出故障了，雖然不會影響全域性，但是也會帶來一定損失。因此我們需要考慮將每個區裡的資料備份起來，備份有幾種方式：

• 集中備份式

• 獨立備份式

• 相互備份式

下麵將這三種備份方式解釋一下：

1. 集中備份式

如圖，

（參考圖片）

集中備份式是指建立一個獨立的資料備份中心，將各分割槽（節點）的資料都定期同步到這個備份中心，以保障資料的安全性。這種備份方式可以隨意的擴充套件分割槽（節點），不受分割槽的個數限制，並且結構很簡單。但是

這種備份方式的缺點就是，投入成本有點高，因為需要額外建立這麼一個備份資料中心，平時也是閑置的，有點浪費資源。另外，備份中心自身也可能會有單點的故障，且備份中心中需儲存多個分割槽的資料，還可能會互相受到影響。

2. 獨立備份式

如圖，

（參考圖片）

獨立備份式就是給每一個資料分割槽（節點）都建立一個額外的備份節點，這個備份節點部署在不同的地域/城市，這樣才能起到容災的作用。

這種備份方式相比較於 集中備份式 ，建設成本就更大一些了，畢竟每一個分割槽都需要額外建立一個備份節點。但是結構更清晰簡單了，而且各個分割槽的資料之間還可以做到互不影響，完全是獨立的。後續擴充套件分割槽（節點）的時候，對前面的備份節點也沒有影響，擴充套件性好。

3. 相互備份式

這個暫時沒有找到合適的圖。

相互備份式其實是結合了上面兩種特性在一起的樣式。上面的方式不是成本大麼，那麼這種方式就不額外建立備份中心了，讓各個分割槽（節點）互相備份資料。比如 分割槽A 將自身資料同步一份給 分割槽B備份著，分割槽B 將自己的資料同步一份給 分割槽A 備份著，如果是三個以上分割槽，還可以做到迴圈備份。

這種備份方式，設計稍微複雜一些，擴充套件性也弱一些，但是可以節約資源。

無論採用哪種方式，都需要結合實際的業務場景來決定。

以上，就是對資料庫在多機叢集樣式下的技術架構的分享，歡迎大家一起交流。

●編號422，輸入編號直達本文

●輸入m獲取文章目錄

更多推薦《18個技術類微信公眾號》

涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。