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

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

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

　　什么是高可用

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

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

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

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

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

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

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

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

　　消除單點(diǎn)問(wèn)題

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

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

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

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

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

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

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