高可用架構(gòu)對于互聯(lián)網(wǎng)服務(wù)基本是標(biāo)配，無論是應(yīng)用服務(wù)還是數(shù)據(jù)庫服務(wù)都需要做到高可用。雖然互聯(lián)網(wǎng)服務(wù)號稱7*24小時(shí)不間斷服務(wù)，但多多少少有一些時(shí)候服務(wù)不可用，比如某些時(shí)候網(wǎng)頁打不開，百度不能搜索或者無法發(fā)微博，發(fā)微信等。一般而言，衡量高可用做到什么程度可以通過一年內(nèi)服務(wù)不可用時(shí)間作為參考，要做到3個(gè)9的可用性，一年內(nèi)只能累計(jì)有8個(gè)小時(shí)不可服務(wù)，而如果要做到5個(gè)9的可用性，則一年內(nèi)只能累計(jì)5分鐘服務(wù)中斷。所以雖說每個(gè)公司都說自己的服務(wù)是7*24不間斷的，但實(shí)際上能做到5個(gè)9的屈指可數(shù)，甚至根本做不到，國內(nèi)互聯(lián)網(wǎng)巨頭BAT(百度，阿里巴巴，騰訊)都有因?yàn)楣收蠈?dǎo)致的停服問題。對于一個(gè)系統(tǒng)而言，可能包含很多模塊，比如前端應(yīng)用，緩存，數(shù)據(jù)庫，搜索，消息隊(duì)列等，每個(gè)模塊都需要做到高可用，才能保證整個(gè)系統(tǒng)的高可用。對于數(shù)據(jù)庫服務(wù)而言，高可用可能更復(fù)雜，對用戶的服務(wù)可用，不僅僅是能訪問，還需要有正確性保證，因此討論數(shù)據(jù)庫的高可用方案時(shí)，一般會同時(shí)考慮方案中數(shù)據(jù)一致性問題。今天這篇文章主要討論MySQL數(shù)據(jù)庫的高可用方案，介紹每種方案的特性以及優(yōu)缺點(diǎn)，本文是對各種方案的總結(jié)，希望拋磚引玉，和大家一起討論。

1.基于共享存儲的方案SAN
方案介紹：SAN(Storage Area Network)簡單點(diǎn)說就是可以實(shí)現(xiàn)網(wǎng)絡(luò)中不同服務(wù)器的數(shù)據(jù)共享，共享存儲能夠?yàn)閿?shù)據(jù)庫服務(wù)器和存儲解耦。使用共享存儲時(shí)，服務(wù)器能夠正常掛載文件系統(tǒng)并操作，如果服務(wù)器掛了，備用服務(wù)器可以掛載相同的文件系統(tǒng)，執(zhí)行需要的恢復(fù)操作，然后啟動(dòng)MySQL。共享存儲的架構(gòu)如下:

優(yōu)點(diǎn):
1.可以避免存儲外的其它組件引起的數(shù)據(jù)丟失。
2.部署簡單，切換邏輯簡單，對應(yīng)用透明。
3.保證主備數(shù)據(jù)的強(qiáng)一致。
限制或缺點(diǎn):
1.共享存儲是單點(diǎn)，若共享存儲掛了，則會丟失數(shù)據(jù)。
2.價(jià)格比價(jià)昂貴。

2.基于磁盤復(fù)制的方案 DRBD
方案介紹：DRBD(Distributed Replicated Block Device)是一種磁盤復(fù)制技術(shù)，可以獲得和SAN類似的效果。DBRD是一個(gè)以linux內(nèi)核模塊方式實(shí)現(xiàn)的塊級別同步復(fù)制技術(shù)。它通過網(wǎng)卡將主服務(wù)器的每個(gè)塊復(fù)制到另外一個(gè)服務(wù)器塊設(shè)備上，并在主設(shè)備提交塊之前記錄下來。DRBD與SAN類似，也是有一個(gè)熱備機(jī)器，開始提供服務(wù)時(shí)會使用和故障機(jī)器相同的數(shù)據(jù)，只不過DRBD的數(shù)據(jù)是復(fù)制存儲，不是共享存儲。DRBD的架構(gòu)圖如下：

