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

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

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

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

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

3.基于主從復(fù)制(單點寫)方案
前面討論的兩種方案分別依賴于底層的共享存儲和磁盤復(fù)制技術(shù)，來解決MYSQL服務(wù)器單點和磁盤單點的問題。而實際生產(chǎn)環(huán)境中，高可用更多的是依賴MySQL本身的復(fù)制，通過復(fù)制為Master制作一個或多個熱副本，在Master故障時，將服務(wù)切換到熱副本。下面的幾種方案都是基于主從復(fù)制的方案，方案由簡單到復(fù)雜，功能也越來越強大，實施難度由易到難，各位可以根據(jù)實際情況選擇合適的方案。
3.1.keepalived/heartbeat
方案介紹：
keepalived是一個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)聽來確認服務(wù)器的狀態(tài)，如果發(fā)現(xiàn)服務(wù)器故障，則將故障服務(wù)器從系統(tǒng)中剔除。keepalived的高可用架構(gòu)如下圖，分別在主、從服務(wù)器上安裝keepalived的軟件，并配置同樣的VIP，VIP層將真實IP屏蔽，應(yīng)用服務(wù)器通過訪問VIP來獲取DB服務(wù)。當Master故障時，keepalived感知，并將Slave提升主，繼續(xù)提供服務(wù)對應(yīng)用層透明。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最新評論