高可用，英文翻譯為”High Availability”.

從字面上理解就是要做到服務的full-time的持續(xù)可用，但老實說，要做到full-time是不現(xiàn)實的，因為能夠影響系統(tǒng)服務可用性的因素實在是太多了，除了軟件BUG、硬件故障外還包括系統(tǒng)所依賴的一些第三方服務(如運營商提供的帶寬)，甚至還包括天災人禍等；因此我理解所謂的高可用意味著”更少的停服時間”，而工業(yè)界也有一套測量系統(tǒng)可用性的標準，即大家所熟知的SLA(Service Level Agrement)，也就是幾個9的可用性(如下表)：

在工業(yè)應用場景中，如當下做在線服務的各大互聯(lián)網(wǎng)公司，號稱7*24小時的不間斷服務，想想如果只是達到一個9的可用性將會是一種什么樣的災難；而要做到5個9的可用性就意味著全年只有一次服務宕機，而且得在5分鐘左右就恢復，其中的難度也是不言而喻的，我想只是采用技術手段不足以做到，還需要通過一整套完備嚴謹?shù)墓こ坦芾矸婪都芭涮坠ぞ摺?yōu)秀工程運維人員等。

云計算號稱互聯(lián)網(wǎng)公司的水和電，高可用猶如云服務商的生命線，而云數(shù)據(jù)庫作為該領域的一項重要服務更是接受著不同維度的考驗，因為云端成千上萬個用戶數(shù)據(jù)庫實例所面臨的問題會更加五花八門。

下面將先介紹MySQL領域幾個典型的高可用解決方案，分析其中的關鍵技術及適用場景，并在此基礎上介紹和分享UDB的高可用方案。

一、高可用數(shù)據(jù)庫關鍵技術點

數(shù)據(jù)庫服務和很多工業(yè)服務在高可用技術方案是相通的，為了實現(xiàn)高可用首先實現(xiàn)服務的”冗余”，即服務的集群化，如果服務有冗余備份，宕機后還有其它備份服務(熱備和冷備)可以頂上，所以實現(xiàn)數(shù)據(jù)庫服務的”冗余”也是高可用數(shù)據(jù)庫的核心準則;而有了”冗余”備份后還不夠，如果每次宕機都需要人工恢復切換至備份服務，恢復時間得不到保證，同時人為的故障恢復過程中可能會引入新的風險(人為事故)，從而降低了服務的可用性，因此必須還具備”自動故障轉移”功能。而數(shù)據(jù)庫服務相比于其它系統(tǒng)的高可用，在以上兩個關鍵技術點的實現(xiàn)上會更加的困難，因為傳統(tǒng)RDMS對數(shù)據(jù)和事務的持久性和穩(wěn)定性是要求非高的，從也提高了對冗余數(shù)據(jù)的一致性的要求和實現(xiàn)難度。

二、高可用MySQL典型解決方案

下圖是Oracle官方對MySQL幾種典型高可用方案及可用性的總結，由于時間相對較早并且隨著近幾年分布式一致性協(xié)議在工業(yè)界的實踐和發(fā)展，MySQL高可用方案又有了全新的發(fā)展方向以及相對成熟的方案，下面將一并羅列和解析。

Mysql Replication 就是通過MySQL原生的復制技術來實現(xiàn)數(shù)據(jù)的冗余，該方案也是最易實現(xiàn)和通用的方案，相關的原理介紹網(wǎng)上介紹很多，這里不再詳細贅述，實現(xiàn)原理主要是通過2PC來實現(xiàn)本地BINLOG和本地數(shù)據(jù)的一致性，并再此基礎上通過兩個線程(IO線程和SQL線程)來實現(xiàn)遠端數(shù)據(jù)和本地數(shù)據(jù)的同步，根據(jù)數(shù)據(jù)一致性程度不同復制技術又可以分為異步復制、半同步復制以及同步復制，另外在此冗余技術之上，一般會搭配使用MysqlProxy、keepalived、MHA等第三方軟件來實現(xiàn)自動容災，此技術方案如果不做一定優(yōu)化，可用性一般不到2個9。

Mysql Fabric 是Oracle官方提供的一種Mysql高可用方案，通過數(shù)據(jù)分片下的讀寫分離模式，該方案的可用性達到2個9。

DRBD磁盤復制，分布式塊設備復制(Distributed Relicated Block Deivce,DRBD)，是一種基于軟件、基于網(wǎng)絡的塊復制存儲解決方案，主要用于對服務器之間的磁盤、分區(qū)、邏輯卷等進行數(shù)據(jù)鏡像，當用戶將數(shù)據(jù)寫入本地磁盤時，還會將數(shù)據(jù)發(fā)送到網(wǎng)絡中另一臺主機的磁盤上，這樣的本地主機(主節(jié)點)與遠程主機(備節(jié)點)的數(shù)據(jù)就可以保證實時同步，當本地主機出現(xiàn)問題，遠程主機上還保留著一份相同的數(shù)據(jù)，可以繼續(xù)使用，保證了數(shù)據(jù)的安全，該方案缺點是IO性能影響嚴重，可用性不到3個9。