優(yōu)點(diǎn)：
1.切換對應(yīng)用透明
2.保證主備數(shù)據(jù)的強(qiáng)一致。
限制或缺點(diǎn)：
1.影響寫入性能，由于每次寫磁盤，實(shí)質(zhì)都需要同步到網(wǎng)絡(luò)服務(wù)器。
2.一般配置兩節(jié)點(diǎn)同步，可擴(kuò)展性比較差
3.備庫不能提供讀服務(wù)，資源浪費(fèi)

3.基于主從復(fù)制(單點(diǎn)寫)方案
前面討論的兩種方案分別依賴于底層的共享存儲和磁盤復(fù)制技術(shù)，來解決MYSQL服務(wù)器單點(diǎn)和磁盤單點(diǎn)的問題。而實(shí)際生產(chǎn)環(huán)境中，高可用更多的是依賴MySQL本身的復(fù)制，通過復(fù)制為Master制作一個(gè)或多個(gè)熱副本，在Master故障時(shí)，將服務(wù)切換到熱副本。下面的幾種方案都是基于主從復(fù)制的方案，方案由簡單到復(fù)雜，功能也越來越強(qiáng)大，實(shí)施難度由易到難，各位可以根據(jù)實(shí)際情況選擇合適的方案。
3.1.keepalived/heartbeat
方案介紹：
keepalived是一個(gè)HA軟件，它的作用是檢測服務(wù)器(web服務(wù)器，DB服務(wù)器等)狀態(tài)，檢查原理是模擬網(wǎng)絡(luò)請求檢測，檢測方式包括HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK等。對于DB服務(wù)器而言，主要就是IP,端口(TCP_CHECK)，但這可能不夠(比如DB服務(wù)器ReadOnly)，因此keepalived也支持自定義腳本。keepalived通過監(jiān)聽來確認(rèn)服務(wù)器的狀態(tài)，如果發(fā)現(xiàn)服務(wù)器故障，則將故障服務(wù)器從系統(tǒng)中剔除。keepalived的高可用架構(gòu)如下圖，分別在主、從服務(wù)器上安裝keepalived的軟件，并配置同樣的VIP，VIP層將真實(shí)IP屏蔽，應(yīng)用服務(wù)器通過訪問VIP來獲取DB服務(wù)。當(dāng)Master故障時(shí)，keepalived感知，并將Slave提升主，繼續(xù)提供服務(wù)對應(yīng)用層透明。

優(yōu)點(diǎn)：
1. 安裝配置簡單
2. Master故障時(shí)，Slave快速切換提供服務(wù)，并且對應(yīng)用透明。
限制或缺點(diǎn)：
1.需要主備的IP在同一個(gè)網(wǎng)段。
2.提供的檢測機(jī)制比較弱，需要自定義腳本來確定Master是否能提供服務(wù)，比如更新心跳表等。
3.無法保證數(shù)據(jù)的一致性，原生的MySQL采用異步復(fù)制，若Master故障，Slave數(shù)據(jù)可能不是最新，導(dǎo)致數(shù)據(jù)丟失，因此切換時(shí)要考慮Slave延遲的因素，確定切換策略。對于強(qiáng)一致需求的場景，可以開啟(semi-sync)半同步，來減少數(shù)據(jù)丟失。
4.keepalived軟件自身的HA無法保證。

3.2.MHA
方案介紹：MHA(Master High Availability)是一位日本MySQL大牛用Perl寫的一套MySQL故障切換方案，來保證數(shù)據(jù)庫的高可用，MHA通過從宕機(jī)的主服務(wù)器上保存二進(jìn)制日志來進(jìn)行回補(bǔ)，能在最大程度上減少數(shù)據(jù)丟失。MHA由兩部分組成：MHA Manager（管理節(jié)點(diǎn)）和MHA Node（數(shù)據(jù)節(jié)點(diǎn)）。MHA可以單獨(dú)部署在一臺獨(dú)立的機(jī)器上管理多個(gè)master-slave集群，MHA Node運(yùn)行在每臺MySQL服務(wù)器上，主要作用是切換時(shí)處理二進(jìn)制日志，確保切換盡量少丟數(shù)據(jù)。MHA Manager會定時(shí)探測集群中的master節(jié)點(diǎn)，當(dāng)master出現(xiàn)故障時(shí)，它可以自動(dòng)將最新數(shù)據(jù)的slave提升為新的master，然后將所有其他的slave重新指向新的master，整個(gè)故障轉(zhuǎn)移過程對應(yīng)用程序完全透明。MHA的架構(gòu)如下：

