•  案例背景
• 案例分析
• MySQL 主從結(jié)構(gòu)
• 案例解答
• 總結(jié)

案例背景

假設(shè)你公司面臨雙 11 大促，投入了大量營(yíng)銷費(fèi)用用于平臺(tái)推廣，這帶來(lái)了巨大的流量，如果你是訂單系統(tǒng)的技術(shù)負(fù)責(zé)人，要怎么應(yīng)對(duì)突如其來(lái)的讀寫流量呢?

這是一個(gè)很典型的應(yīng)用場(chǎng)景，我想很多研發(fā)工程師會(huì)回答：通過(guò) Redis 作為 MySQL 的緩存，然后當(dāng)用戶查看“訂單中心”時(shí)，通過(guò)查詢訂單緩存，幫助 MySQL 抗住大部分的查詢請(qǐng)求。

應(yīng)用緩存的原則之一是保證緩存命中率足夠高，不然很多請(qǐng)求會(huì)穿透緩存，最終打到數(shù)據(jù)庫(kù)上。然而在“訂單中心”這樣的場(chǎng)景中，每個(gè)用戶的訂單都不同，除非全量緩存數(shù)據(jù)庫(kù)訂單信息(又會(huì)帶來(lái)架構(gòu)的復(fù)雜度)，不然緩存的命中率依舊很低。

所以在這種場(chǎng)景下，緩存只能作為數(shù)據(jù)庫(kù)的前置保護(hù)機(jī)制，但是還會(huì)有很多流量打到數(shù)據(jù)庫(kù)上，并且隨著用戶訂單不斷增多，請(qǐng)求到 MySQL 上的讀寫流量會(huì)越來(lái)越多，當(dāng)單臺(tái) MySQL 支撐不了大量的并發(fā)請(qǐng)求時(shí)，該怎么辦?

案例分析

互聯(lián)網(wǎng)大部分系統(tǒng)的訪問(wèn)流量是讀多寫少，讀寫請(qǐng)求量的差距可能達(dá)到幾個(gè)數(shù)量級(jí)，就好比你在京東上的商品的瀏覽量肯定遠(yuǎn)大于你的下單量。

所以你要考慮優(yōu)化數(shù)據(jù)庫(kù)來(lái)抗住高查詢請(qǐng)求，首先要做的就是區(qū)分讀寫流量區(qū)，這樣才方便針對(duì)讀流量做單獨(dú)擴(kuò)展，這個(gè)過(guò)程就是流量的“讀寫分離”。

讀寫分離是提升 MySQL 并發(fā)的首選方案，因?yàn)楫?dāng)單臺(tái) MySQL 無(wú)法滿足要求時(shí)，就只能用多個(gè)具有相同數(shù)據(jù)的 MySQL 實(shí)例組成的集群來(lái)承擔(dān)大量的讀寫請(qǐng)求。

MySQL 主從結(jié)構(gòu)

MySQL 做讀寫分離的前提，是把 MySQL 集群拆分成“主 + 從”結(jié)構(gòu)的數(shù)據(jù)集群，這樣才能實(shí)現(xiàn)程序上的讀寫分離，并且 MySQL 集群的主庫(kù)、從庫(kù)的數(shù)據(jù)是通過(guò)主從復(fù)制實(shí)現(xiàn)同步的。

那么面試官會(huì)問(wèn)你“MySQL 集群如何實(shí)現(xiàn)主從復(fù)制?” 換一種問(wèn)法就是“當(dāng)你提交一個(gè)事務(wù)到 MySQL 集群后，MySQL 都執(zhí)行了哪些操作?”面試官往往會(huì)以該問(wèn)題為切入點(diǎn)，挖掘你對(duì) MySQL 集群主從復(fù)制原理的理解，然后再模擬一個(gè)業(yè)務(wù)場(chǎng)景，讓你給出解決主從復(fù)制問(wèn)題的架構(gòu)設(shè)計(jì)方案。

所以，針對(duì)面試官的套路，你要做好以下的準(zhǔn)備：

• 掌握讀多寫少場(chǎng)景下的架構(gòu)設(shè)計(jì)思路，知道緩存不能解決所有問(wèn)題，“讀寫分離”是提升系統(tǒng)并發(fā)能力的重要手段。
• 深入了解數(shù)據(jù)庫(kù)的主從復(fù)制，掌握它的原理、問(wèn)題，以及解決方案。
• 從實(shí)踐出發(fā)，做到技術(shù)的認(rèn)知抽象，從方法論層面來(lái)看設(shè)計(jì)。

