概述
在很多項目中，當業務規模越來越大，數據越來越多，隨之而來的就是數據庫壓力會越來越大。慢慢就會發現，數據庫層可能已經成為了整個系統的關鍵點和性能瓶頸了，因此實現數據層的高可用就成為了我們項目中經常要解決的問題。
今天主要分享數據存儲層的高可用方案和數據庫集群的架構方案。
下面先介紹如何實現數據存儲層的高可用方案。在保障數據層的高性能與高穩定方面，最容易想到的方式就是對數據進行分片、多份、冗餘等，很多架構的本質其實也是基於這幾點來實現的。
大體上，單中心雙機的常見方案有以下這些：
- 一主一備的架構（主備式）
- 一主一從的架構（主從式）
- 互為主從的架構（主主式）
以上方案從上至下，依次是從簡單到複雜，從基礎到豐富：
一、一主一備的架構（主備式）
主備式架構是雙機部署中最簡單的一種架構了，幾乎市面上所有的數據庫系統都會自帶這個主備功能。
其思路也特別的簡單：將數據庫部署到兩臺機器，其中一臺機器（代號A）作為日常提供數據讀寫服務的機器，稱為「主機」。另外一臺機器（代號B）並不提供線上服務，但會實時的將「主機」的數據同步過來，稱為「備機」。一旦「主機」出了故障，通過人工的方式，手動的將「主機」踢下線，將「備機」改為「主機」來繼續提供服務。
這個架構的優缺點都很明顯，優點就是幾乎不需要做什麼開發改造，各類數據庫就支持這種模式，部署維護起來也簡單，並沒有引入額外的系統複雜度和瓶頸。
但是缺點呢，就是當「主機」出現故障的時候，需要人工去幹預啊，運維同學很辛苦的，而且處理還不一定及時。再還有一個缺點就是，主備架構會造成嚴重浪費資源，畢竟需要一臺與「主機」同等配置的「備機」長期備著，但又不作為線上服務來使用。
為了解決這個資源浪費問題，我們就得想一個把「備機」也用起來的方案：主從式架構。
二、一主一從的架構（主從式）
主從式架構大體上與上述的主備式架構差不多。區別就是主備式的「備機」平時是不幹活的的，主要起到備份的作用。而主從式的「備機」改為了「從機」，平時也要提供服務，跟「主機」一樣隨時隨刻的在幹活的。
主從式架構中的「從機」雖然也在隨時隨刻提供服務，但是它只提供「讀」服務，並不提供「寫」服務。「主機」會實時的將線上數據同步到「從機」，以保證「從機」能夠正常的提供讀操作。
這種架構相比較主備式，對資源是一種節約，畢竟「從機」也在提供服務，沒有白白的浪費。並且在「主機」出現故障時，在人工介入之前，好歹「從機」也是能夠提供數據的「讀」操作的，畢竟大多數業務都是「讀」多「寫」少，因此對穩定性又提高了一個層次。
缺點就是架構稍微複雜了一點，畢竟「主機」和「從機」都有「讀」服務，那麼前端業務系統就需要用一定策略去判斷該路由到哪一臺去讀取數據。還有就是，延遲問題，「主機」的數據同步到「從機」難免會有一定程度的延遲，這個延遲可能會對數據實時性要求較高的業務有一定影響。
通過上面內容可以看到，雖然這個架構一定程度解決了資源浪費，但是並沒有解決人工干預的問題，當出現了故障後還是需要人工去處理。
三、互為主從的架構（主主式）
互為主從的架構是指兩臺機器自己都是主機，並且也都是作為對方的從機。兩臺機器都提供完整的讀寫服務，因此無需切換，客戶機在調用的時候隨機挑選一臺即可，當其中一臺宕機了，另外一臺還可以繼續服務。
採用
互為主從架構有個複雜點就是，因為兩臺主機都接受寫數據，那就需要將寫的最新數據實時的同步給對方，需要將數據進行兩臺主機的雙向複製。而雙向複製不可避免的會在一定程度上帶來數據延遲、極端情況下甚至有數據丟失等問題。在實際業務中，有些業務數據對一致性要求是非常高的，並不能接受數據的延遲、丟失，因此這類業務也不適合互為主從的模式，比如金融業務。但是我們互聯網業務中大多數場景還是沒有這麼高要求的，所以這種模式對於一般場景還是用的蠻多。以上，就是對數據庫從主備架構、到主從架構、再到主主架構的高可用方案基本講解了，接下來會繼續分享數據庫在多機集群模式下的技術架構，歡迎大家關注交流。
眾所周知，數據庫服務可能已經成為了很多系統的性能關鍵點，甚至是瓶頸了。也給大家介紹了數據庫服務器從主備架構、到主從架構、再到主主架構的基礎方案。但如果單臺機器已經不能滿足完整業務數據存儲的時候，我們就需要考慮採用多機甚至多中心的部署方案了。
針對多機的架構，常見有如下做法：
- 單中心數據集群
- 多中心數據分區
下面來具體看看：
一、單中心的數據集群架構（單中心多機）
單數據中心多機器的集群又可以分為：
- 數據集中模式
- 數據分散模式
這兩種的主要區別在於集群中的完整業務數據是全部集中在一臺機器上，但是分散在多臺機器上。
- 數據集中模式
這種模式與「一主一從式」（主從式）比較類似，完整的業務數據還是存儲在一臺主機的上，主機承擔讀服務和寫服務，從機只承擔讀服務。但是從機有多臺機器，從機實時的從主機同步數據。所以這種模式，也可以理解為「一主多從」式。
因為有多個從機，那麼也給這種架構帶來了一些額外需要處理問題，比如：
1.1，主機需要實時的將數據同步到多臺從機上，涉及到主機的處理壓力問題。
1.2，需要保障多臺從機之間的數據一致性的問題，如果出現數據不一致，如何處理。
1.3，多臺從機是如何檢測主機狀態的，因為從機在關鍵時刻是要替換主機的，那麼如果多臺從機監測到的主機狀態不一致，那又可能會帶來其它問題。
1.4，從機切換為主機的時候，選擇哪一臺從機來切換呢，這涉及到多臺從機之間如何進行選舉的問題。
這些問題，在我們進行架構設計的時候，必須提前考慮。不過市面上也有一些工具可以輔助實現，例如 ZooKeeper等。
另外，由於數據集中模式的所有寫操作都只到一臺主機上，而讀操作可以到N臺從機上。因此這種模式比較適用於業務數據量不大、讀操作遠遠大於寫操作、集群規模較小的業務場景。
- 數據分散模式
數據分散模式是指，完整的業務數據並非是全部存儲在一臺主機上的，而是由多臺主機共同分擔，分散存儲。因此這種模式適用於大數據量、集群規模較大的場景。
使用這種模式，也有幾點需要特別注意的：
1.1，儘量將數據均衡的分散的各個機上，這樣才能保證資源的均衡使用和性能的最佳。
1.2，多臺機器上的數據雖然不同，但是也需要互相進行數據的備份。
1.3，要能動態的增加和刪除節點，這樣可以便於隨時擴展，通常採用一致性HASH的方法。
二、多中心的數據分區架構（多中心多機）
出於容災的考慮，通常會在多個不同地區部署多套的數據集群。畢竟在國內運營商網絡故障、光纖被山東藍翔技工剷斷等事件還是不少的。輕則一個機房出問題，重則一個城市一個省份都可能故障。
如果我們數據存儲服務只部署在一個機房，那如果這個機房出現了故障，很有可能導致不能服務甚至是無法恢復業務了。因此我們就需要考慮多中心的數據分區架構，將數據按照一定的規則進行分區，部署在不同機房/城市裡，且每一個分區都存儲一部分數據，通過這種方式來保障數據和服務的可用性。
在多中心的數據分區模式下，我們需要提前規劃 “分區規則” 。畢竟將數據在地理位置上分區，在網絡通訊方面是有時延的，所以必須要考慮好我們是要以區域、還是以城市、還是省份來分節點部署。
除了 “分區規則” ，我們還需要考慮 “備份規則” 。
因為分區之後，各區都只存儲一部分數據，並不是完整數據。如果其中一個區出故障了，雖然不會影響全局，但是也會帶來一定損失。因此我們需要考慮將每個區裡的數據備份起來，備份有幾種方式：
- 集中備份式
- 獨立備份式
- 相互備份式
下面將這三種備份方式解釋一下：
- 集中備份式
集中備份式是指建立一個獨立的數據備份中心，將各分區（節點）的數據都定期同步到這個備份中心，以保障數據的安全性。這種備份方式可以隨意的擴展分區（節點），不受分區的個數限制，並且結構很簡單。但是
這種備份方式的缺點就是，投入成本有點高，因為需要額外建立這麼一個備份數據中心，平時也是閒置的，有點浪費資源。另外，備份中心自身也可能會有單點的故障，且備份中心中需存儲多個分區的數據，還可能會互相受到影響。
- 獨立備份式
獨立備份式就是給每一個數據分區（節點）都建立一個額外的備份節點，這個備份節點部署在不同的地域/城市，這樣才能起到容災的作用。
這種備份方式相比較於 集中備份式 ，建設成本就更大一些了，畢竟每一個分區都需要額外建立一個備份節點。但是結構更清晰簡單了，而且各個分區的數據之間還可以做到互不影響，完全是獨立的。後續擴展分區（節點）的時候，對前面的備份節點也沒有影響，擴展性好。
- 相互備份式
相互備份式其實是結合了上面兩種特性在一起的模式。上面的方式不是成本大麼，那麼這種方式就不額外建立備份中心了，讓各個分區（節點）互相備份數據。比如 分區A 將自身數據同步一份給 分區B備份著，分區B 將自己的數據同步一份給 分區A 備份著，如果是三個以上分區，還可以做到循環備份。
這種備份方式，設計稍微複雜一些，擴展性也弱一些，但是可以節約資源。
無論採用哪種方式，都需要結合實際的業務場景來決定。
以上，就是對數據庫在多機集群模式下的技術架構的分享
篇幅有限，關於數據存儲層的高可用方案和數據庫集群的架構方案就介紹到這了，再增加內容大家肯定就不看了...後期內容會分享更多高可用和集群的內容，感興趣的朋友可以關注下哦！
閱讀更多 波波說運維 的文章
