近幾年，隨著移動互聯(lián)網(wǎng)的發(fā)展、云計算的普及和各種新業(yè)務(wù)的出現(xiàn)，數(shù)據(jù)呈現(xiàn)爆發(fā)式增長，給整個業(yè)務(wù)系統(tǒng)帶來了越來越大的挑戰(zhàn)，特別是對于底層數(shù)據(jù)存儲系統(tǒng)。完美的高可用系統(tǒng)，是所有公司最理想的追求。如果只從應(yīng)用層和緩存層看高可用問題，是比較容易解決的。對于應(yīng)用層來說，根據(jù)業(yè)務(wù)特點可以很方便地設(shè)計成無狀態(tài)的服務(wù)，在大多數(shù)互聯(lián)網(wǎng)公司中，在業(yè)務(wù)層的最上層使用動態(tài)DNS、LVS、HAProxy等負載均衡組件，配合Docker和Kubernetes實現(xiàn)彈性伸縮，能夠很容易實現(xiàn)應(yīng)用服務(wù)的高可用。對于緩存層來說，也有很多可選的開源方案來幫助解決，比如Codis、Twemproxy、Redis Cluster等等，如果對緩存數(shù)據(jù)的一致性和實時性要求不高，這些方案就可以很好解決緩存層面的問題。但對存儲層來說，支持高可用非常困難。

　　在互聯(lián)網(wǎng)架構(gòu)中，最底層的核心數(shù)據(jù)存儲一般都會選擇關(guān)系型數(shù)據(jù)庫，最流行的當(dāng)屬MySQL。大數(shù)據(jù)時代，大家漸漸發(fā)現(xiàn)傳統(tǒng)的關(guān)系型數(shù)據(jù)庫開始出現(xiàn)一些瓶頸：單機容量不能支撐快速增長的業(yè)務(wù)需求；高并發(fā)的頻繁訪問經(jīng)常造成服務(wù)的響應(yīng)超時；主從數(shù)據(jù)同步帶來的數(shù)據(jù)不一致問題；大數(shù)據(jù)場景下查詢性能大幅波動等等。

　　當(dāng)前，數(shù)據(jù)庫方案有了很多不一樣的變化。首先，不同于早期的單機型數(shù)據(jù)庫，在當(dāng)下數(shù)據(jù)呈現(xiàn)爆發(fā)式增長，數(shù)據(jù)總量也從GB級別跨越到了TB甚至PB級別，遠超單機數(shù)據(jù)庫的存儲上限，所以只能選擇分布式的數(shù)據(jù)存儲方案。其次，隨著存儲節(jié)點的增加，存儲節(jié)點出問題的可能性也大大提高，光靠人工完全不現(xiàn)實，所以需要數(shù)據(jù)庫層面保證自己高效快速地實現(xiàn)故障遷移。另外，隨著存儲節(jié)點的增加，運維成本也大大增加，對自動化工具也提出了更高要求。最后，新分布式數(shù)據(jù)庫的出現(xiàn)，用戶在OLTP數(shù)據(jù)庫基本需求的基礎(chǔ)上，對大數(shù)據(jù)分析查詢的業(yè)務(wù)要求更高，在某種程度上OLTP和OLAP融合的新型數(shù)據(jù)庫會是未來極具潛力的發(fā)展方向之一。

　　什么是高可用

　　Wikipedia的解釋中，高可用即High Availability，一般通過SLA（Service Level Agrement）來衡量。這里從CAP角度來看待高可用問題。CAP是分布式系統(tǒng)領(lǐng)域一個非常著名的理論，由Berkerly的Brewer提出。該理論認為任何基于網(wǎng)絡(luò)的分布式系統(tǒng)都具有以下三要素：

　　數(shù)據(jù)一致性（Consistence）：等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本；

　　可用性（Availability）：對數(shù)據(jù)更新具備高可用性；

　　分區(qū)容忍性（Partition tolerance）：以實際效果而言，分區(qū)相當(dāng)于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A間做出選擇。

