高可用架構對於互聯網服務基本是標配，無論是應用服務還是數據庫服務都需要做到高可用。雖然互聯網服務號稱7*24小時不間斷服務，但多多少少有一些時候服務不可用，比如某些時候網頁打不開，百度不能搜索或者無法發微博，發微信等。一般而言，衡量高可用做到什麼程度可以通過一年內服務不可用時間作為參考，要做到3個9的可用性，一年內只能累計有8個小時不可服務，而如果要做到5個9的可用性，則一年內只能累計5分鐘服務中斷。所以雖說每個公司都說自己的服務是7*24不間斷的，但實際上能做到5個9的屈指可數，甚至根本做不到，國內互聯網巨頭BAT(百度，阿裡巴巴，騰訊)都有因為故障導致的停服問題。對於一個系統而言，可能包含很多模塊，比如前端應用，緩存，數據庫，搜索，消息隊列等，每個模塊都需要做到高可用，才能保證整個系統的高可用。對於數據庫服務而言，高可用可能更復雜，對用戶的服務可用，不僅僅是能訪問，還需要有正確性保證，因此討論數據庫的高可用方案時，一般會同時考慮方案中數據一致性問題。今天這篇文章主要討論MySQL數據庫的高可用方案，介紹每種方案的特性以及優缺點，本文是對各種方案的總結，希望拋磚引玉，和大家一起討論。
1.基於共享存儲的方案SAN
方案介紹：SAN(Storage Area Network)簡單點說就是可以實現網絡中不同服務器的數據共享，共享存儲能夠為數據庫服務器和存儲解耦。使用共享存儲時，服務器能夠正常掛載文件系統並操作，如果服務器掛了，備用服務器可以掛載相同的文件系統，執行需要的恢復操作，然後啟動MySQL。共享存儲的架構如下:
優點:
1.可以避免存儲外的其它組件引起的數據丟失。
2.部署簡單，切換邏輯簡單，對應用透明。
3.保證主備數據的強一致。
限制或缺點:
1.共享存儲是單點，若共享存儲掛了，則會丟失數據。
2.價格比價昂貴。
2.基於磁盤復制的方案 DRBD
方案介紹：DRBD(Distributed Replicated Block Device)是一種磁盤復制技術，可以獲得和SAN類似的效果。DBRD是一個以linux內核模塊方式實現的塊級別同步復制技術。它通過網卡將主服務器的每個塊復制到另外一個服務器塊設備上，並在主設備提交塊之前記錄下來。DRBD與SAN類似，也是有一個熱備機器，開始提供服務時會使用和故障機器相同的數據，只不過DRBD的數據是復制存儲，不是共享存儲。DRBD的架構圖如下：
優點：
1.切換對應用透明
2.保證主備數據的強一致。
限制或缺點：
1.影響寫入性能，由於每次寫磁盤，實質都需要同步到網絡服務器。
2.一般配置兩節點同步，可擴展性比較差
3.備庫不能提供讀服務，資源浪費
3.基於主從復制(單點寫)方案
前面討論的兩種方案分別依賴於底層的共享存儲和磁盤復制技術，來解決MYSQL服務器單點和磁盤單點的問題。而實際生產環境中，高可用更多的是依賴MySQL本身的復制，通過復制為Master制作一個或多個熱副本，在Master故障時，將服務切換到熱副本。下面的幾種方案都是基於主從復制的方案，方案由簡單到復雜，功能也越來越強大，實施難度由易到難，各位可以根據實際情況選擇合適的方案。
3.1.keepalived/heartbeat
方案介紹：
keepalived是一個HA軟件，它的作用是檢測服務器(web服務器，DB服務器等)狀態，檢查原理是模擬網絡請求檢測，檢測方式包括HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK等。對於DB服務器而言，主要就是IP,端口(TCP_CHECK)，但這可能不夠(比如DB服務器ReadOnly)，因此keepalived也支持自定義腳本。keepalived通過監聽來確認服務器的狀態，如果發現服務器故障，則將故障服務器從系統中剔除。keepalived的高可用架構如下圖，分別在主、從服務器上安裝keepalived的軟件，並配置同樣的VIP，VIP層將真實IP屏蔽，應用服務器通過訪問VIP來獲取DB服務。當Master故障時，keepalived感知，並將Slave提升主，繼續提供服務對應用層透明。
優點：
1. 安裝配置簡單
2. Master故障時，Slave快速切換提供服務，並且對應用透明。
限制或缺點：
1.需要主備的IP在同一個網段。
2.提供的檢測機制比較弱，需要自定義腳本來確定Master是否能提供服務，比如更新心跳表等。
3.無法保證數據的一致性，原生的MySQL采用異步復制，若Master故障，Slave數據可能不是最新，導致數據丟失，因此切換時要考慮Slave延遲的因素，確定切換策略。對於強一致需求的場景，可以開啟(semi-sync)半同步，來減少數據丟失。
4.keepalived軟件自身的HA無法保證。
3.2.MHA
方案介紹：MHA(Master High Availability)是一位日本MySQL大牛用Perl寫的一套MySQL故障切換方案，來保證數據庫的高可用，MHA通過從宕機的主服務器上保存二進制日志來進行回補，能在最大程度上減少數據丟失。MHA由兩部分組成：MHA Manager（管理節點）和MHA Node（數據節點）。MHA可以單獨部署在一台獨立的機器上管理多個master-slave集群，MHA Node運行在每台MySQL服務器上，主要作用是切換時處理二進制日志，確保切換盡量少丟數據。MHA Manager會定時探測集群中的master節點，當master出現故障時，它可以自動將最新數據的slave提升為新的master，然後將所有其他的slave重新指向新的master，整個故障轉移過程對應用程序完全透明。MHA的架構如下：
MHA failover過程：
a.檢測到 Master 異常，進行一系列判斷，最後確定 Master 宕掉；
b.檢查配置信息，羅列出當前架構中各節點的狀態；
c.根據定義的腳本處理故障的 Master，VIP漂移或者關掉mysqld服務；
d.所有 Slave 比較位點，選出位點最新的 Slave，再與 Master 比較並獲得 binlog 的差異，copy 到管理節點；
e.從候選節點中選擇新的 Master，新的 Master 會和位點最新的 Slave 進行比較並獲得 relaylog 的差異；
f.管理節點把 binlog 的差異 copy 到新 Master，新 Master 應用 binlog 差異和 relaylog 差異，最後獲得位點信息，並接受寫請求(read_only=0)；
g.其他 Slave 與位點最新的 Slave 進行比較，並獲得 relaylog 的差異，copy 到對應的 Slave；
h.管理節點把 binlog 的差異 copy 到每個 Slave，比較 Exec_Master_Log_Pos 和 Read_Master_Log_Pos，獲得差異日志；
i.每個Slave應用所有差異日志，然後 reset slave 並重新指向新 Master；
j.新 Master reset slave 來清除 Slave 信息。
優點：
1. 代碼開源，方便結合業務場景二次開發
2. 故障切換時，可以修復多個Slave之間的差異日志，最終使所有Slave保持數據一致，然後從中選擇一個充當新的Master，並將其它Slave指向它。
3. 可以靈活選擇VIP方案或者全局目錄數據庫方案(更改Master IP映射)來進行切換。
缺點：
1.無法保證強一致，因為從故障Master上保存二進制日志並不總是可行，比如Master磁盤壞了，或者SSH認證失敗等。
2.只支持一主多從架構，要求一個復制集群中必須最少有三台數據庫服務器，一主二從，即一台充當master，一台充當備用master，另外一台充當從庫。
3.采用全局目錄數據庫方案切換時，需要應用感知變化，因此對應用不透明，因此要保持切換對應用透明，依然依賴於VIP。
4.不適用於大規模集群部署，配置比較復雜。
5.MHA管理節點本身的HA無法保證。
3.3.基於zookeeper的高可用
方案介紹：
從前面的討論可以看到，無論是keepalived方案還是MHA方案，都無法解決HA軟件自身的高可用問題，因為HA本身是單點。那麼如果將HA也引入多個副本呢？那麼又帶來新的問題，1.HA軟件之間如何保證強同步。2.如何確保不會有多個HA同時進行切換動作。這兩個問題實質都分布式系統一致性問題，為此，可以為HA軟件引入類似Paxos，Raft這樣的分布式一致性協議，保證HA軟件的可用性。zooKeeper是一個典型的發布/訂閱模式的分布式數據管理與協調框架，通過zookeeper中豐富的數據節點類型進行交叉使用，配合watcher事件通知機制，可以方便地構建一系列分布式應用涉及的核心功能，比如：數據發布/訂閱，負載均衡，分布式協調/通知，集群管理，Master選舉，分布式鎖和分布式隊列等。zookeeper是一個很大話題，大家可以google去找更多的信息，我這裡主要討論zookeeper如何解決HA自身可用性問題。架構圖如下：
圖中每個MySQL節點上面部署了一個HA client，用於實時向zookeeper匯報本地節點的心跳狀態，比如主庫crash，通過修改zookeeper(以下簡稱zk)上的節點信息，來通知HA。HA節點在zk上注冊監聽事件，當zk節點發生變化時會自動讓HA感知，HA節點可以部署一個或多個，主要用於容災。HA節點之間通過zookeeper服務來實現數據的一致性，通過分布式鎖保證多個HA節點不會同時對一個主從節點進行切換。HA本身是無狀態的，所有MySQL節點狀態信息全部保存在zookeeper服務器上，切換時，HA會對MySQL節點進行復檢，然後切換。我們看看引入zookeeper後的切換流程：
a.HA client 檢測到 Master 異常，進行一系列判斷，最後確定 Master 宕掉；
b.HA client 刪除 Master在zk上的節點信息；
c.由於監聽機制，HA會感知到有節點被刪除；
d.HA對MySQL節點進行復檢，比如建立連接，更新心跳表等
e.確認異常後，則進行切換。
我們再看看這種架構下，是否能保證HA自身的高可用
(1).如果HA-client本身掛了，MySQL節點正常？
HA-Client管理的MySQL節點無法與zookeeper保持心跳，zk服務將節點刪除，HA會感知到這種變化，准備嘗試一次切換，切換前，會進行復檢，復檢時發現MySQL節點是OK的，則不會切換。
(2).MySQL節點與zookeeper的網絡斷了，那麼表現如何？
由於HA-Client與節點在同一台主機，因此HA-client無法再定時向zk匯報心跳，zk會將對應的MySQL節點信息刪除，HA嘗試復檢，依然失敗，則進行切換。
(3).HA掛了，表現如何？
由於HA無狀態，並且有多個副本，因此一個HA掛了，不會對整個系統造成影響。
優點：
1. 保證了整個系統的高可用
2. 主從的強一致依賴於MySQL本身，比如半同步，或者外圍工具的回補策略，類似MHA。
3. 擴展性非常好，可以管理大規模集群。
缺點：
1.引入zk，整個系統變得復雜。
4.基於Cluster(多點寫)方案
第3節討論的方案基本是目前業內使用的主流方案，這類方案的特點是，單點寫。雖然我們可以借助中間件進行分片(sharding)，但是對於同一份數據，依然只允許一個節點寫，從這個角度來說，上面的方案是偽分布式。下面討論的兩種方案算是真正分布式，同一個數據理論上可以在多個節點寫入，類似於Oracle的RAC，EMC的GreenPlum這種分布式數據庫。在MySQL領域，主要提供了2種解決方案：基於Galera的PXC和NDB Cluster。MySQL Cluster實現基於NDB存儲引擎，使用很多局限性，而PXC是基於innodb引擎，雖然也有局限性，但由於目前innodb使用非常廣泛，所以有一定的參考價值。目前據我所知，去哪兒公司在他們的生產環境中使用了PXC方案。PXC(Percona XtraDB Cluster)的架構圖如下：
優點：
1.准同步復制
2.多個可同時讀寫節點，可實現寫擴展，較分片方案更進一步
3.自動節點管理
4.數據嚴格一致
5.服務高可用
缺點：
1.只支持innodb引擎
2.所有表都要有主鍵
3.由於寫要同步到其它節點，存在寫擴大問題
4.非常依賴於網絡穩定性，不適用於遠距離同步
5.基於中間件proxy的方案
准確地來說，中間件與高可用沒有特別大的關系，因為切換都是在數據庫層完成，但引入中間層後，使得對應用更透明。在引入中間件之前，所有的方案，基本都依賴於VIP漂移機制，或者不依賴於VIP又不能保證對應用透明。通過加入中間件層，可以同時實現對應用透明和高可用。此外中間層還可以做sharding，方便寫擴展。proxy的方案很多，比如mysql自帶的mysql-proxy和fabric，阿裡巴巴的cobar和tddl等。我們以fabric為例，其架構圖如下:
應用都請求 Fabric 連接器，然後通過使用 XML-RPC 協議訪問 Fabric 節點， Fabric 節點依賴於備用存儲 (backing store)，裡面存儲整個 HA 集群的元數據信息。連接器讀取 backing store 的信息，然後將元數據緩存到 cache，這樣做的好處就是減少每次建立連接時與管理節點交互所帶來的開銷。Fabric 節點可管理多個 HA Group，每個 HA Group 裡有一個 Primary 和多個 Secondary(slave)，當 Primary 異常的時候會從 Secondary 中選出最合適的節點提升為新 Primary，其余 Secondary 都將重新指向新 Primary。這些都是自動操作，對業務是無感知的，HA 切換之後還需要通知連接器更新的元數據信息。
優點：
1.切換對應用透明
2.可擴展性強，方便分片擴展
3.可以跨機房部署切換
缺點：
1.是一個比較新的組件，沒有很多實際應用場景
2.沒有解決強一致問題，主備強一致性依賴於MySQL自身(半同步)，以及回滾回補機制。
總結
以上介紹了目前MySQL幾種典型的高可用架構，包括基於共享存儲方案，基於磁盤復制方案和基於主從復制的方案。對於主從復制方案，分別介紹了keepalived，MHA以及引入zookeeper的方案。對於每種方案，都從持續可用，數據強一致性，以及切換對應用的透明性進行說明。個人覺得基於MySQL復制的方案是主流，也非常成熟，引入中間件和引入zookeeper雖然能將系統的可用性做地更好，可支撐的規模更大，但也對研發和運維也提出了更高的要求。因此，在選擇方案時，要根據業務場景和運維規模做抉擇。