MHA failover過程：
a.檢測到 Master 異常，進(jìn)行一系列判斷，最后確定 Master 宕掉；
b.檢查配置信息，羅列出當(dāng)前架構(gòu)中各節(jié)點(diǎn)的狀態(tài)；
c.根據(jù)定義的腳本處理故障的 Master，VIP漂移或者關(guān)掉mysqld服務(wù)；
d.所有 Slave 比較位點(diǎn)，選出位點(diǎn)最新的 Slave，再與 Master 比較并獲得 binlog 的差異，copy 到管理節(jié)點(diǎn)；
e.從候選節(jié)點(diǎn)中選擇新的 Master，新的 Master 會和位點(diǎn)最新的 Slave 進(jìn)行比較并獲得 relaylog 的差異；
f.管理節(jié)點(diǎn)把 binlog 的差異 copy 到新 Master，新 Master 應(yīng)用 binlog 差異和 relaylog 差異，最后獲得位點(diǎn)信息，并接受寫請求(read_only=0)；
g.其他 Slave 與位點(diǎn)最新的 Slave 進(jìn)行比較，并獲得 relaylog 的差異，copy 到對應(yīng)的 Slave；
h.管理節(jié)點(diǎn)把 binlog 的差異 copy 到每個(gè) Slave，比較 Exec_Master_Log_Pos 和 Read_Master_Log_Pos，獲得差異日志；
i.每個(gè)Slave應(yīng)用所有差異日志，然后 reset slave 并重新指向新 Master；
j.新 Master reset slave 來清除 Slave 信息。

優(yōu)點(diǎn)：
1. 代碼開源，方便結(jié)合業(yè)務(wù)場景二次開發(fā)
2. 故障切換時(shí)，可以修復(fù)多個(gè)Slave之間的差異日志，最終使所有Slave保持?jǐn)?shù)據(jù)一致，然后從中選擇一個(gè)充當(dāng)新的Master，并將其它Slave指向它。
3. 可以靈活選擇VIP方案或者全局目錄數(shù)據(jù)庫方案(更改Master IP映射)來進(jìn)行切換。
缺點(diǎn)：
1.無法保證強(qiáng)一致，因?yàn)閺墓收螹aster上保存二進(jìn)制日志并不總是可行，比如Master磁盤壞了，或者SSH認(rèn)證失敗等。
2.只支持一主多從架構(gòu)，要求一個(gè)復(fù)制集群中必須最少有三臺數(shù)據(jù)庫服務(wù)器，一主二從，即一臺充當(dāng)master，一臺充當(dāng)備用master，另外一臺充當(dāng)從庫。
3.采用全局目錄數(shù)據(jù)庫方案切換時(shí)，需要應(yīng)用感知變化，因此對應(yīng)用不透明，因此要保持切換對應(yīng)用透明，依然依賴于VIP。
4.不適用于大規(guī)模集群部署，配置比較復(fù)雜。
5.MHA管理節(jié)點(diǎn)本身的HA無法保證。

3.3.基于zookeeper的高可用
方案介紹：
從前面的討論可以看到，無論是keepalived方案還是MHA方案，都無法解決HA軟件自身的高可用問題，因?yàn)镠A本身是單點(diǎn)。那么如果將HA也引入多個(gè)副本呢？那么又帶來新的問題，1.HA軟件之間如何保證強(qiáng)同步。2.如何確保不會有多個(gè)HA同時(shí)進(jìn)行切換動(dòng)作。這兩個(gè)問題實(shí)質(zhì)都分布式系統(tǒng)一致性問題，為此，可以為HA軟件引入類似Paxos，Raft這樣的分布式一致性協(xié)議，保證HA軟件的可用性。zooKeeper是一個(gè)典型的發(fā)布/訂閱模式的分布式數(shù)據(jù)管理與協(xié)調(diào)框架，通過zookeeper中豐富的數(shù)據(jù)節(jié)點(diǎn)類型進(jìn)行交叉使用，配合watcher事件通知機(jī)制，可以方便地構(gòu)建一系列分布式應(yīng)用涉及的核心功能，比如：數(shù)據(jù)發(fā)布/訂閱，負(fù)載均衡，分布式協(xié)調(diào)/通知，集群管理，Master選舉，分布式鎖和分布式隊(duì)列等。zookeeper是一個(gè)很大話題，大家可以google去找更多的信息，我這里主要討論zookeeper如何解決HA自身可用性問題。架構(gòu)圖如下：