　　三要素不能同時滿足。但后來很多人將CAP解讀為數(shù)據(jù)一致性、可用性和分區(qū)容忍性最多只能滿足兩個，這種解讀本身存在一定的誤導(dǎo)性，原因就在于忽略了特定條件。假想兩個節(jié)點N1和N2，在某些場景下發(fā)生了分區(qū)（P）問題，即N1和N2分處分區(qū)的兩側(cè)。這時對于外部的寫操作來說，如果允許任一節(jié)點可寫的話就相當(dāng)于選擇了A，喪失了C。同樣，如果為了滿足C，那么寫入操作就會失敗，A就無法保證，所以存在分區(qū)問題時，無法同時保證A和C。雖然分區(qū)在局域網(wǎng)中出現(xiàn)的概率相對很低，但卻無法避免，所以系統(tǒng)只能在CP和AP之間做出權(quán)衡。

　　當(dāng)前有很多的NoSQL數(shù)據(jù)庫，在CAP之間選擇了AP，比如Amazon Dynamo和Cassandra，追求可用性，適當(dāng)犧牲一致性，只實現(xiàn)最終一致性。這種選擇允許短時間的數(shù)據(jù)不一致，并且可以交由用戶自己來處理寫入沖突，但是可以隨時接受用戶的讀寫請求。在這種場景下就需要特別注意數(shù)據(jù)不一致引起的各種奇怪問題，對于比較嚴(yán)肅的業(yè)務(wù)場景，比如訂單、支付等，對事務(wù)和一致性要求比較高，這種AP類型的系統(tǒng)就不適用了。而且該系統(tǒng)放棄了SQL和ACID事務(wù)，給開發(fā)人員帶來了更多的開發(fā)工作和額外的心智負擔(dān)，很容易出現(xiàn)問題，所以NoSQL數(shù)據(jù)庫犧牲一致性來獲取服務(wù)的可用性，并沒有徹底解決大數(shù)據(jù)時代數(shù)據(jù)庫的高可用問題。

　　大數(shù)據(jù)時代，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫必然會由單機擴展到分布式，追求數(shù)據(jù)一致性，所以必然會是一個CP類型的系統(tǒng)，像這種新型的、下一代的分布式關(guān)系型數(shù)據(jù)庫，既具有傳統(tǒng)單機數(shù)據(jù)庫的SQL支持和ACID事務(wù)保證，又有NoSQL數(shù)據(jù)庫的Scale特點，稱為NewSQL數(shù)據(jù)庫，包括Google的Spanner/F1、PingCAP的TiDB等等。但從CAP的角度看，選擇CP并不意味著完全放棄了A，CP系統(tǒng)只是在某些產(chǎn)生分區(qū)的場景下不能實現(xiàn)100%的A，但完全可以通過有效的辦法來實現(xiàn)高可用（HA）。由此可見，并不是CP系統(tǒng)就完全放棄了A，只不過在產(chǎn)生分區(qū)的場景下無法從理論上保證A，這是一個常見的誤解。

　　澄清了CAP的問題，下面討論如何打造高可用的數(shù)據(jù)庫。數(shù)據(jù)庫是一個非常大的概念，從傳統(tǒng)單機SQL，到NoSQL，再到現(xiàn)在流行的NewSQL，這里面不同的實現(xiàn)方案實在太多，本文聚焦在關(guān)系型數(shù)據(jù)庫，主要探討最流行的MySQL數(shù)據(jù)庫及其生態(tài)。最近幾年，隨著大家在分布式數(shù)據(jù)庫領(lǐng)域的探索，出現(xiàn)了很多不同類型的解決方案，比如中間件/Proxy的方案，典型的比如TDDL、Cobar、Altlas、DRDS、TDSQL、MyCAT、KingShard、Vitess、PhxSQL等，還有一種新型的NewSQL數(shù)據(jù)庫，比如Google Spanner/F1、Oceanbase、TiDB等。下面看下業(yè)界在打造高可用數(shù)據(jù)庫方面新的技術(shù)進展，以及和傳統(tǒng)方案選型的對比。

　　消除單點問題

