數(shù)據(jù)庫高可用架構(gòu)了解一下

看多了應(yīng)用服務(wù)的高可用架構(gòu)，我們來看看數(shù)據(jù)庫的高可用吧。

數(shù)據(jù)存儲高可用的方案本質(zhì)都是通過將數(shù)據(jù)復(fù)制到多個存儲設(shè)備，通過數(shù)據(jù)冗余的方式來實(shí)現(xiàn)高可用。常見的高可用架構(gòu)有主備、主從、主主、集群、分區(qū)等，接下來我們聊聊每種架構(gòu)的優(yōu)缺點(diǎn)。

主備架構(gòu)

1. 基本架構(gòu)拓?fù)鋱D如下

整體架構(gòu)簡單，幾乎所有的數(shù)據(jù)庫都提供了主備復(fù)制的功能，例如Mysql、Oracle、MongoDB等。在這種架構(gòu)中備庫主要承擔(dān)數(shù)據(jù)備份的作用，不參與實(shí)際業(yè)務(wù)讀寫操作，如果把備機(jī)改成主機(jī)需要人工操作。

2. 優(yōu)缺點(diǎn)分析
   主備架構(gòu)的優(yōu)點(diǎn)就是簡單，具體表現(xiàn)有：

• 對于客戶端來說，不需要感知備機(jī)的存在，即使災(zāi)難恢復(fù)后，原來的備機(jī)被人工干預(yù)修改為主機(jī)，客戶端只需要簡單修改連接地址即可，應(yīng)用架構(gòu)不需要做任何改動；
• 主機(jī)和備機(jī)只需要進(jìn)行數(shù)據(jù)復(fù)制，不需要進(jìn)行狀態(tài)判斷和主備切換這類復(fù)雜操作。

這種架構(gòu)的缺點(diǎn)也比較明顯：

• 備機(jī)主要是用于數(shù)據(jù)備份，如果應(yīng)用架構(gòu)沒有讀寫分離設(shè)計時會造成成本浪費(fèi)
• 故障后需要人工干預(yù)，無法自動恢復(fù)，而人工處理效率又比較低，恢復(fù)過程也容易出錯。

主從架構(gòu)

主從架構(gòu)與主備架構(gòu)只有一字之差，但是對于實(shí)際應(yīng)用架構(gòu)差距卻很大。在主備架構(gòu)中備庫不參與業(yè)務(wù)操作，而在主從架構(gòu)中從庫是需要參與業(yè)務(wù)操作的，應(yīng)用架構(gòu)需要做讀寫分離，將寫操作寫入主庫，而讀操作從從庫讀。

1. 主從基本架構(gòu)拓?fù)鋱D如下
2. 優(yōu)缺點(diǎn)分析
   這種架構(gòu)在少量寫和大量讀時非常有用。可以把讀分?jǐn)偟蕉鄠€備庫上，減少主庫的壓力，直到從庫給主庫造成了太大的負(fù)擔(dān)，或者主從之間的帶寬成為瓶頸為止。

相比于主備架構(gòu)，它有如下優(yōu)點(diǎn)：

• 在主庫故障時，讀操作相關(guān)業(yè)務(wù)可以繼續(xù)運(yùn)行
• 從庫對外提供讀能力，發(fā)揮了硬件的性能
• 可以為不同的角色提供不同的從庫

缺點(diǎn)：

• 主從架構(gòu)中從庫需要提供讀業(yè)務(wù)，如果主從復(fù)制延遲大，數(shù)據(jù)會出現(xiàn)不一致情況；
• 應(yīng)用架構(gòu)需要做修改，一般會加入讀寫分離，復(fù)雜度比主備高；
• 故障后需要人工干預(yù)，無法自動恢復(fù)，而人工處理效率又比較低，恢復(fù)過程也容易出錯。

主從切換

上面兩種架構(gòu)都存在兩個共同問題：

• 主庫故障后，無法進(jìn)行寫操作
• 主庫出了問題后需要人工干預(yù)才能將從庫切換到主庫，而人工切換又可能出現(xiàn)不及時或者切換故障的問題。

基于以上兩個問題我們需要一個能自動切換的架構(gòu)，當(dāng)主庫出了故障后能自動將從庫切換成主庫，無需運(yùn)維人員干預(yù)。
要實(shí)現(xiàn)主從切換架構(gòu)必須要考慮一個關(guān)鍵點(diǎn)：必須要有一個機(jī)制能監(jiān)測到數(shù)據(jù)庫節(jié)點(diǎn)的運(yùn)行狀態(tài)，以此來決定是否切換。
這種架構(gòu)我們一般會引入一個第三方中介，數(shù)據(jù)庫節(jié)點(diǎn)定時向第三方中介匯報自己的狀態(tài)信息；或者第三方中介定時去數(shù)據(jù)庫節(jié)點(diǎn)拉取數(shù)據(jù)庫狀態(tài)；

優(yōu)點(diǎn)：

• 解決了人工干預(yù)的問題，大大減少了故障時間，一定程度上保護(hù)了運(yùn)維人員的人生安全 缺點(diǎn)：
• 架構(gòu)復(fù)雜，引入了第三方中介后又需要保證第三方中介的高可用。

這里推薦大家了解一下mysql的 MHA架構(gòu)，或者使用ZK、Keepalived自己搭建主從切換架構(gòu)。

主主架構(gòu)

主主架構(gòu)又叫主主復(fù)制，兩臺數(shù)據(jù)庫都是主庫，互相將數(shù)據(jù)復(fù)制給對方，客戶端可以挑選任意一臺數(shù)據(jù)庫進(jìn)行讀寫操作。

相比于主從切換，主主架構(gòu)有如下優(yōu)點(diǎn)：

• 兩臺數(shù)據(jù)庫都是主庫，不存在切換的概念
• 客戶端無需區(qū)分不同角色的主機(jī)，隨便將讀寫操作發(fā)給哪臺數(shù)據(jù)庫。
• 架構(gòu)簡單

但是允許向兩臺主數(shù)據(jù)庫寫入是一件很危險的事：

• AB兩臺數(shù)據(jù)庫采用自增長主鍵，A庫插入用戶后id是1，B庫插入用戶后id也是1，數(shù)據(jù)沖突
• 同時對數(shù)據(jù)庫數(shù)據(jù)進(jìn)行更新會出現(xiàn)大問題，加入AB庫的表tb都有1個字段col，數(shù)值為1。如A庫執(zhí)行update tb set col = col +1,B庫執(zhí)行update tb set col = col * 2,最終執(zhí)行完一臺數(shù)據(jù)的值變成了4，另一臺數(shù)據(jù)庫的值變成了3，而且沒有任何復(fù)制錯誤，一旦出了問題需要好久才能定位。所以主主架構(gòu)必須要保證數(shù)據(jù)能夠雙向復(fù)制，對數(shù)據(jù)的設(shè)計有嚴(yán)格的要求，一般適用于那些臨時性，可丟失、可覆蓋的數(shù)據(jù)場景。