圖中每個(gè)MySQL節(jié)點(diǎn)上面部署了一個(gè)HA client，用于實(shí)時(shí)向zookeeper匯報(bào)本地節(jié)點(diǎn)的心跳狀態(tài)，比如主庫crash，通過修改zookeeper(以下簡稱zk)上的節(jié)點(diǎn)信息，來通知HA。HA節(jié)點(diǎn)在zk上注冊監(jiān)聽事件，當(dāng)zk節(jié)點(diǎn)發(fā)生變化時(shí)會自動(dòng)讓HA感知，HA節(jié)點(diǎn)可以部署一個(gè)或多個(gè)，主要用于容災(zāi)。HA節(jié)點(diǎn)之間通過zookeeper服務(wù)來實(shí)現(xiàn)數(shù)據(jù)的一致性，通過分布式鎖保證多個(gè)HA節(jié)點(diǎn)不會同時(shí)對一個(gè)主從節(jié)點(diǎn)進(jìn)行切換。HA本身是無狀態(tài)的，所有MySQL節(jié)點(diǎn)狀態(tài)信息全部保存在zookeeper服務(wù)器上，切換時(shí)，HA會對MySQL節(jié)點(diǎn)進(jìn)行復(fù)檢，然后切換。我們看看引入zookeeper后的切換流程：
a.HA client 檢測到 Master 異常，進(jìn)行一系列判斷，最后確定 Master 宕掉；
b.HA client 刪除 Master在zk上的節(jié)點(diǎn)信息；
c.由于監(jiān)聽機(jī)制，HA會感知到有節(jié)點(diǎn)被刪除；
d.HA對MySQL節(jié)點(diǎn)進(jìn)行復(fù)檢，比如建立連接，更新心跳表等
e.確認(rèn)異常后，則進(jìn)行切換。

我們再看看這種架構(gòu)下，是否能保證HA自身的高可用
(1).如果HA-client本身掛了，MySQL節(jié)點(diǎn)正常？
HA-Client管理的MySQL節(jié)點(diǎn)無法與zookeeper保持心跳，zk服務(wù)將節(jié)點(diǎn)刪除，HA會感知到這種變化，準(zhǔn)備嘗試一次切換，切換前，會進(jìn)行復(fù)檢，復(fù)檢時(shí)發(fā)現(xiàn)MySQL節(jié)點(diǎn)是OK的，則不會切換。
(2).MySQL節(jié)點(diǎn)與zookeeper的網(wǎng)絡(luò)斷了，那么表現(xiàn)如何？
由于HA-Client與節(jié)點(diǎn)在同一臺主機(jī)，因此HA-client無法再定時(shí)向zk匯報(bào)心跳，zk會將對應(yīng)的MySQL節(jié)點(diǎn)信息刪除，HA嘗試復(fù)檢，依然失敗，則進(jìn)行切換。
(3).HA掛了，表現(xiàn)如何？
由于HA無狀態(tài)，并且有多個(gè)副本，因此一個(gè)HA掛了，不會對整個(gè)系統(tǒng)造成影響。

優(yōu)點(diǎn)：
1. 保證了整個(gè)系統(tǒng)的高可用
2. 主從的強(qiáng)一致依賴于MySQL本身，比如半同步，或者外圍工具的回補(bǔ)策略，類似MHA。
3. 擴(kuò)展性非常好，可以管理大規(guī)模集群。
缺點(diǎn)：
1.引入zk，整個(gè)系統(tǒng)變得復(fù)雜。

4.基于Cluster(多點(diǎn)寫)方案
第3節(jié)討論的方案基本是目前業(yè)內(nèi)使用的主流方案，這類方案的特點(diǎn)是，單點(diǎn)寫。雖然我們可以借助中間件進(jìn)行分片(sharding)，但是對于同一份數(shù)據(jù)，依然只允許一個(gè)節(jié)點(diǎn)寫，從這個(gè)角度來說，上面的方案是偽分布式。下面討論的兩種方案算是真正分布式，同一個(gè)數(shù)據(jù)理論上可以在多個(gè)節(jié)點(diǎn)寫入，類似于Oracle的RAC，EMC的GreenPlum這種分布式數(shù)據(jù)庫。在MySQL領(lǐng)域，主要提供了2種解決方案：基于Galera的PXC和NDB Cluster。MySQL Cluster實(shí)現(xiàn)基于NDB存儲引擎，使用很多局限性，而PXC是基于innodb引擎，雖然也有局限性，但由于目前innodb使用非常廣泛，所以有一定的參考價(jià)值。目前據(jù)我所知，去哪兒公司在他們的生產(chǎn)環(huán)境中使用了PXC方案。PXC(Percona XtraDB Cluster)的架構(gòu)圖如下：