　　為了實現(xiàn)數(shù)據(jù)庫層面的高可用，必須要消除單點問題（SPOF）。存在單點服務(wù)的情況下，一旦單點服務(wù)掛掉，整個服務(wù)就不可用。消除單點問題最常用的方案就是復(fù)制（Replication），通過數(shù)據(jù)冗余的方式來實現(xiàn)高可用。

　　為什么必須要冗余？數(shù)據(jù)庫本身是有狀態(tài)的，不會像無狀態(tài)的服務(wù)那樣掛掉就可以重啟，而數(shù)據(jù)庫本身能夠保證數(shù)據(jù)持久化，所以如果沒有冗余副本，一旦數(shù)據(jù)庫掛掉，只能等待數(shù)據(jù)庫重啟，在這段恢復(fù)時間服務(wù)完全不可用，高可用就無法保證。但如果有了額外的數(shù)據(jù)副本，高可用就變得可能了，主要能保證在檢測到服務(wù)發(fā)生問題之后及時做服務(wù)切換。

　　對于MySQL來說，默認復(fù)制方式是異步的主從復(fù)制方式，雖然這種方案被很多的互聯(lián)網(wǎng)公司所采用，但實際上這種方案存在一個致命問題——存在丟失數(shù)據(jù)的風(fēng)險。數(shù)據(jù)傳輸經(jīng)過網(wǎng)絡(luò)，這也就意味著存在傳輸時延，那么對于異步復(fù)制來說，主從數(shù)據(jù)庫的數(shù)據(jù)本身是最終一致性的，所以主庫一旦出現(xiàn)了問題，切換從庫極有可能會帶來數(shù)據(jù)不一致的風(fēng)險。

　　因為異步復(fù)制方式存在更大的問題，很多時候大家都會考慮用半同步復(fù)制方式Semi-Sync，這種數(shù)據(jù)復(fù)制方式在默認情況下會使用同步的數(shù)據(jù)復(fù)制方式，不過在數(shù)據(jù)復(fù)制壓力較大的情況下，就會退化成異步的數(shù)據(jù)復(fù)制方式，所以依然會存在高可用問題。當(dāng)然，也有人會選用完全同步的方式，但是這種復(fù)制方式在并發(fā)壓力下會有明顯的性能問題，所以也不常用。

　　那有沒有一種數(shù)據(jù)復(fù)制方式，能同時保證數(shù)據(jù)的可靠性和性能？答案是有的，那就是最近業(yè)界討論較多的分布式一致性算法，典型的是Paxos和Raft。簡單來說，它們是高度自動化、強一致的復(fù)制算法。以Raft為例，Raft中基數(shù)個節(jié)點組成一個Raft Group，在一個Raft Group內(nèi)，只要滿足大多數(shù)節(jié)點寫成功，就認為可以寫成功了，比如一個3節(jié)點的Raft Group，只要保證Raft Leader和任意一個Raft Follower寫成功就可以了，所以同步寫Leader，異步寫兩個Follower，只要其中一個返回就可以，相比完全的同步方式，性能要好很多。所以從復(fù)制層面來看，Raft更像是一個自適應(yīng)的同步+異步復(fù)制方案，同步和異步的最優(yōu)選擇通過Raft算法來保證。

相關(guān)電子資料下載

• 常用于緩存處理的機制總結(jié) 如何避免緩存雪崩問題？ 24
• 觸發(fā)器的基本原理、應(yīng)用場景及優(yōu)缺點 83
• AI大模型對數(shù)據(jù)存儲技術(shù)的發(fā)展趨勢 64
• 訪問控制中PIP的典型流程和關(guān)鍵點思考 60
• 物證管理系統(tǒng)|智物證DW-S404是一套成熟系統(tǒng) 44
• Python 梯度計算模塊如何實現(xiàn)一個邏輯回歸模型 93
• TinyDB ：一個純Python編寫的輕量級數(shù)據(jù)庫 58
• mysql經(jīng)典面試題及答案 63
• 人大金倉獲評“2023年度軟件和信息技術(shù)服務(wù)名牌企業(yè)” 100
• 人大金倉亮相第40屆CCF中國數(shù)據(jù)庫學(xué)術(shù)會議（NDBC 2023） 119