案例解答

MySQL 主從復(fù)制的原理無(wú)論是“MySQL 集群如何實(shí)現(xiàn)主從復(fù)制”還是“當(dāng)你提交一個(gè)事務(wù)到 MySQL 集群后，MySQL 集群都執(zhí)行了哪些操作?”面試官主要是問(wèn)你：MySQL 的主從復(fù)制的過(guò)程是怎樣的?

總的來(lái)講，MySQL 的主從復(fù)制依賴于 binlog ，也就是記錄 MySQL 上的所有變化并以二進(jìn)制形式保存在磁盤上。復(fù)制的過(guò)程就是將 binlog 中的數(shù)據(jù)從主庫(kù)傳輸?shù)綇膸?kù)上。這個(gè)過(guò)程一般是異步的，也就是主庫(kù)上執(zhí)行事務(wù)操作的線程不會(huì)等待復(fù)制 binlog 的線程同步完成。

為了方便你記憶，我把 MySQL 集群的主從復(fù)制過(guò)程梳理成 3 個(gè)階段。

• 寫入 Binlog：主庫(kù)寫 binlog 日志，提交事務(wù)，并更新本地存儲(chǔ)數(shù)據(jù)。
• 同步 Binlog：把 binlog 復(fù)制到所有從庫(kù)上，每個(gè)從庫(kù)把 binlog 寫到暫存日志中。
• 回放 Binlog：回放 binlog，并更新存儲(chǔ)數(shù)據(jù)。

但在面試中你不能簡(jiǎn)單地只講這幾個(gè)階段，要盡可能詳細(xì)地說(shuō)明主庫(kù)和從庫(kù)的數(shù)據(jù)同步過(guò)程，為的是讓面試官感受到你技術(shù)的扎實(shí)程度(詳細(xì)過(guò)程如下)。

MySQL 主庫(kù)在收到客戶端提交事務(wù)的請(qǐng)求之后，會(huì)先寫入 binlog，再提交事務(wù)，更新存儲(chǔ)引擎中的數(shù)據(jù)，事務(wù)提交完成后，返回給客戶端“操作成功”的響應(yīng)。

從庫(kù)會(huì)創(chuàng)建一個(gè)專門的 I/O 線程，連接主庫(kù)的 log dump 線程，來(lái)接收主庫(kù)的 binlog 日志，再把 binlog 信息寫入 relay log 的中繼日志里，再返回給主庫(kù)“復(fù)制成功”的響應(yīng)。

從庫(kù)會(huì)創(chuàng)建一個(gè)用于回放 binlog 的線程，去讀 relay log 中繼日志，然后回放 binlog 更新存儲(chǔ)引擎中的數(shù)據(jù)，最終實(shí)現(xiàn)主從的數(shù)據(jù)一致性。

在完成主從復(fù)制之后，你就可以在寫數(shù)據(jù)時(shí)只寫主庫(kù)，在讀數(shù)據(jù)時(shí)只讀從庫(kù)，這樣即使寫請(qǐng)求會(huì)鎖表或者鎖記錄，也不會(huì)影響讀請(qǐng)求的執(zhí)行。

同時(shí)，在讀流量比較大時(shí)，你可以部署多個(gè)從庫(kù)共同承擔(dān)讀流量，這就是“一主多從”的部署方式，你在垂直電商項(xiàng)目中可以用該方式抵御較高的并發(fā)讀流量。另外，從庫(kù)也可以作為一個(gè)備庫(kù)，以避免主庫(kù)故障導(dǎo)致的數(shù)據(jù)丟失。

MySQL 一主多從

當(dāng)然，一旦你提及“一主多從”，面試官很容易設(shè)陷阱問(wèn)你：那大促流量大時(shí)，是不是只要多增加幾臺(tái)從庫(kù)，就可以抗住大促的并發(fā)讀請(qǐng)求了?

當(dāng)然不是。

