是時候java
關注mysql
咱們一波了sql
看多了應用服務的高可用架構，咱們來看看數據庫的高可用吧。
數據庫
數據存儲高可用的方案本質都是經過將數據複製到多個存儲設備，經過數據冗餘的方式來實現高可用。常見的高可用架構有主備、主從、主從切換、主主等接下來咱們聊聊每種架構的優缺點。
安全
主備架構
一、基本架構拓撲圖以下微信
總體架構簡單，幾乎全部的數據庫都提供了主備複製的功能，例如Mysql、Oracle、MongoDB等。在這種架構中備庫主要承擔數據備份的做用，不參與實際業務讀寫操做，若是把備機改爲主機須要人工操做。架構
二、優缺點分析 主備架構的優勢就是簡單，具體表現有：app
-
對於客戶端來講，不須要感知備機的存在，即便災難恢復後，原來的備機被人工干預修改成主機，客戶端只須要簡單修改鏈接地址便可，應用架構不須要作任何改動； -
主機和備機只須要進行數據複製，不須要進行狀態判斷和主備切換這類複雜操做。
這種架構的缺點也比較明顯：運維
-
備機主要是用於數據備份，若是應用架構沒有讀寫分離設計時會形成成本浪費 -
故障後須要人工干預，沒法自動恢復，而人工處理效率又比較低，恢復過程也容易出錯。
主從架構
主從架構與主備架構只有一字之差，可是對於實際應用架構差距卻很大。在主備架構中備庫不參與業務操做，而在主從架構中從庫是須要參與業務操做的，應用架構須要作讀寫分離，將寫操做寫入主庫，而讀操做從從庫讀。性能
一、主從基本架構拓撲圖以下
二、優缺點分析 這種架構在少許寫和大量讀時很是有用。能夠把讀分攤到多個備庫上，減小主庫的壓力，直到從庫給主庫形成了太大的負擔，或者主從之間的帶寬成爲瓶頸爲止。
相比於主備架構，它有以下優勢：
-
在主庫故障時，讀操做相關業務能夠繼續運行 -
從庫對外提供讀能力，發揮了硬件的性能 -
能夠爲不一樣的角色提供不一樣的從庫
缺點：
-
主從架構中從庫須要提供讀業務，若是主從複製延遲大，數據會出現不一致狀況； -
應用架構須要作修改，通常會加入讀寫分離，複雜度比主備高； -
故障後須要人工干預，沒法自動恢復，而人工處理效率又比較低，恢復過程也容易出錯。
主從切換
上面兩種架構都存在兩個共同問題：
-
主庫故障後，沒法進行寫操做 -
主庫出了問題後須要人工干預才能將從庫切換到主庫，而人工切換又可能出現不及時或者切換故障的問題。
基於以上兩個問題咱們須要一個能自動切換的架構，當主庫出了故障後能自動將從庫切換成主庫，無需運維人員干預。要實現主從切換架構必需要考慮一個關鍵點：必需要有一個機制能監測到數據庫節點的運行狀態，以此來決定是否切換。這種架構咱們通常會引入一個第三方中介，數據庫節點定時向第三方中介彙報本身的狀態信息；或者第三方中介定時去數據庫節點拉取數據庫狀態；
優勢：
-
解決了人工干預的問題，大大減小了故障時間，必定程度上保護了運維人員的人生安全 缺點： -
架構複雜，引入了第三方中介後又須要保證第三方中介的高可用。
這裏推薦你們瞭解一下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，並且沒有任何複製錯誤，一旦出了問題須要很久才能定位。因此主主架構必需要保證數據可以雙向複製，對數據的設計有嚴格的要求，通常適用於那些臨時性，可丟失、可覆蓋的數據場景。
舒適提示
若是你喜歡本文，請分享到朋友圈，想要得到更多信息，請關注我。
本文分享自微信公衆號 - JAVA日知錄（javadaily）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。