知識星球
精彩預告：第八屆資料技術嘉年華大會將於2018年11月16日~17日在北京市朝陽區東三環中路61號富力萬麗酒店盛大開啟。本次大會邀請網際網路領先企業的資料庫專家，國產資料庫的領軍人物，雲技術等領域的知名人士，圍繞資料、智慧、連結組織前沿議題，倡導以智慧智慧演演算法應用，發掘資料價值，以技術將企業連結到未來的戰略制高點！
社群專屬福利（99.9%的人不知道）：一分錢全場通票等你搶
本文我們就來聊一聊如何實現資料儲存層的高可用方案。在保障資料層的高效能與高穩定方面，最容易想到的方式就是對資料進行分片、多份、冗餘等，很多架構的本質其實也是基於這幾點來實現的。
這裡先不看細節，即先不管底層資料源是什麼資料庫，我們先只聊架構方案，因為無論底層是關係型資料庫，還是NoSQL資料庫，無論是 Mysql 還是 Redis、MongoDB，我們在架構設計上都是相通的。
大體上，單中心雙機的常見方案有以下這些：
-
一主一備的架構（主備式）
-
一主一從的架構（主從式）
-
互為主從的架構（主主式）
以上方案從上至下，依次是從簡單到複雜，從基礎到豐富。下麵我們來具體看看：
一、一主一備的架構（主備式）
主備式架構是雙機部署中最簡單的一種架構了，幾乎市面上所有的資料庫系統都會自帶這個主備功能。
其思路也特別的簡單：將資料庫部署到兩臺機器，其中一臺機器（代號A）作為日常提供資料讀寫服務的機器，稱為「主機」。另外一臺機器（代號B）並不提供線上服務，但會實時的將「主機」的資料同步過來，稱為「備機」。一旦「主機」出了故障，透過人工的方式，手動的將「主機」踢下線，將「備機」改為「主機」來繼續提供服務。這個架構的優缺點都很明顯，優點就是幾乎不需要做什麼開發改造，各類資料庫就支援這種樣式，部署維護起來也簡單，並沒有引入額外的系統複雜度和瓶頸。
但是缺點呢，就是當「主機」出現故障的時候，需要人工去幹預啊，運維同學很辛苦的，而且處理還不一定及時。再還有一個缺點就是，主備架構會造成嚴重浪費資源，畢竟需要一臺與「主機」同等配置的「備機」長期備著，但又不作為線上服務來使用，你說浪費不浪費。
為瞭解決這個資源浪費問題，我們就得想一個把「備機」也用起來的方案：主從式架構。
二、一主一從的架構（主從式）
主從式架構大體上與上述的主備式架構差不多。區別就是主備式的「備機」平時是不幹活的的，主要起到備份的作用。而主從式的「備機」改為了「從機」，平時也要提供服務，跟「主機」一樣隨時隨刻的在幹活的。
主從式架構中的「從機」雖然也在隨時隨刻提供服務，但是它只提供「讀」服務，並不提供「寫」服務。「主機」會實時的將線上資料同步到「從機」，以保證「從機」能夠正常的提供讀操作。
這種架構相比較主備式，對資源是一種節約，畢竟「從機」也在提供服務，沒有白白的浪費。並且在「主機」出現故障時，在人工介入之前，好歹「從機」也是能夠提供資料的「讀」操作的，畢竟大多數業務都是「讀」多「寫」少，因此對穩定性又提高了一個層次。
缺點就是架構稍微複雜了一點，畢竟「主機」和「從機」都有「讀」服務，那麼前端業務系統就需要用一定策略去判斷該路由到哪一臺去讀取資料。還有就是，延遲問題，「主機」的資料同步到「從機」難免會有一定程度的延遲，這個延遲可能會對資料實時性要求較高的業務有一定影響。
透過上面內容可以看到，雖然這個架構一定程度解決了資源浪費，但是並沒有解決人工幹預的問題，當出現了故障後還是需要人工去處理。
如果想讓架構更智慧一點，那麼我們就需要引入「主從雙機自動切換」的功能。
主從雙機自動切換：是指當主機出現故障後，從機能夠自動檢測發現。同時從機將自己迅速切換為主機，將原來的主機立即下線服務，或轉換為從機狀態。
要實現「主從雙機自動切換」，有幾個關鍵點需要考慮：
-
主機與從機之間的狀態如何判斷？
必須有一個機制能監測兩臺機器的執行狀態，以此來決定是否應該切換。
我們比較常用的狀態傳遞方式有兩種：
「雙機互連樣式」
「第三方中介樣式」
「雙機互連樣式」：是指在主機和從機之間建立一條用於狀態通訊的通道。透過這個通道，主機和從機之間可以共享服務狀態，一旦發現對方宕機或者停止服務了，就可以立即將自己切換為主服務。不過這種方式需要關註通道的健壯性，一旦通道自身不穩定了，可能會導致假訊息出現，比如主機並沒有宕機，但是通道壞了，導致從機以為出現了異常，就將自己切換為了主機，那就出現了2個主機了，因此通道本身也是一個可能的故障點。
「第三方中介樣式」：是指在主機和從機之外，再建立一個中介機器，這個中介機器專門用來維護各節點（主機/從機）狀態的，主機/從機實時的將自身狀態上報給中介機器，中介機器來決定是否應該切換、何時切換。MongoDB的Replica Set就是採用的這種樣式。
-
除了狀態判斷，還需要考慮切換的策略是什麼？ 也就是說發生異常幾次/多久後開始切換，是否有一個緩衝機制等。另外切換完成後，當原主機又恢復正常之後是否需要自動再切換回來等策略。
-
另外就是需要註意在切換過程中雙機資料如果發生衝突時，以哪個為準？處理機制是什麼。
這些細節都是在設計主從自動切換架構時候，要提前規劃的。
三、互為主從的架構（主主式）
互為主從的架構是指兩臺機器自己都是主機，並且也都是作為對方的從機。兩臺機器都提供完整的讀寫服務，因此無需切換，客戶機在呼叫的時候隨機挑選一臺即可，當其中一臺宕機了，另外一臺還可以繼續服務。
採用互為主從架構有個複雜點就是，因為兩臺主機都接受寫資料，那就需要將寫的最新資料實時的同步給對方，需要將資料進行兩臺主機的雙向複製。而雙向複製不可避免的會在一定程度上帶來資料延遲、極端情況下甚至有資料丟失等問題。在實際業務中，有些業務資料對一致性要求是非常高的，並不能接受資料的延遲、丟失，因此這類業務也不適合互為主從的樣式，比如金融業務。但是我們網際網路業務中大多數場景還是沒有這麼高要求的，所以這種樣式對於一般場景還是用的蠻多。
以上，就是對資料庫從主備架構、到主從架構、再到主主架構的高可用方案基本講解了，接下來會繼續分享資料庫在多機叢集樣式下的技術架構，歡迎大家關註交流。
接下來我們就再來聊一聊，在多機環境下，資料庫叢集的架構方案。
同樣，這裡先不看細節，不管底層資料源是什麼資料庫，我們先談架構方案。因為無論底層是 Mysql 還是 Redis、MongoDB，我們在架構設計上都是相通的。
針對多機的架構，常見有如下做法：
-
單中心資料叢集
-
多中心資料分割槽
下麵我們來具體看看：
一、單中心的資料叢集架構（單中心多機）
單資料中心多機器的叢集又可以分為：
-
資料集中樣式
-
資料分散樣式
這兩種的主要區別在於叢集中的完整業務資料是全部集中在一臺機器上，但是分散在多臺機器上。
-
資料集中樣式
這種樣式與「一主一從式」（主從式）比較類似，完整的業務資料還是儲存在一臺主機的上，主機承擔讀服務和寫服務，從機只承擔讀服務。但是從機有多臺機器，從機實時的從主機同步資料。所以這種樣式，也可以理解為「一主多從」式。
因為有多個從機，那麼也給這種架構帶來了一些額外需要處理問題，比如：
1.1，主機需要實時的將資料同步到多臺從機上，涉及到主機的處理壓力問題。
1.2，需要保障多臺從機之間的資料一致性的問題，如果出現資料不一致，如何處理。
1.3，多臺從機是如何檢測主機狀態的，因為從機在關鍵時刻是要替換主機的，那麼如果多臺從機監測到的主機狀態不一致，那又可能會帶來其它問題。
1.4，從機切換為主機的時候，選擇哪一臺從機來切換呢，這涉及到多臺從機之間如何進行選舉的問題。
這些問題，在我們進行架構設計的時候，必須提前考慮。不過市面上也有一些工具可以輔助實現，例如 ZooKeeper等。
另外，由於資料集中樣式的所有寫操作都只到一臺主機上，而讀操作可以到N臺從機上。因此這種樣式比較適用於業務資料量不大、讀操作遠遠大於寫操作、叢集規模較小的業務場景。
-
資料分散樣式
資料分散樣式是指，完整的業務資料並非是全部儲存在一臺主機上的，而是由多臺主機共同分擔，分散儲存。因此這種樣式適用於大資料量、叢集規模較大的場景。
使用這種樣式，也有幾點需要特別註意的：
1.1，儘量將資料均衡的分散的各個機上，這樣才能保證資源的均衡使用和效能的最佳。
1.2，多臺機器上的資料雖然不同，但是也需要互相進行資料的備份。
1.3，要能動態的增加和刪除節點，這樣可以便於隨時擴充套件，通常採用一致性HASH的方法。
聊完了單資料中心的叢集架構，我們再來看看多資料中心的資料分割槽架構。
二、多中心的資料分割槽架構（多中心多機）
出於容災的考慮，通常會在多個不同地區部署多套的資料叢集。畢竟在國內運營商網路故障、光纖被山東藍翔技工鏟斷等事件還是不少的。輕則一個機房出問題，重則一個城市一個省份都可能故障。
如果我們資料儲存服務只部署在一個機房，那如果這個機房出現了故障，很有可能導致不能服務甚至是無法恢復業務了。因此我們就需要考慮多中心的資料分割槽架構，將資料按照一定的規則進行分割槽，部署在不同機房/城市裡，且每一個分割槽都儲存一部分資料，透過這種方式來保障資料和服務的可用性。
在多中心的資料分割槽樣式下，我們需要提前規劃 “分割槽規則” 。畢竟將資料在地理位置上分割槽，在網路通訊方面是有時延的，所以必須要考慮好我們是要以區域、還是以城市、還是省份來分節點部署。
除了 “分割槽規則” ，我們還需要考慮 “備份規則” 。
因為分割槽之後，各區都只儲存一部分資料，並不是完整資料。如果其中一個區出故障了，雖然不會影響全域性，但是也會帶來一定損失。因此我們需要考慮將每個區裡的資料備份起來，備份有幾種方式：
-
集中備份式
-
獨立備份式
-
相互備份式
下麵將這三種備份方式解釋一下：
-
集中備份式
集中備份式是指建立一個獨立的資料備份中心，將各分割槽（節點）的資料都定期同步到這個備份中心，以保障資料的安全性。這種備份方式可以隨意的擴充套件分割槽（節點），不受分割槽的個數限制，並且結構很簡單。但是
這種備份方式的缺點就是，投入成本有點高，因為需要額外建立這麼一個備份資料中心，平時也是閑置的，有點浪費資源。另外，備份中心自身也可能會有單點的故障，且備份中心中需儲存多個分割槽的資料，還可能會互相受到影響。
-
獨立備份式
獨立備份式就是給每一個資料分割槽（節點）都建立一個額外的備份節點，這個備份節點部署在不同的地域/城市，這樣才能起到容災的作用。
這種備份方式相比較於 集中備份式 ，建設成本就更大一些了，畢竟每一個分割槽都需要額外建立一個備份節點。但是結構更清晰簡單了，而且各個分割槽的資料之間還可以做到互不影響，完全是獨立的。後續擴充套件分割槽（節點）的時候，對前面的備份節點也沒有影響，擴充套件性好。
-
相互備份式
相互備份式其實是結合了上面兩種特性在一起的樣式。上面的方式不是成本大麼，那麼這種方式就不額外建立備份中心了，讓各個分割槽（節點）互相備份資料。比如 分割槽A 將自身資料同步一份給 分割槽B備份著，分割槽B 將自己的資料同步一份給 分割槽A 備份著，如果是三個以上分割槽，還可以做到迴圈備份。
這種備份方式，設計稍微複雜一些，擴充套件性也弱一些，但是可以節約資源。
無論採用哪種方式，都需要結合實際的業務場景來決定。
以上，就是對資料庫在多機叢集樣式下的技術架構的分享，歡迎大家一起交流。
轉載自：不止思考。
投稿：有投稿意向技術人請在公眾號對話方塊留言。
轉載：意向文章下方留言。
更多精彩請關註 “資料和雲” 公眾號 。