Solaris Clustering，該方案代表這另一種技術方向，即以共享存儲為基礎，實現(xiàn)數(shù)據(jù)庫服務器和存儲設備的解耦，這樣數(shù)據(jù)庫服務器之間的冗余與數(shù)據(jù)無關，而數(shù)據(jù)的冗余則通過SAN共享儲存或者分布式存儲系統(tǒng)來實現(xiàn)，當然Solaris Clustering除此之外還提供了操作系統(tǒng)、硬件等各個層面的監(jiān)控機制，該方案的可用性達到接近4個9，但是實現(xiàn)代價大，價格昂貴。

Mysql Cluster是官方提供的一個開源方案，其將MySQL的集群分為SQL節(jié)點和數(shù)據(jù)節(jié)點，數(shù)據(jù)節(jié)點通過一種內(nèi)存中的存儲引擎來實現(xiàn)自動sharding和復制，雖然該方案號稱接近5個9的可用性，但是缺點也是很多，如對內(nèi)存消耗大，使用成本高，犧牲了過多的SQL語言特性，配置復雜等。

基于PAXOS分布式一致性協(xié)議的方案，Paxos 協(xié)議主要多數(shù)派投票的方式，來就分布式系統(tǒng)中某個值達成一致，該算法被業(yè)界認為唯一的分布式一致性算法，包括其在內(nèi)衍生出來的分布式一致性算法(如Raft等)也在很多肯多開源分布式系統(tǒng)得到應用。Paxos與MySQL相結合可以實現(xiàn)在分布式的MySQL數(shù)據(jù)庫最終一致性從而保證高可用，而使用分布式算法用來解決MySQL數(shù)據(jù)庫數(shù)據(jù)一致性的問題的方法，也越來越被人們所接受，一系列產(chǎn)品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被應用到生產(chǎn)環(huán)境，而最近Oracle官方所推出的MySQL Group Replication的GA，更使其在Mysql高可用領域成為了一種民用技術;因此使用分布式協(xié)議和多副本來解決數(shù)據(jù)庫一致性問題已經(jīng)成為了主流的方向。但是此類方案還出于初級階段，不夠成熟，同時分布式一致性協(xié)議由于網(wǎng)絡開銷的原因在性能上還有待提高和優(yōu)化。

三、 高可用數(shù)據(jù)庫案例分享--UDB

為了實現(xiàn)云數(shù)據(jù)庫服務的高可用，UDB基于半同步復制技術采用雙主的熱備架構，為了實現(xiàn)故障自動轉移，并在此基礎上實現(xiàn)了Proxy模塊，該模塊不僅負責數(shù)據(jù)業(yè)務的轉發(fā)，同時還監(jiān)控后端DB的健康狀況，雙主數(shù)據(jù)一致性檢測，并在后端DB宕機情況下，在不影響數(shù)據(jù)一致性的情況下，完成數(shù)據(jù)業(yè)務切換，整個架構及容災過程如下圖：

也許從架構上看很簡單，一主一備的架構沒有什么新意，但是深入到細節(jié)中會發(fā)現(xiàn)有很多問題和難點,或者說這些問題都圍繞這一個目標，如何保證數(shù)據(jù)一致性。

普通的異步復制對數(shù)據(jù)庫性能影響小，但是主從數(shù)據(jù)一致性難以保證；強同步復制雖然保證了主從強一致，但是可用性很差;因此udb選擇了折中的方案即半同步復制，但只是簡單的使用半同步復制還是不夠，通過分析半同步復制的過程和原理，會發(fā)現(xiàn)半同步復制會存在以下一些缺陷，下面將分析缺陷的同時介紹下udb的解決方案和策略：

1. 臨界事務問題?

什么是臨界事務，臨界事務就是在宕機那個時間點主庫正在提交的事務，這個事務可能已經(jīng)提交，可能已經(jīng)fsync到磁盤，但是確沒有同步到從庫中去，半同步復制對于臨界事務是沒法保證的，如下圖是myql5.7無損復制一次事務commit流程(udb基于次復制技術做了優(yōu)化)：

如上圖，我們對5.7版本中的無損復制模式(默認模式下)的半同步復制的主機commit做了細分，拆成7個可能crash的階段，考慮到雙機切換后可能會導致的數(shù)據(jù)丟失和數(shù)據(jù)一致性異常，我們對每個階段有如下分析：

