在互聯網項目中，當業務規模越來越大，數據越來越多，隨之而來的就是數據庫壓力會越來越大。慢慢就會發現，數據庫層可能已經成為了整個系統的關鍵點和性能瓶頸了，因此實現數據層的高可用就成為了我們項目中經常要解決的問題。
本文我們就來聊一聊如何實現數據存儲層的高可用方案。在保障數據層的高性能與高穩定方面，最容易想到的方式就是對數據進行分片、多份、冗余等，很多架構的本質其實也是基於這幾點來實現的。
這里先不看細節，即先不管底層數據源是什么數據庫，我們先只聊架構方案，因為無論底層是關系型數據庫，還是NoSQL數據庫，無論是 Mysql 還是 Redis、MongoDB，我們在架構設計上都是相通的。
大體上，單中心雙機的常見方案有以下這些：
-
一主一備的架構（主備式）
-
一主一從的架構（主從式）
-
互為主從的架構（主主式）
以上方案從上至下，依次是從簡單到復雜，從基礎到豐富。下面我們來具體看看：
一、一主一備的架構（主備式）
主備式架構是雙機部署中最簡單的一種架構了，幾乎市面上所有的數據庫系統都會自帶這個主備功能。
如圖，
其思路也特別的簡單：將數據庫部署到兩台機器，其中一台機器（代號A）作為日常提供數據讀寫服務的機器，稱為「主機」。另外一台機器（代號B）並不提供線上服務，但會實時的將「主機」的數據同步過來，稱為「備機」。一旦「主機」出了故障，通過人工的方式，手動的將「主機」踢下線，將「備機」改為「主機」來繼續提供服務。
這個架構的優缺點都很明顯，優點就是幾乎不需要做什么開發改造，各類數據庫就支持這種模式，部署維護起來也簡單，並沒有引入額外的系統復雜度和瓶頸。
但是缺點呢，就是當「主機」出現故障的時候，需要人工去干預啊，運維同學很辛苦的，而且處理還不一定及時。再還有一個缺點就是，主備架構會造成嚴重浪費資源，畢竟需要一台與「主機」同等配置的「備機」長期備着，但又不作為線上服務來使用，你說浪費不浪費。
為了解決這個資源浪費問題，我們就得想一個把「備機」也用起來的方案：主從式架構。
二、一主一從的架構（主從式）
主從式架構大體上與上述的主備式架構差不多。區別就是主備式的「備機」平時是不干活的的，主要起到備份的作用。而主從式的「備機」改為了「從機」，平時也要提供服務，跟「主機」一樣隨時隨刻的在干活的。
如圖，
主從式架構中的「從機」雖然也在隨時隨刻提供服務，但是它只提供「讀」服務，並不提供「寫」服務。「主機」會實時的將線上數據同步到「從機」，以保證「從機」能夠正常的提供讀操作。
這種架構相比較主備式，對資源是一種節約，畢竟「從機」也在提供服務，沒有白白的浪費。並且在「主機」出現故障時，在人工介入之前，好歹「從機」也是能夠提供數據的「讀」操作的，畢竟大多數業務都是「讀」多「寫」少，因此對穩定性又提高了一個層次。
缺點就是架構稍微復雜了一點，畢竟「主機」和「從機」都有「讀」服務，那么前端業務系統就需要用一定策略去判斷該路由到哪一台去讀取數據。還有就是，延遲問題，「主機」的數據同步到「從機」難免會有一定程度的延遲，這個延遲可能會對數據實時性要求較高的業務有一定影響。
通過上面內容可以看到，雖然這個架構一定程度解決了資源浪費，但是並沒有解決人工干預的問題，當出現了故障后還是需要人工去處理。
如果想讓架構更智能一點，那么我們就需要引入「主從雙機自動切換」的功能。
主從雙機自動切換：是指當主機出現故障后，從機能夠自動檢測發現。同時從機將自己迅速切換為主機，將原來的主機立即下線服務，或轉換為從機狀態。
要實現「主從雙機自動切換」，有幾個關鍵點需要考慮：
-
主機與從機之間的狀態如何判斷？
必須有一個機制能監測兩台機器的運行狀態，以此來決定是否應該切換。
我們比較常用的狀態傳遞方式有兩種：
-
「雙機互連模式」
-
「第三方中介模式」
「雙機互連模式」：是指在主機和從機之間建立一條用於狀態通訊的通道。通過這個通道，主機和從機之間可以共享服務狀態，一旦發現對方宕機或者停止服務了，就可以立即將自己切換為主服務。不過這種方式需要關注通道的健壯性，一旦通道自身不穩定了，可能會導致假消息出現，比如主機並沒有宕機，但是通道壞了，導致從機以為出現了異常，就將自己切換為了主機，那就出現了2個主機了，因此通道本身也是一個可能的故障點。
「第三方中介模式」：是指在主機和從機之外，再建立一個中介機器，這個中介機器專門用來維護各節點（主機/從機）狀態的，主機/從機實時的將自身狀態上報給中介機器，中介機器來決定是否應該切換、何時切換。MongoDB的Replica Set就是采用的這種模式。
-
除了狀態判斷，還需要考慮切換的策略是什么？ 也就是說發生異常幾次/多久后開始切換，是否有一個緩沖機制等。另外切換完成后，當原主機又恢復正常之后是否需要自動再切換回來等策略。
-
另外就是需要注意在切換過程中雙機數據如果發生沖突時，以哪個為准？處理機制是什么。
這些細節都是在設計主從自動切換架構時候，要提前規划的。
三、互為主從的架構（主主式）
互為主從的架構是指兩台機器自己都是主機，並且也都是作為對方的從機。兩台機器都提供完整的讀寫服務，因此無需切換，客戶機在調用的時候隨機挑選一台即可，當其中一台宕機了，另外一台還可以繼續服務。
如圖，
采用 互為主從架構 有個復雜點就是，因為兩台主機都接受寫數據，那就需要將寫的最新數據實時的同步給對方，需要將數據進行兩台主機的雙向復制。而雙向復制不可避免的會在一定程度上帶來數據延遲、極端情況下甚至有數據丟失等問題。在實際業務中，有些業務數據對一致性要求是非常高的，並不能接受數據的延遲、丟失，因此這類業務也不適合互為主從的模式，比如金融業務。但是我們互聯網業務中大多數場景還是沒有這么高要求的，所以這種模式對於一般場景還是用的蠻多。
以上，就是對數據庫從主備架構、到主從架構、再到主主架構的高可用方案基本講解了，接下來會繼續分享數據庫在多機集群模式下的技術架構，歡迎大家關注交流。
本文原創發布於微信公眾號「 不止思考 」，交流Java、Web、架構、大數據、職業發展、技術管理，歡迎關注。
