看多了應用服務的高可用架構，我們來看看數據庫的高可用吧。
數據存儲高可用的方案本質都是通過將數據複製到多個存儲設備，通過數據冗餘的方式來實現高可用。常見的高可用架構有主備、主從、主主、集群、分區等，接下來我們聊聊每種架構的優缺點。
主備架構
1、基本架構拓撲圖如下
整體架構簡單，幾乎所有的數據庫都提供了主備複製的功能，例如Mysql、Oracle、MongoDB等。在這種架構中備庫主要承擔數據備份的作用，不參與實際業務讀寫操作，如果把備機改成主機需要人工操作。
2、優缺點分析
主備架構的優點就是簡單，具體表現有：
- 對於客戶端來說，不需要感知備機的存在，即使災難恢復後，原來的備機被人工干預修改為主機，客戶端只需要簡單修改連接地址即可，應用架構不需要做任何改動；
- 主機和備機只需要進行數據複製，不需要進行狀態判斷和主備切換這類複雜操作。
這種架構的缺點也比較明顯：
- 備機主要是用於數據備份，如果應用架構沒有讀寫分離設計時會造成成本浪費
- 故障後需要人工干預，無法自動恢復，而人工處理效率又比較低，恢復過程也容易出錯。
主從架構
主從架構與主備架構只有一字之差，但是對於實際應用架構差距卻很大。在主備架構中備庫不參與業務操作，而在主從架構中從庫是需要參與業務操作的，應用架構需要做讀寫分離，將寫操作寫入主庫，而讀操作從從庫讀。
1、主從基本架構拓撲圖如下
2、優缺點分析
這種架構在少量寫和大量讀時非常有用。可以把讀分攤到多個備庫上，減少主庫的壓力，直到從庫給主庫造成了太大的負擔，或者主從之間的帶寬成為瓶頸為止。
相比於主備架構，它有如下優點：
- 在主庫故障時，讀操作相關業務可以繼續運行
- 從庫對外提供讀能力，發揮了硬件的性能
- 可以為不同的角色提供不同的從庫
缺點：
- 主從架構中從庫需要提供讀業務，如果主從複製延遲大，數據會出現不一致情況；
- 應用架構需要做修改，一般會加入讀寫分離，複雜度比主備高；
- 故障後需要人工干預，無法自動恢復，而人工處理效率又比較低，恢復過程也容易出錯。
主從切換
上面兩種架構都存在兩個共同問題：
- 主庫故障後，無法進行寫操作
- 主庫出了問題後需要人工干預才能將從庫切換到主庫，而人工切換又可能出現不及時或者切換故障的問題。
基於以上兩個問題我們需要一個能自動切換的架構，當主庫出了故障後能自動將從庫切換成主庫，無需運維人員干預。
要實現主從切換架構必須要考慮一個關鍵點：必須要有一個機制能監測到數據庫節點的運行狀態，以此來決定是否切換。
這種架構我們一般會引入一個第三方中介，數據庫節點定時向第三方中介彙報自己的狀態信息；或者第三方中介定時去數據庫節點拉取數據庫狀態；
優點：
- 解決了人工干預的問題，大大減少了故障時間，一定程度上保護了運維人員的人生安全
缺點： - 架構複雜，引入了第三方中介後又需要保證第三方中介的高可用。
這裡推薦大家瞭解一下mysql的 MHA 架構，或者使用ZK、Keepalived自己搭建主從切換架構。
主主架構
主主架構又叫主主複製，兩臺數據庫都是主庫，互相將數據複製給對方，客戶端可以挑選任意一臺數據庫進行讀寫操作。
相比於主從切換，主主架構有如下優點：
- 兩臺數據庫都是主庫，不存在切換的概念
- 客戶端無需區分不同角色的主機，隨便將讀寫操作發給哪臺數據庫。
- 架構簡單
但是允許向兩臺主數據庫寫入是一件很危險的事：
- AB兩臺數據庫採用自增長主鍵，A庫插入用戶後id是1，B庫插入用戶後id也是1，數據衝突
- 同時對數據庫數據進行更新會出現大問題，加入AB庫的表 tb 都有1個字段col，數值為1。如A庫執行 update tb set col = col +1 ,B庫執行 update tb set col = col * 2 ,最終執行完一臺數據的值變成了4，另一臺數據庫的值變成了3，而且沒有任何複製錯誤，一旦出了問題需要好久才能定位。
所以主主架構必須要保證數據能夠雙向複製，對數據的設計有嚴格的要求，一般適用於那些臨時性，可丟失、可覆蓋的數據場景。
閱讀更多 努力的程序員 的文章