• 在階段1,2,3發(fā)生了crash，由于主庫重啟后事務會回滾，binlog未發(fā)送到從庫，所以不會發(fā)生異常。

• 在階段4發(fā)生異常，由于主庫進入了commit階段，但是binlog尚未發(fā)送到從庫。在主庫重啟后仍然會將這個事務發(fā)送到從機。

• 在階段5,6,7發(fā)生異常，由于從庫已經(jīng)收到了binlog，只要主庫重啟后即可達到主庫和備庫數(shù)據(jù)一致的效果。

通過以上分析，無損復制模式下只有在階段4發(fā)生宕機會導致恢復后雙主數(shù)據(jù)不一致，因為當在此階段發(fā)生宕機，該事務并沒有發(fā)送至從庫，但是主庫已提交至Binlog和Redolog，如果此時業(yè)務切至從庫，主庫恢復后會繼續(xù)將事務commit并同步到從庫，但是由于從庫上已經(jīng)有了新事務，很可能會和此事務產(chǎn)生沖突(如主鍵沖突)，從而導致雙主數(shù)據(jù)不一致；為了解決此宕機時臨界事務問題，我們通過內(nèi)核層面在主庫重啟recovery階段作了如下調(diào)整：有選擇性的commit并復制到從庫部分事務，回滾掉沒有同步到原從庫的事務及Truncate掉binlog中相應的event，整個過程如下圖：

如上圖所示，主庫在恢復后，會向從庫或者proxy詢問從本庫同步過去的***一條事務的Binlog位置，并以此為基礎回滾掉該Binlog位置之后的臨界事務。

2. 半同步退化問題?

由于網(wǎng)絡抖動以及從庫硬件故障等問題會導致半同步退化為異步，如果在此情況下主庫發(fā)生宕機并發(fā)生切換，會導致數(shù)據(jù)丟失，對于很多數(shù)據(jù)敏感的業(yè)務(如金融)后果是非常嚴重的;因此當半同步復制退化，整個集群是不可以容災切換業(yè)務的;但是如果主機宕機無法ssh登陸，我們又如何確定主從是否退化，從庫數(shù)據(jù)是否和主庫一致呢。

為了解決此問題，防止錯誤的切換導致數(shù)據(jù)丟失，UDB通過在proxy和mysql之間以及主從之間增加鏈接通道，proxy和myql會用專門的線程通過此鏈接通道同步事務信息，如果主庫發(fā)生宕機，從庫可以在本地緩存和遠端proxy獲取同步事務信息，并使用該事務信息作為從機是否可以切換的依據(jù)，如下圖：

同時為了提高可用性，應對短時間網(wǎng)絡抖動后造成雙主長時間數(shù)據(jù)不一致，udb在網(wǎng)絡恢復后，會額外啟動一個復制鏈路來追補落后的數(shù)據(jù)，而原半同步復制鏈路繼續(xù)用于復制實時事務，這樣不僅可以加快復制數(shù)據(jù)效率，而且避免了由于從庫負載過高永遠恢復半同步的風險。

3. 如何保證proxy的高可用

通過以上問題及UDB相應解決方案的分析，大家可以看出Proxy在整個架構中扮演著極其重要的角色，不僅負責數(shù)據(jù)轉發(fā)，同時為數(shù)據(jù)一致性和可用性提高保障；因此大家一定會問如果Proxy宕機怎么辦，為了解決Proxy高可用問題，UDB這邊對Proxy模塊也采用了一主一備模式，如下圖：

當圖中左路主Proxy宕機后，ProxyMaster模塊會觸發(fā)容災處理過程，此時ProxyMaster會將虛擬IP重新綁定至Proxy(backup)并自動啟動，啟動后Proxy(backup)會重新鏈路至原MasterDB，以保證業(yè)務不間斷，而ProxyMaster模塊通過ZK服務分布在多個服務器上，有效的保證了Proxy的可用性。

當然除了該雙主技術架構外，為了保障服務的高可用，UDB在運維監(jiān)控等層面也做了很多工作，通過對從硬件、操作系統(tǒng)、數(shù)據(jù)庫以及網(wǎng)絡等各個層面的不間斷監(jiān)控，從而***程度的及時捕獲和恢復數(shù)據(jù)庫服務;同時UDB通過自研的大型數(shù)據(jù)庫備份系統(tǒng)，能夠應對各種級別的宕機故障后的數(shù)據(jù)恢復，從而保障了用戶數(shù)據(jù)的安全可靠性。

【本文是51CTO專欄機構作者“大U的技術課堂”的原創(chuàng)文章，轉載請通過微信公眾號(ucloud2012)聯(lián)系作者】

 戳這里，看該作者更多好文