架構設計之「數據庫集群方案」
在之前的文章中，我們知道數據庫服務可能已經成為了很多系統的性能關鍵點，甚至是瓶頸了。也給大家介紹了數據庫服務器從主備架構、到主從架構、再到主主架構的基礎方案。但如果單臺機器已經不能滿足完整業務數據存儲的時候，我們就需要考慮采用多機甚至多中心的部署方案了。
今天我們就再來聊一聊，在多機環境下，數據庫集群的架構方案。
同樣，這裏先不看細節，不管底層數據源是什麽數據庫，我們先談架構方案。因為無論底層是 Mysql 還是 Redis、MongoDB，我們在架構設計上都是相通的。
針對多機的架構，常見有如下做法：
-
單中心數據集群
-
多中心數據分區
下面我們來具體看看：
一、單中心的數據集群架構（單中心多機）
單數據中心多機器的集群又可以分為：
-
數據集中模式
-
數據分散模式
這兩種的主要區別在於集群中的完整業務數據是全部集中在一臺機器上，但是分散在多臺機器上。
-
數據集中模式
如圖，
這種模式與「一主一從式」（主從式）比較類似，完整的業務數據還是存儲在一臺主機的上，主機承擔讀服務和寫服務，從機只承擔讀服務。但是從機有多臺機器，從機實時的從主機同步數據。所以這種模式，也可以理解為「一主多從」式。
因為有多個從機，那麽也給這種架構帶來了一些額外需要處理問題，比如：
1.1，主機需要實時的將數據同步到多臺從機上，涉及到主機的處理壓力問題。
1.2，需要保障多臺從機之間的數據一致性的問題，如果出現數據不一致，如何處理。
1.3，多臺從機是如何檢測主機狀態的，因為從機在關鍵時刻是要替換主機的，那麽如果多臺從機監測到的主機狀態不一致，那又可能會帶來其它問題。
1.4，從機切換為主機的時候，選擇哪一臺從機來切換呢，這涉及到多臺從機之間如何進行選舉的問題。
這些問題，在我們進行架構設計的時候，必須提前考慮。不過市面上也有一些工具可以輔助實現，例如 ZooKeeper等。
另外，由於數據集中模式的所有寫操作都只到一臺主機上，而讀操作可以到N臺從機上。因此這種模式比較適用於業務數據量不大、讀操作遠遠大於寫操作、集群規模較小的業務場景。
-
數據分散模式
如圖，
數據分散模式是指，完整的業務數據並非是全部存儲在一臺主機上的，而是由多臺主機共同分擔，分散存儲。因此這種模式適用於大數據量、集群規模較大的場景。
使用這種模式，也有幾點需要特別註意的：
1.1，盡量將數據均衡的分散的各個機上，這樣才能保證資源的均衡使用和性能的最佳。
1.2，多臺機器上的數據雖然不同，但是也需要互相進行數據的備份。
1.3，要能動態的增加和刪除節點，這樣可以便於隨時擴展，通常采用一致性HASH的方法。
聊完了單數據中心的集群架構，我們再來看看多數據中心的數據分區架構。
二、多中心的數據分區架構（多中心多機）
出於容災的考慮，通常會在多個不同地區部署多套的數據集群。畢竟在國內運營商網絡故障、光纖被山東藍翔技工鏟斷等事件還是不少的。輕則一個機房出問題，重則一個城市一個省份都可能故障。
如果我們數據存儲服務只部署在一個機房，那如果這個機房出現了故障，很有可能導致不能服務甚至是無法恢復業務了。因此我們就需要考慮多中心的數據分區架構，將數據按照一定的規則進行分區，部署在不同機房/城市裏，且每一個分區都存儲一部分數據，通過這種方式來保障數據和服務的可用性。
在多中心的數據分區模式下，我們需要提前規劃 “分區規則” 。畢竟將數據在地理位置上分區，在網絡通訊方面是有時延的，所以必須要考慮好我們是要以區域、還是以城市、還是省份來分節點部署。
除了 “分區規則” ，我們還需要考慮 “備份規則” 。
因為分區之後，各區都只存儲一部分數據，並不是完整數據。如果其中一個區出故障了，雖然不會影響全局，但是也會帶來一定損失。因此我們需要考慮將每個區裏的數據備份起來，備份有幾種方式：
-
集中備份式
-
獨立備份式
-
相互備份式
下面將這三種備份方式解釋一下：
-
集中備份式
如圖，
集中備份式是指建立一個獨立的數據備份中心，將各分區（節點）的數據都定期同步到這個備份中心，以保障數據的安全性。這種備份方式可以隨意的擴展分區（節點），不受分區的個數限制，並且結構很簡單。但是
這種備份方式的缺點就是，投入成本有點高，因為需要額外建立這麽一個備份數據中心，平時也是閑置的，有點浪費資源。另外，備份中心自身也可能會有單點的故障，且備份中心中需存儲多個分區的數據，還可能會互相受到影響。
-
獨立備份式
如圖，
（參考圖片）
獨立備份式就是給每一個數據分區（節點）都建立一個額外的備份節點，這個備份節點部署在不同的地域/城市，這樣才能起到容災的作用。
這種備份方式相比較於 集中備份式 ，建設成本就更大一些了，畢竟每一個分區都需要額外建立一個備份節點。但是結構更清晰簡單了，而且各個分區的數據之間還可以做到互不影響，完全是獨立的。後續擴展分區（節點）的時候，對前面的備份節點也沒有影響，擴展性好。
-
相互備份式
這個暫時沒有找到合適的圖。
相互備份式其實是結合了上面兩種特性在一起的模式。上面的方式不是成本大麽，那麽這種方式就不額外建立備份中心了，讓各個分區（節點）互相備份數據。比如 分區A 將自身數據同步一份給 分區B備份著，分區B 將自己的數據同步一份給 分區A 備份著，如果是三個以上分區，還可以做到循環備份。
這種備份方式，設計稍微復雜一些，擴展性也弱一些，但是可以節約資源。
無論采用哪種方式，都需要結合實際的業務場景來決定。
以上，就是對數據庫在多機集群模式下的技術架構的分享，歡迎大家一起交流。
本文原創發布於微信公眾號「 不止思考 」，交流Java、Web、架構、大數據、職業發展、技術管理，歡迎關註。
架構設計之「數據庫集群方案」