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