因?yàn)閺膸?kù)數(shù)量增加，從庫(kù)連接上來(lái)的 I/O 線程也比較多，主庫(kù)也要?jiǎng)?chuàng)建同樣多的 log dump 線程來(lái)處理復(fù)制的請(qǐng)求，對(duì)主庫(kù)資源消耗比較高，同時(shí)還受限于主庫(kù)的網(wǎng)絡(luò)帶寬。所以在實(shí)際使用中，一個(gè)主庫(kù)一般跟 2～3 個(gè)從庫(kù)(1 套數(shù)據(jù)庫(kù)，1 主 2 從 1 備主)，這就是一主多從的 MySQL 集群結(jié)構(gòu)。

其實(shí)，你從 MySQL 主從復(fù)制過(guò)程也能發(fā)現(xiàn)，MySQL 默認(rèn)是異步模式：MySQL 主庫(kù)提交事務(wù)的線程并不會(huì)等待 binlog 同步到各從庫(kù)，就返回客戶端結(jié)果。這種模式一旦主庫(kù)宕機(jī)，數(shù)據(jù)就會(huì)發(fā)生丟失。

而這時(shí)，面試官一般會(huì)追問(wèn)你“MySQL 主從復(fù)制還有哪些模型?”主要有三種。

• 同步復(fù)制：事務(wù)線程要等待所有從庫(kù)的復(fù)制成功響應(yīng)。
• 異步復(fù)制：事務(wù)線程完全不等待從庫(kù)的復(fù)制成功響應(yīng)。
• 半同步復(fù)制：MySQL 5.7 版本之后增加的一種復(fù)制方式，介于兩者之間，事務(wù)線程不用等待所有的從庫(kù)復(fù)制成功響應(yīng)，只要一部分復(fù)制成功響應(yīng)回來(lái)就行，比如一主二從的集群，只要數(shù)據(jù)成功復(fù)制到任意一個(gè)從庫(kù)上，主庫(kù)的事務(wù)線程就可以返回給客戶端。

這種半同步復(fù)制的方式，兼顧了異步復(fù)制和同步復(fù)制的優(yōu)點(diǎn)，即使出現(xiàn)主庫(kù)宕機(jī)，至少還有一個(gè)從庫(kù)有最新的數(shù)據(jù)，不存在數(shù)據(jù)丟失的風(fēng)險(xiǎn)。

講到這兒，你基本掌握了 MySQL 主從復(fù)制的原理，但如果面試官想挖掘你的架構(gòu)設(shè)計(jì)能力，還會(huì)從架構(gòu)設(shè)計(jì)上考察你怎么解決 MySQL 主從復(fù)制延遲的問(wèn)題，比如問(wèn)你“在系統(tǒng)設(shè)計(jì)上有哪些方案可以解決主從復(fù)制的延遲問(wèn)題?”

從架構(gòu)上解決主從復(fù)制延遲

我們來(lái)結(jié)合實(shí)際案例設(shè)計(jì)一個(gè)主從復(fù)制延遲的解決方案。

在電商平臺(tái)，每次用戶發(fā)布商品評(píng)論時(shí)，都會(huì)先調(diào)用評(píng)論審核，目的是對(duì)用戶發(fā)布的商品評(píng)論進(jìn)行如言論監(jiān)控、圖片鑒黃等操作。

評(píng)論在更新完主庫(kù)后，商品發(fā)布模塊會(huì)異步調(diào)用審核模塊，并把評(píng)論 ID 傳遞給審核模塊，然后再由評(píng)論審核模塊用評(píng)論 ID 查詢從庫(kù)中獲取到完整的評(píng)論信息。此時(shí)如果主從數(shù)據(jù)庫(kù)存在延遲，在從庫(kù)中就會(huì)獲取不到評(píng)論信息，整個(gè)流程就會(huì)出現(xiàn)異常。

主從延遲影響評(píng)論讀取的實(shí)時(shí)性

這是主從復(fù)制延遲導(dǎo)致的查詢異常，解決思路有很多，我提供給你幾個(gè)方案。

使用數(shù)據(jù)冗余

可以在異步調(diào)用審核模塊時(shí)，不僅僅發(fā)送商品 ID，而是發(fā)送審核模塊需要的所有評(píng)論信息，借此避免在從庫(kù)中重新查詢數(shù)據(jù)(這個(gè)方案簡(jiǎn)單易實(shí)現(xiàn)，推薦你選擇)。但你要注意每次調(diào)用的參數(shù)大小，過(guò)大的消息會(huì)占用網(wǎng)絡(luò)帶寬和通信時(shí)間。

使用緩存解決

