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