優(yōu)點(diǎn)：
1.準(zhǔn)同步復(fù)制
2.多個(gè)可同時(shí)讀寫節(jié)點(diǎn)，可實(shí)現(xiàn)寫擴(kuò)展，較分片方案更進(jìn)一步
3.自動(dòng)節(jié)點(diǎn)管理
4.數(shù)據(jù)嚴(yán)格一致
5.服務(wù)高可用
缺點(diǎn)：
1.只支持innodb引擎
2.所有表都要有主鍵
3.由于寫要同步到其它節(jié)點(diǎn)，存在寫擴(kuò)大問題
4.非常依賴于網(wǎng)絡(luò)穩(wěn)定性，不適用于遠(yuǎn)距離同步

5.基于中間件proxy的方案
準(zhǔn)確地來說，中間件與高可用沒有特別大的關(guān)系，因?yàn)榍袚Q都是在數(shù)據(jù)庫層完成，但引入中間層后，使得對應(yīng)用更透明。在引入中間件之前，所有的方案，基本都依賴于VIP漂移機(jī)制，或者不依賴于VIP又不能保證對應(yīng)用透明。通過加入中間件層，可以同時(shí)實(shí)現(xiàn)對應(yīng)用透明和高可用。此外中間層還可以做sharding，方便寫擴(kuò)展。proxy的方案很多，比如mysql自帶的mysql-proxy和fabric，阿里巴巴的cobar和tddl等。我們以fabric為例，其架構(gòu)圖如下:

應(yīng)用都請求 Fabric 連接器，然后通過使用 XML-RPC 協(xié)議訪問 Fabric 節(jié)點(diǎn)， Fabric 節(jié)點(diǎn)依賴于備用存儲 (backing store)，里面存儲整個(gè) HA 集群的元數(shù)據(jù)信息。連接器讀取 backing store 的信息，然后將元數(shù)據(jù)緩存到 cache，這樣做的好處就是減少每次建立連接時(shí)與管理節(jié)點(diǎn)交互所帶來的開銷。Fabric 節(jié)點(diǎn)可管理多個(gè) HA Group，每個(gè) HA Group 里有一個(gè) Primary 和多個(gè) Secondary(slave)，當(dāng) Primary 異常的時(shí)候會從 Secondary 中選出最合適的節(jié)點(diǎn)提升為新 Primary，其余 Secondary 都將重新指向新 Primary。這些都是自動(dòng)操作，對業(yè)務(wù)是無感知的，HA 切換之后還需要通知連接器更新的元數(shù)據(jù)信息。
優(yōu)點(diǎn)：
1.切換對應(yīng)用透明
2.可擴(kuò)展性強(qiáng)，方便分片擴(kuò)展
3.可以跨機(jī)房部署切換

缺點(diǎn)：
1.是一個(gè)比較新的組件，沒有很多實(shí)際應(yīng)用場景
2.沒有解決強(qiáng)一致問題，主備強(qiáng)一致性依賴于MySQL自身(半同步)，以及回滾回補(bǔ)機(jī)制。

總結(jié)
以上介紹了目前MySQL幾種典型的高可用架構(gòu)，包括基于共享存儲方案，基于磁盤復(fù)制方案和基于主從復(fù)制的方案。對于主從復(fù)制方案，分別介紹了keepalived，MHA以及引入zookeeper的方案。對于每種方案，都從持續(xù)可用，數(shù)據(jù)強(qiáng)一致性，以及切換對應(yīng)用的透明性進(jìn)行說明。個(gè)人覺得基于MySQL復(fù)制的方案是主流，也非常成熟，引入中間件和引入zookeeper雖然能將系統(tǒng)的可用性做地更好，可支撐的規(guī)模更大，但也對研發(fā)和運(yùn)維也提出了更高的要求。因此，在選擇方案時(shí)，要根據(jù)業(yè)務(wù)場景和運(yùn)維規(guī)模做抉擇。