圖解?MySQL?面試題?——?容災(zāi)篇
時間：2021-12-07 15:51:58
手機(jī)看文章
掃描二維碼
隨時隨地手機(jī)看文章
[導(dǎo)讀]不多說，直接發(fā)車！今天我們要講的就是MySQL的容災(zāi)。容災(zāi)一直是后臺開發(fā)中的重點(diǎn)，如果是線上服務(wù)出了問題，沒有合適的容災(zāi)機(jī)制，那么對業(yè)務(wù)來說一定會是個沉重的打擊，但是容災(zāi)同時也是拉開能力差距的難點(diǎn)，需要有強(qiáng)勁的實(shí)力才能把握住。不知道阿柴能不能經(jīng)受住這樣的考驗(yàn)。現(xiàn)在，就讓我們繼續(xù)開...
不多說，直接發(fā)車！
今天我們要講的就是MySQL的容災(zāi)。
容災(zāi)一直是后臺開發(fā)中的重點(diǎn)，如果是線上服務(wù)出了問題，沒有合適的容災(zāi)機(jī)制，那么對業(yè)務(wù)來說一定會是個沉重的打擊，但是容災(zāi)同時也是拉開能力差距的難點(diǎn)，需要有強(qiáng)勁的實(shí)力才能把握住。
不知道阿柴能不能經(jīng)受住這樣的考驗(yàn)。
現(xiàn)在，就讓我們繼續(xù)開啟這場沉浸式面試吧。
容災(zāi)熱身
容災(zāi)有幾種方式？從冷熱來說，分為冷備和熱備。從距離來說，分為同城和異地。
一般而言，大的維度劃分就是兩者的正交：同城冷備，異地冷備，同城熱備，異地?zé)醾洹?/span>
MySQL如果掛了怎么辦呢？MySQL可以主從模式部署，如果主掛了，可以將從升級為主。當(dāng)然，為了節(jié)約資源，如果業(yè)務(wù)允許，在平時運(yùn)行正常的時候，也可以將部分讀請求分流到從節(jié)點(diǎn)。
那主從模式按部署方式又分為哪幾種？常見的主從模式有幾種，具體的模式也得看實(shí)際的業(yè)務(wù)需要。根據(jù)實(shí)際的情況，選擇合適的一種架構(gòu)模式。
1.一主一從模式：一個大佬帶一個小弟，大佬掛了小弟上位。
2.一主多從模式：一個大佬帶一群小弟，只要不全掛，就還能翻盤。
3.級聯(lián)主從模式：一個大佬培養(yǎng)了一個親信骨干，其它小弟都由親信骨干培養(yǎng)。
嗯，比喻得不錯，那主節(jié)點(diǎn)和從節(jié)點(diǎn)怎么保證一致呢？兩種方式，一種是雙寫兩個db，還有就是主從復(fù)制。前者需要耗費(fèi)大量成本去保證雙寫的最終一致性。所以更常見的是主從復(fù)制。
那主從復(fù)制，Master做了哪些工作？當(dāng)主節(jié)點(diǎn)上進(jìn)行寫操作時，會按照時間先后順序?qū)懭氲絙inlog中。主從復(fù)制就是基于binlog進(jìn)行的，具體流程有兩部分。
首先，當(dāng)從節(jié)點(diǎn)連接到主節(jié)點(diǎn)時，主節(jié)點(diǎn)會創(chuàng)建一個叫做dump的線程，有多少個從節(jié)點(diǎn)，就會創(chuàng)建多少個dump線程；
然后，當(dāng)主節(jié)點(diǎn)的binlog發(fā)生變化的時候，dump線程就會通知從節(jié)點(diǎn)，并將相應(yīng)的binlog內(nèi)容發(fā)送給從節(jié)點(diǎn)。
主從復(fù)制，Slave又做了哪些工作呢？當(dāng)開啟主從同步的時候，從節(jié)點(diǎn)會創(chuàng)建兩個線程用來完成數(shù)據(jù)同步工作：
I/O線程連接到主節(jié)點(diǎn)，主節(jié)點(diǎn)上的dump線程會將binlog的內(nèi)容發(fā)送給I/O線程。它接收到內(nèi)容后，再將其寫入到本地的relay log。
SQL線程讀取I/O線程寫入的relay log，并且根據(jù)relay log的內(nèi)容對從數(shù)據(jù)庫做對應(yīng)的操作。
數(shù)據(jù)復(fù)制
主從復(fù)制有幾種模式？主要有三種模式：異步模式、半同步模式、全同步模式。
異步模式：這種模式下，主節(jié)點(diǎn)不關(guān)心dump線程同步情況，直接返回成功給客戶。
半同步模式下，主節(jié)點(diǎn)只需要接收到其中一臺從節(jié)點(diǎn)的返回信息，就會給用戶返回成功，否則需要等待直到超時回滾。
這樣做性能比異步模式會差一些，但可靠性會高一些，保證了binlog至少傳輸?shù)搅艘粋€從節(jié)點(diǎn)上，不過沒有保證從節(jié)點(diǎn)立刻將此事務(wù)更新到存儲中。
全同步模式是指主節(jié)點(diǎn)和從節(jié)點(diǎn)全部執(zhí)行并提交了，才會向客戶端返回成功。
注意，是提交，而不只是從節(jié)點(diǎn)寫入到relay log，這樣主從是強(qiáng)一致性的，但性能損耗非常大，必須在網(wǎng)絡(luò)良好的情況下使用。
那全同步模式下，性能會不會很差，有優(yōu)化空間嗎？全同步主要性能損耗在于同步等待返回，業(yè)界有一個方案叫MAR，即異步多線程強(qiáng)同步復(fù)制，只有當(dāng)備機(jī)數(shù)據(jù)完全同步后，才由主機(jī)給予應(yīng)用事務(wù)應(yīng)答，保障數(shù)據(jù)不丟失，同時還用多線程思路保證了性能。
MAR可以說是半同步和全同步的折中，經(jīng)常被稱為強(qiáng)同步。騰訊的明星產(chǎn)品TDSQL，就是使用的MAR做同步。
詳細(xì)說一下強(qiáng)同步細(xì)節(jié)吧。Master上事務(wù)寫到binlog就算結(jié)束，將會話保存到session中。接著執(zhí)行下一輪循環(huán)去處理其它請求，這樣就避免讓線程阻塞等待應(yīng)答了。
然后負(fù)責(zé)主備同步的dump線程會將binlog立即發(fā)送給slave，slave的IO線程收到binlog并寫入到relay log之后，再給主機(jī)一個應(yīng)答。
在Master，會有一組線程來處理應(yīng)答，收到應(yīng)答之后找到對應(yīng)的會話，還可以批量執(zhí)行commit，并且給客戶端應(yīng)答。
綜合來看，MAR強(qiáng)同步復(fù)制的特點(diǎn)保證了節(jié)點(diǎn)間數(shù)據(jù)的較強(qiáng)一致性，又將串行同步操作異步化，還引入線程池能力，保證同城情況下TPS幾乎不會下降。
能了解強(qiáng)同步說明對業(yè)界先進(jìn)實(shí)踐是有了解的，妥妥加分。
MySQL一般會使用哪種模式的復(fù)制呢？根據(jù)業(yè)務(wù)需求，如果要求實(shí)時性高的話，可以搞同城容災(zāi)，同城可以選擇全同步模式。
如果要求進(jìn)一步降低風(fēng)險的話，異地容災(zāi)也得搞起來，異地通常會采取異步模式。
業(yè)界容災(zāi)方案
同城容災(zāi)和異地容災(zāi)的區(qū)別是什么？同城容災(zāi)是在相近區(qū)域建立兩個數(shù)據(jù)中心 : 一個負(fù)責(zé)日常生產(chǎn)運(yùn)行 ; 一個負(fù)責(zé)在災(zāi)難發(fā)生后的重建。同城之間的同步速度比較快，可以支持全同步模式。
異地容災(zāi)主備中心之間的距離較遠(yuǎn)， 因此一般采用異步同步，災(zāi)難情況下會有少量的數(shù)據(jù)丟失。異地災(zāi)難備份可以有效防范地震、水災(zāi)等各類風(fēng)險。
由于同城災(zāi)難備份和異地災(zāi)難備份各有所長，為達(dá)到最理想的防災(zāi)效果，數(shù)據(jù)中心應(yīng)考慮采用同城和異地各建立一個災(zāi)難備份中心。
你有了解過兩地三中心嗎？兩地三中心即同城雙中心?一個異地中心。同城雙中心由于距離近，數(shù)據(jù)可以完全同步。異地災(zāi)備中心因?yàn)榫嚯x遠(yuǎn)，會有一定程度的數(shù)據(jù)延遲。
同城雙中心具有投資成本低、建設(shè)速度快、運(yùn)維管理相對簡單、可靠性更高等優(yōu)點(diǎn)。
異地災(zāi)備中心則具有抗風(fēng)險能力強(qiáng)的作用，當(dāng)同城中心因?yàn)樽匀粸?zāi)害等原因而發(fā)生故障時，異地災(zāi)備中心可以用備份數(shù)據(jù)進(jìn)行業(yè)務(wù)恢復(fù)。
那災(zāi)難發(fā)生時MySQL該怎么切換呢？如果是同城強(qiáng)同步的節(jié)點(diǎn)，直接切換主從即可。如果是跨城市，這種主要是災(zāi)難之后的止損，災(zāi)難地的數(shù)據(jù)不一定能恢復(fù)。
平時事故時間較短，不一定要切到異地冷備。如果時間預(yù)期比較長，比如光纖斷了要等幾小時以上的，就需要考慮切到異地冷備，此時會丟失一部分?jǐn)?shù)據(jù)，等到恢復(fù)之后，再做數(shù)據(jù)遷移。
MySQL異地雙活怎么做？前面說的異地冷備其實(shí)也是異地雙活的一種。異地雙活是說兩個不同城地域，同時進(jìn)行服務(wù)，并且互相容災(zāi)。
既然能相互容災(zāi)，那么兩地?cái)?shù)據(jù)都需要是完整的，至少是最終完整，所以有個同步的過程。
如果出現(xiàn)異常，可以將流量切到另一個地域，快速恢復(fù)。
那你能說說異地雙活的適用場景嗎？異地雙活非常困難，主要涉及到跨城的網(wǎng)絡(luò)存在較大延遲。要做異地雙活，需要對業(yè)務(wù)場景進(jìn)行考慮。
如果要完全數(shù)據(jù)同步，那么兩端需要相互同步數(shù)據(jù)，一般需要數(shù)據(jù)沖突較少，并且要接受一定的查詢延時。
還有一種場景，如果增量數(shù)據(jù)不受存量影響，比如任務(wù)表，那么也可以不雙向同步數(shù)據(jù)，如果一地掛了，可以將用戶的新任務(wù)調(diào)度到異地，等恢復(fù)之后，再遷移回來，缺點(diǎn)就是損失一些記錄。
MySQL是后臺開發(fā)中非常重要的領(lǐng)域，容災(zāi)更是面試環(huán)節(jié)的高頻考點(diǎn)。
一方面是日常故障怎么做到快速恢復(fù)，另一方面，如果真的發(fā)生了大型事故 （比如2015年8月，天津爆炸導(dǎo)致騰訊機(jī)房受損），怎么把影響降低到最小，這些都是我們需要考慮的問題，若是連冷備兜底都沒有，那么這個項(xiàng)目基本可以說拜拜了。
當(dāng)然，在面試中，要是問到容災(zāi)，你能對答如流，甚至拔高，絕對是一個加分項(xiàng)！
下載文檔
