雖說我們的機子(服務器)在絕大部分下是可靠的,但是還是會有意外發(fā)生。

單點故障的情況不可避免，而且單副本的存儲方案早已無法滿足業(yè)務的可靠性要求，單機可靠性就就兩個9，也就是一年大概有3.65天不可用。因此一般情況下我們至少也會上個雙機存儲架構。凡事最好有個plan B。

主備

主：主機，備：備機。主機的意思當然是以它為主了，讀寫都是主機上，而備機呢就是備用，默默的在背后吸收主機的數(shù)據(jù)，時刻待命著等待主機掛了之后取而代之(沒這么壞哈哈)。因此在主機還活著的情況下，備機的唯一使命就是同步主機的數(shù)據(jù)，不對外提供服務。

優(yōu)點：簡單，主備之間只有數(shù)據(jù)同步，不需要考慮別的情況。就很簡單的配置一下，再搞一臺服務器就能組成主備架構了。

缺點：備機等于就拿來備份，浪費了備機這臺服務器的資源。上面說的不考慮別的情況指的是主機和備機它們兩之間就只要復制數(shù)據(jù)，但是有些情況我們人還是得考慮的：主機掛了如何讓備機上。

有三種選擇

1. 人工切換。人工切換時效性不高，出了事情首先你得開機，登錄遠程一陣啪啪得好幾分鐘或者萬一你在LOL，黑鐵晉級青銅最后一把努力了幾個月即將晉升倔強青銅的一刻！是吧。還要萬一在深夜或者說....是吧。

2. 引入中間件。例如ZooKeeper、keepalived。就跟好多房東把房子委托給中介一樣，這中間件就是個中介。全權由中介來打理主機和備機，它會根據(jù)機子狀態(tài)來判別這時候是不是該備機上了。(建議)

3. 主機備機之間狀態(tài)傳輸(咱不找中介了，自己來打理)，啥意思呢？就是除數(shù)據(jù)同步，主備之間還要有個狀態(tài)傳輸過程，來讓備機只要現(xiàn)在主機過得好不好，可以是主機主動推送它的狀態(tài)給備機，或者是備機去索要狀態(tài)。當狀態(tài)拿不到或者不對的時候就開始主備切換。但是可能傳輸出現(xiàn)了波動啥的，導致備機誤判了，然后備機升級為主機，這樣就兩主機了(下面會說主主的問題)。

主從

主：主機，從：從機

從機和備機的區(qū)別在于它得除了同步數(shù)據(jù)之外還得干活，對外提供讀的操作，你可以理解為它是仆從。但是仆從和備機一樣也有翻身做主人的一天，所以它也在默默的等待著主機掛了，取而代之。

優(yōu)點：充分利用了資源，嘿嘿不想備機這么爽了，還得出來干活，對外提供讀操作。而且在主機掛了的時候，如果沒任命新機主之前，讀操作還是能用的。

缺點：

1. 客戶端需要多個判斷，也就是不同操作需要發(fā)放給不同服務器，我上圖主機提供讀寫，有時候讀寫分離了，主機就提供寫。

2. 主從延遲，讀操作分配給從庫，就會存在數(shù)據(jù)同步的延遲問題，比如某個人注冊了賬號之后，登錄走的是從機，這時候數(shù)據(jù)還未從主機同步過來，那可不讓人很難受了。有關主從延遲問題的一些解決辦法

3. 和主備一樣的切換問題。(參考主備)

主主

主主就是兩臺都是主機。同時對外提供讀寫操作?？蛻舳巳我庠L問提供的一臺。

優(yōu)點：主主的好處就是可以把寫操作也分擔一下，但是問題恰恰就出在寫操作上，導致主主的架構有很大的局限性。

缺點：例如主機A有個注冊的插入操作，生成的id是50，同一時刻主機B也有個插入操作生成的id也是50。然后它們之間的數(shù)據(jù)同步了，你說是誰覆蓋誰呢？誰覆蓋誰都不對！

因此主主只適用于可以雙向復制，覆蓋的數(shù)據(jù)(例如用戶登錄生成的token)。但是我們平日里絕大部分的數(shù)據(jù)都不允許。

結語

這種雙機存儲架構一般而言應用于一些業(yè)務量不大的場景。主要還是為了存儲的可用性。

特別推薦一個分享架構+算法的優(yōu)質內容，還沒關注的小伙伴，可以長按關注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