可以在寫入數(shù)據(jù)主庫(kù)的同時(shí)，把評(píng)論數(shù)據(jù)寫到 Redis 緩存里，這樣其他線程再獲取評(píng)論信息時(shí)會(huì)優(yōu)先查詢緩存，也可以保證數(shù)據(jù)的一致性。

不過(guò)這種方式會(huì)帶來(lái)緩存和數(shù)據(jù)庫(kù)的一致性問(wèn)題，比如兩個(gè)線程同時(shí)更新數(shù)據(jù)，操作步驟如下：

線程 A 先更新數(shù)據(jù)庫(kù)為 100，此時(shí)線程 B 把數(shù)據(jù)庫(kù)和緩存中的數(shù)據(jù)都更新成了 200，然后線程 A 又把緩存更新為 100，這樣數(shù)據(jù)庫(kù)中的值 200 和緩存中的值 100 就不一致了。

總的來(lái)說(shuō)，通過(guò)緩存解決 MySQL 主從復(fù)制延遲時(shí)，會(huì)出現(xiàn)數(shù)據(jù)庫(kù)與緩存數(shù)據(jù)不一致的情況。

直接查詢主庫(kù)

該方案在使用時(shí)一定要謹(jǐn)慎，你要提前明確查詢的數(shù)據(jù)量不大，不然會(huì)出現(xiàn)主庫(kù)寫請(qǐng)求鎖行，影響讀請(qǐng)求的執(zhí)行，最終對(duì)主庫(kù)造成比較大的壓力。

當(dāng)然了，面試官除了從架構(gòu)上考察你對(duì) MySQL主從復(fù)制延遲的理解，還會(huì)問(wèn)你一些擴(kuò)展問(wèn)題，比如：當(dāng) MySQL 做了主從分離后，對(duì)于數(shù)據(jù)庫(kù)的使用方式就發(fā)生了變化，以前只需要使用一個(gè)數(shù)據(jù)庫(kù)地址操作數(shù)據(jù)庫(kù)，現(xiàn)在卻要使用一個(gè)主庫(kù)地址和多個(gè)從庫(kù)地址，并且還要區(qū)分寫入操作和查詢操作，那從工程代碼上設(shè)計(jì)，怎么實(shí)現(xiàn)主庫(kù)和從庫(kù)的數(shù)據(jù)訪問(wèn)呢?

實(shí)現(xiàn)主庫(kù)和從庫(kù)的數(shù)據(jù)庫(kù)訪問(wèn)

一種簡(jiǎn)單的做法是：提前把所有數(shù)據(jù)源配置在工程中，每個(gè)數(shù)據(jù)源對(duì)應(yīng)一個(gè)主庫(kù)或者從庫(kù)，然后改造代碼，在代碼邏輯中進(jìn)行判斷，將 SQL 語(yǔ)句發(fā)送給某一個(gè)指定的數(shù)據(jù)源來(lái)處理。

這個(gè)方案簡(jiǎn)單易實(shí)現(xiàn)，但 SQL 路由規(guī)則侵入代碼邏輯，在復(fù)雜的工程中不利于代碼的維護(hù)。

另一個(gè)做法是：獨(dú)立部署的代理中間件，如 MyCat，這一類中間件部署在獨(dú)立的服務(wù)器上，一般使用標(biāo)準(zhǔn)的 MySQL 通信協(xié)議，可以代理多個(gè)數(shù)據(jù)庫(kù)。

該方案的優(yōu)點(diǎn)是隔離底層數(shù)據(jù)庫(kù)與上層應(yīng)用的訪問(wèn)復(fù)雜度，比較適合有獨(dú)立運(yùn)維團(tuán)隊(duì)的公司選型;缺陷是所有的 SQL 語(yǔ)句都要跨兩次網(wǎng)絡(luò)傳輸，有一定的性能損耗，再就是運(yùn)維中間件是一個(gè)專業(yè)且復(fù)雜的工作，需要一定的技術(shù)沉淀。

總結(jié)

我們先從一個(gè)案例出發(fā)，了解了在互聯(lián)網(wǎng)流量讀多寫少的情況下，需要通過(guò)“讀寫分離”提升系統(tǒng)的并發(fā)能力，又因?yàn)?ldquo;讀寫分離”的前提是做 “主+從”的數(shù)據(jù)集群架構(gòu)，所以我們又講了主從復(fù)制的原理，以及怎么解決主從復(fù)制帶來(lái)的延遲。